Limiting the AssignedTo dropdown-population for Team Foundation Server workitems

The Situation

You are running multiple Team Foundation Server projects with different developers working on different projects. All of the projects use the MSF Agile process. When a workitem is created (Task, Bug, etc.) you are able to assign a workitem to a designated user. The UI contains with a dropdown which is filled with all TFS users, not just the projectmembers. Furthermore you find it undesirable that new workitems are assigned to the creator by default.

Desired situation

When selecting a person to assign a workitem to, the dropdown is filled with persons assigned to the project’s Contributors or Project Administrator group. New workitems are assigned to no one in paticular. Both new and current projects should work this way.

Steps to get there

Download the process template for MSF Agile using the Process Template Manager.
Modify the files Bug.xml, QoS.xml, Risk.xml, Scenario.xml and Task.xml (located in the "MSF for Agile Software Development - v4.0\WorkItem Tracking\TypeDefinitions" directory) such that

<FIELD name=”Assigned To” refname=”System.AssignedTo” type=”String”>
<VALIDUSER/>
</FIELD>

is changed into

<FIELD name=”Assigned To” refname=”System.AssignedTo” type=”String”>
<ALLOWEDVALUES expanditems=”true” filteritems=”excludegroups”>
<LISTITEM value=”[Project]\Project Administrators” />
<LISTITEM value=”[Project]\Contributors” />
<LISTITEM value=”Unassigned” />
</ALLOWEDVALUES>
<DEFAULT from=”value” value=”Unassigned” />
</FIELD>

The syntax of ALLOWEDVALUES, LISTITEM and DEFAULT as well as some info on expansion can be read in the MSDN Library. After you’ve added users or groups to the project groups don’t forget to do a refresh of the project before opening a workitem, otherwise the list isn’t populated correctly, I think that expanding of the lists is done on the server, not on the client.

To correct any pre-existing projects you’ll have to use the witimport tool to update the template files in each project. So for all your projects you have to run the following commands in a command window (ofcourse substituting the placeholders for your own TFS ServerName and ProjectName):

witimport /t <TFS ServerName> /p <ProjectName> /f <fullPathToModifiedFile>\Bug.xml
witimport /t <TFS ServerName> /p <ProjectName> /f <fullPathToModifiedFile>\QoS.xml
witimport /t <TFS ServerName> /p <ProjectName> /f <fullPathToModifiedFile>\Risk.xml
witimport /t <TFS ServerName> /p <ProjectName> /f <fullPathToModifiedFile>\Scenario.xml
witimport /t <TFS ServerName> /p <ProjectName> /f <fullPathToModifiedFile>\Task.xml

Again, remember to refresh any running Team Explorer instances to receive the changes on the client machines.

JetBrains is creating a Team Development System

My former colleagues at Info Support have it for some time now and sell it as part of their Endeavour offering.
I’ve implemented multiple variations, always with the help of the popular CruiseControl.Net
Microsoft has one named Visual Studio Team System
There used to be an initiative for an Open Source variant name NTeam but it appears to be dead.

Now apparantly the people at JetBrains (of IntelliJ IDEA and ReSharper fame) are building one as well. A Team Development System called TeamCity. From the webpages I conclude that they are implementing a distributed team environment which picks an available build server to run the next build on, and it will both build .Net and Java projects. Looks promising, I’ll keep an eye on it.