Today I was asked one of the most asked questions related to work item tracking: “Can you can assign a work item to a group in stead of a person”?

My standard answer to this question is “yes” and I tell people this can be easily be done by setting the ALLOWEDVALUES to include the attribute expanditems = “false” and add list items that contain the TFS group names.

Since the question came from my team mate I said I would fix the work item type so he did not have to spend to much time for this simple change.

To my surprise I found that it is easy but you have to know one additional fact and that is that you must not have altered the System.AssignedTo to only allow valid users!

So what happened?

I have a work item type called “Deliverable”. This is a work item that can be assigned to a group of developers, designers, testers, etc. So the requirement was simple, have this work item only assigned to a group in stead of a person. What I did was quite simple, for each state definition I just set the ALLOWEDVALUES to the list of groups I want to have the work item assigned to. See the example below:

 <br>&lt;STATE value="Scoped"&gt; <br>&nbsp;&nbsp; &lt;FIELDS&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;FIELD refname="System.AssignedTo"&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ALLOWEDVALUES expanditems="false"&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Project Managers" /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Feature Managers"&nbsp; /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Software Architects" /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Designers" /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Implementers" /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Testers" /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;LISTITEM value="[project]\Integrators" /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ALLOWEDVALUES&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;REQUIRED /&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/FIELD&gt; <br>&nbsp;&nbsp; &lt;/FIELDS&gt; <br>&lt;/STATE&gt; <br>

After uploading the work item, I got a strange surprise, the assigned to field always appeared empty [:(]


It took me quite some time to figure out what happened here. I finally figured out that this is caused by the fact that the Work Item Field definition for System.AssignedTo has a constraint set of <VALIDUSER/> and a TFS group is not considered to be a valid user. (This is something that probably your custom work item has as well since the common way to customize your work items is to pick the Microsoft work items and change those. The Microsoft work item types have this constraint set as well )

 <br>&lt;FIELD reportable="dimension" type="String" name="Assigned To" refname="System.AssignedTo"&gt; <br><strong>&nbsp; &lt;VALIDUSER /&gt; <br></strong>&lt;/FIELD&gt; <br>

So to fix this problem, I removed the <VALIDUSER/> constraint on the System.AssignedTo field. After removing the constraint and restarting Visual Studio after uploading the new type definition(I used WITImport at the command line, but this can also be done using the power tools) , the dropdown will show the options I expected to see.


So it is nice when you know the answer , but here you can see again that only knowing the answer is not enough to be productive, you actually have to have done this so you also know the problems you might run into [:)]


Hope this keeps you from pulling your hair out.