We have AzureDevops 2019 on premise with users in domain 1 and users in domains 2. There is full trust between the domains. It is possible to add users from both domains to tfs security groups, however it is possible to assign work items, only to few specific users of domain 2. Can u please advise ?
however it is possible to assign work items, only to few specific
users of domain 2
For this issue , do you refer to show only the specified users in the "Assign To" dropdown?
If so, here is a case you can refer to to achieve it:
1.Open the Visual Studio Command Prompt. This will give you a command
line window with the PATH set to run VS / TFS tools
2.Download the Work Item Type definition that you want to modify (e.g.
Bug, Task):
witadmin exportwitd /collection:collectionurl /p:project /n:typename [/f:filename]
This will give you the WIT's definition, in XML format.
3.Open the XML file. You will edit the rules for the Assigned To
field. Find the term "System.AssignedTo"
4.In the Allowed Values rule element, modify your List Item element to limit the values to members of one (or
more) TFS / Active Directory group(s).
After doing these, you can import the changes in the command line window via : witadmin importwitd /collection:collectionurl /p:project /f:filename
You can also refer to this official document for details.
We seem to have resolved the problem. It seems that TFS needs two things so that users in domain 2 will be recognized for assign to : (1) place the user in a group that is member of the basic service groups, (2) time to synch with active directory.
Related
We are using Microsoft Test Manager 2015 Update 1. I created a couple of shared parameters to see how they work.
How do you delete them? I can make them inactive, but they still display in the list of available shared parameters. I don't see a delete button and when I searched online I found nothing about it.
Shared Parameters are stored in TFS as Work Items so you could destroy it (there may be a better way but I don't know of one)
Remove or delete work items
On-premise you'll have to use the witadmin.exe command line tool (%programfiles(x86)%\Microsoft Visual Studio 14.0\Common7\IDE) with the destroywi option. You'll need to know the ID of the Shared Parameter Work Item you want to get rid of.
witadmin destroywi /collection:http://TFSServerName:8080/tfs/DefaultCollection /id:123
If I load up TFS Web Access and go to Security > Users, I only see the 3 people I've added to my team. However, when I try to assign a task to someone in Web Access or in Visual Studio, it lists a bunch of users from the domain (not all users, looks like all IT people). Where does this come from? How can I change it... without exporting, editing and importing files via command line?
update: I found this line in the MSDN documentation:
Team Foundation \Team Foundation Valid Users
Members of this group
have access to Team Foundation Server. This group automatically
contains all users and groups that have been added anywhere within
Team Foundation Server. You cannot modify the membership of this
group.
I really don't understand... this is our own team's server, a separate install from the main dev team. I have no idea how these other 30 or 40 users got in this group. Major bonus <3 for any help on this. MikeR's answer will allow me to set administrators as the only assigness which will technically fix the issue, but I'd rather be able to use the groups as they were intended if possible.
The problem was that [TEAM FOUNDATION]\Valid Users included [TEAM FOUNDATION]\Team Foundation Administrators which included [BUILT IN]\Administrators
In the TFS Server Administration Console I selected Application Tier and clicked Group Membership. I then double-clicked on [TEAM FOUNDATION]\Team Foundation Administrators and removed [BUILT IN]\Administrators.
Now I only see my team and not all the SQL admins and engineers that were local admins on the server. All without any command line or addons.
This list of possible assings is defined in the WorkItemTypeDefinition. Usually you would export and import this. If you have the TFS PowerTools (http://visualstudiogallery.msdn.microsoft.com/b1ef7eb2-e084-4cb8-9bc7-06c3bad9148f) installed, you can directly work with the WITD in Visual Studio.
To do this, open "Tools->Process Editor->Work Item Types->Open WIT from Server". Choose the TeamProjectCollection you want to connect to and than choose the TeamProject and WorkItemType you are having trouble with.
Check the rules for "AssignedTo" field. Default could be the "ValidUser" rule, which includes every permitted user in TFS. Remove that rule and add a new one "AllowedValues" rule with values like "[project]\Project Administrators", than only "Project Administrators" can be assigned to this Work Item.
If there is already a group defined and not all "ValidUser", remove users from the group set is set there.
I have a TFS 2010 Work Item Type with a custom field called "Requested By." This field can be populated with any name, but since most of the requests come from project developers throughout the organization, the SUGGESTEDVALUES property should populate the dropdown list with members of any TFS team project.
I have tried various values for SUGGESTEDVALUES, but both Collection\ Project Collection Valid Users and Server\ Team Foundation Valid Users seem to return every valid Active Directory account—well over 10,000 names.
I recognize that one option is to add an ALLOWEDVALUES item with multiple LISTITEM entries for Project\ Contributors for every team project, but with more than 150 team projects in the organization, this would be time-consuming initially and challenging to manage in the future.
Is there any easy way to populate the drop-down with TFS valid users who have actually been assigned to any team project in the collection, and exclude "Valid" users who exist in Active Directory but have never been assigned to a project?
What do you get if you use Project Collection Valid Users?
Project Collection Valid Users is the correct group to use, and I have entered it correctly.
However, one project team wanted to make their code available to the entire organization, and added ORG\Domain Users to the [Project]\Readers group. This was discovered by running a full audit with TFS Projects based on a hunch that something like that must have happened.
Having answered this question with "because a project team was doin' it wrong," I have posted a follow-up question to find out how to correctly grant all valid TFS users access to a specific project. See How can I grant Team Project access to all Project Collection Users? for the discussion on (hopefully) doing this "the right way."
I am in the process of evaluating JIRA as a replacement to TFS 2010.
I know that JIRA has the capability to import from CSV but cannot figure out how to export fields like the History fields from TFS to a spreadsheet.
Any recommendations / tools would be highly appreciated.
I don't think there is an easy way to do what you want.
I am thinking you would need to make your own tool using the TFS API. I don't know if JIRA has an API to do the inserting, but TFS's api is fairly good. You could easily get that data out.
For "How To" on the TFS API I usually look to Shai Raitan's TFS API blog posts.
I do custom migrations from all sorts of databases (ClearQuest, TeamTrack, Remedy) into JIRA. It takes about a week to do the job so it isn't cheap but if you have a lot of data and want more information than the standard importers provide, it's one way to go. The CSV importer probably won't do what you want.
Have a look at Appfire's Enterprise Migration Utility. It migrates TFS to JIRA, amongst others.
Simple enough, create a Query that has all your work items, click on the icon to open in Excel,
Save the Excel file as CSV.
done.
Here's what worked for me (sorry about the formatting; it was a .docx):
For every TFS Server:
Create a query by using Iteration Path for all Product Backlog Items and Bugs for every Product and/or every Scrum Team.
A single query can be used for all projects/products by altering the iteration path(s)
Format the results in TFS by selecting the appropriate columns.
Save the query, run it, and open it in Excel an .xlsx file with the word RAW included (for example, XXXX_ALL_WIs_RAW.xlsx).
Using the same file, select Save As… to create and save an excel .csv file.
Note that not all columns/mappings will be used on all projects. Delete unnecessary columns, and change column headings as needed.
The TFS columns/fields, and the Jira fields (some custom) to which they are mapped, for me were:
Iteration Path maps to Scrum Team
ID maps to Legacy ID
Work Item Type maps to Issue Type
Title maps to Summary
Description maps to Description
Acceptance Criteria maps to Acceptance Criteria
Assigned To maps to Assignee (Users must exist in Jira for this to work!)
SubCategory maps to Component/s
Effort maps to Story Points
Severity maps to Priority
Case Number maps to Case ID
Client Name maps to Customer
Platform maps to Environment
Once the .csv has been modified, use File/Check for Issues/Inspect document to determine if modification are required so the inspection results yield no issues.
Save the clean .csv as _CLEAN (for example, XXXX_ALL_WIs_CLEAN.csv).
Rename spreadsheet headers for import to appropriate Jira field names.
Field modifications:
If the work item Acceptance Criteria field has nothing in it, enter “No Acceptance Criteria in the original TFS work item” on the csv.
If the work item Description field has nothing in it, enter “No Description in the original TFS work item” on the csv.
Bugs – Severity must be converted to a number (1 through 5).
Change column headings on the .csv to match the Jira field names, as defined above in 2d.
Clean/Inspect the .csv
If necessary, increase the advanced setting jira.bulk.create.max.issues.per.import in Jira appropriately to handle the number of items being imported (there is a 250 item import limit by default).
In Jira, at the Site Admin Level – Create new Jira projects based on individual products (NOT projects!)
Create or add users that will be used in the various projects.
In Jira, at the Site Admin level – Create Custom Fields as needed
Associate new and existing custom fields to appropriate project screens, and update.
In Jira, at the Site Admin Level – Re-index DB
At the Project level – Create components for the product by using subcategory from TFS. (Can be assigned to Component Lead)
You should now be ready for import into Jira.
Test Case Migration from TFS to Jira/Zephyr if you need it:
Test case migration is a 2-part process.
The first part will get the test cases from TFS, and create and format an Excel spreadsheet containing the data that will then be imported into Jira (Zephyr).
The second part of the process will use a Java tool to import the data from the spreadsheet created in Part 1 of the process.
Part 1 – Test Case Export
Install TCExport (Used to create the Excel spreadsheet that will be used to import the test cases into Zephyr).
When mapping fields while using the .jar tool, use the Excel column letter.
Part 2 – Test Case Import
1. Download the import utility zfj-importer-utility-0.38.jar
This utility can be run by double-clicking the file in most environments. To launch the utility double-click the .jar file or run through the command prompt as: java -jar .
Detailed instructions for using the utility can be found here: https://www.getzephyr.com/insights/getting-started-zephyr-jira-importer-utility
In VSTS 2010 – in MS Test Runner
A defect can be logged against a work item called “BUG” by default.
This bug will have all the details relevant to the test that is run like the information in the following tabs in workitem bug – details tab, System info tab , Test Cases tab, etc .,
Instead of logging defects in workitem “BUG” is it possible to log defects to any other custom workitem but still manage to hold all these details tab , system info tab , test cases tab, etc., into the custom WI.
Please refer the attachment .
You need to put your custom work item type into the Microsoft.BugCategory category. Take a look at the command line tool witadmin in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE
The following blog post might help you:
VS2010 Work item categories
If you want all the controls as well (like repro steps control), then you need to make sure the appropriate fields and form controls are copied over into the work item from the Microsoft work item definitions.