次の方法で共有

TFS 2010: Scoping Assigned To field in Work Item Definition for a Project

  • [アーティクル]

If you are like us, we have a huge investment in Team Foundation Server (TFS) 2010 that includes many groups and many teams.  Fortunately, we are the only team doing development and our project are different from the rest of the organization which is using TFS for work item management.

By default, the “Assigned To” field requires is scoped to any valid user in the system and this often can lead to a list of users that is large and very cumbersome.    In today’s post, I will share with you how to tweak your work item template to show only valid users from your team (assuming you’ve got a team security group setup). 

Pre-Requisites

Before you can update your work item template, you will need to download the TFS 2010 Power Tools.  The Power Tools give you the process template editor which is what we will utilize to pull down your work item template for your specific project.

Export Work Item Template

The process template editor supports direct editing but this is a bit dangerous especially for production systems.  Thus, it is highly recommended that you use the process template editor to “Export WIT” to a file and then edit.  To do this, do the following -

  1. Open Visual Studio 2010
  2. Click Tools, Process Editor, Work Item Types, Export WIT
  3. If you haven’t connected yet to the server, connect to the correct collection (It will auto-prompt)image
  4. From the list, select the Project, click the + to expand current Work Item types (for the purpose of walk-through, I will select Bug)
  5. When asked if you would like to include Global List definition, select No
  6. This will save the work item template, in this case Bug, for the project which you’ve selected

Keep in mind that TFS 2010  ships with 2 out-of-box templates, MSF Agile and CMMI, and another popular one recently is the Visual Studio SCRUM 1.0.  Each of these templates (selected when you create the project) comes with a different set of work item types (Issue, Bug, Task, Sprint, etc.) and as such you will need to select the one you are interested in.

For today’s post, I will not focus on how to make this change  in an automated fashion to multiple work item types but instead focus on making the change to one single type.

Security Group Design & Utilization

If you are like us, we utilize security groups within our Active Directory (AD) domain that are members of TFS security groups.  This model is efficient because changes can be made directly to AD utilizing Forefront Identity Manager (FIM) and then immediately picked up by TFS.

For illustration purposes, this is the hierarchy -

image

For each project that is created in TFS, you can reference security groups only available to that project (e.g. not to the entire collection) using the notation [project]\{TFS Security Group Name}.  When this is known you can have a lot of fun with TFS by editing work items using either the work item editor or using Notepad (direct XML editing).

Change Assigned To Field Value

After you’ve gotten your security group structure setup, you can now answer the most simplest of questions -

for project X, only team y can have work items assigned to them

In our case, the answer to this question would be the following -

for project Louis, only Louis Dev Team can have work items assigned to them

To implement this, you would open the Louis Bug (or Task) work item and modify the field Assigned To by doing these steps:

  1. Right-click Bug work item definition file, select Open with, and choose Notepad (or your favorite XML editor)image
  2. In notepad, hit CTRL+F and do a search for Assigned To which should locate <FIELD name=”Assigned To” …>image
  3. To scope a specific TFS security group, add the following XML -
  4. Click File, Save
  5. In Visual Studio, click Tools, Process Editor, Work Item Types, Import WITimage
  6. Select the file you just edited, and then the project to import it to

For a little bit of reference information, here is a quick tid bit of information that is helpful. If you never have a situation where something is valid to be assigned to the team security group (like a triage), then include the filteritem="excludegroups” as this will remove any group from showing up in the list.  The reverse is obviously true that without this you will get all team members in the list as well as the team security group (e.g. Louis Dev Team).

You’re Done!  Well kinda…

Refresh project

The changes will not be visible to your team until they’ve refreshed the project in Visual Studio.  For those using Team Web Access, the changes are seen when the site is refreshed.  For the purposes of this example, you can right-click the project and select refresh.  Then open the work item type (ex. Bug, Task) and then check the Assigned To as it should now only show team members that are a part of the TFS security group.

image

Summary

In today’s post, I just shared a quick TFS 2010 tip relating to how to scope your Assigned To field to only show a list of specific users.  This is very helpful when you have a large set of valid users for TFS but a specific project is really only a small subset of users.  To ease management, simplify usage, and reduce mistakes, you can change the assigned to field to only show team members who are doing work for that project.  This will remove any chance of assigning the item to the wrong team member and make it much easier in the long run to simply manage assignments of work items such as bugs, tasks, and even user stories.

Enjoy!

Comments

  • Anonymous
    January 01, 2003
    Thank you! Worked like a charm.

  • Anonymous
    January 01, 2003
    I thought the post was extremely well written.  But when I import the Bug.xml I'm getting: TF26204 error. I've done some googling. I keep finding that it's an issue with the .  But not suggested solutions. Any ideas?

  • Anonymous
    January 01, 2003
    Hey itdnext- If you don't mind, can you send me your bug.xml (or whatever WIT type you are modifying) to chrad at microsoft.  I will run it through some tests on this end and see what I can find out.  I haven't personally ran into this error so I'd like to reproduce it on this end and see if I can help you. Thanks, -Chris

  • Anonymous
    January 01, 2003
    I have followed the steps in this article and after importing WIT and refreshing the project I only see name of TFS security Group that I have added to list of possible values of AssignedTo field instead of members of the group. Any Ideas?

  • Anonymous
    January 01, 2003
    Hey Sandeep- Can you send over your the small XML snippet to chrad at Microsoft dotcom so I can take a peak? Thanks, -Chris

  • Anonymous
    January 01, 2003
    Hi, thanks a lot for this helpful hints! With bugs, those new settings caused a little problem though: When a bug is set to resolved then by default the bug gets reassigned to the creator. But since the list does not contain the creator one gets an error. It would be nice if the list is a small list when creating a new bug, and if the list is complete when changing a bug. --Stefan

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Hi Steph23- Interesting, I can see how that occurs.  I was wondering when you configured this did you keep "AllowExistingValues" as a rule for the WIT.  If you copied my exact instructions, you problably didn't :) I will need to update this blog to include this.  To do it, just add under <allowexistingvalues/> <field ... /> and this should correct your problem.  This should allow the creator to get assigned to, I believe.   I've not tested... :) More here - msdn.microsoft.com/.../ms194953(v=VS.80).aspx Let me know... -Chris

  • Anonymous
    September 25, 2015
    Hi Chrad,

    If I want the workitem to be automatically assigned to the manager of the person who is creating it, how can I do it?

    - Jacques