In one of my previous blog posts I was asked how to add custom ‘State’ values for a work item in Team Foundation Server 2010.
The state field is a unique field within the Work Item definition, and the mechanism to edit the values is not quite as intuitive as with other fields. Normally, the allowed values for a field are stored directly within the Field tag, using an AllowedValues (or even SuggestedValues) node:
<FIELD name=“Priority” refname=“Microsoft.VSTS.Common.Priority” type=“Integer” reportable=“dimension“>
<HELPTEXT>Importance to business</HELPTEXT>
<ALLOWEDVALUES expanditems=“true“>
<LISTITEM value=“1“ />
<LISTITEM value=“2“ />
<LISTITEM value=“3“ />
<LISTITEM value=“4“ />
</ALLOWEDVALUES>
<DEFAULT from=“value” value=“2“ />
</FIELD>
The State field is slightly different – the field definition itself doesn’t actually contain any of the valid state values:
<FIELD name=“State” refname=“System.State” type=“String” reportable=“dimension“>
<HELPTEXT>Active = work remains to be done. Closed = tested and checked in.</HELPTEXT>
</FIELD>
Instead, value state values are added to the States node within the Workflow node of the Work Item. See the below for adding a ‘Proposed’ state to the Work Item:
<WORKFLOW>
<STATES>
<STATE value=”Proposed” />
<STATE value=“Active“>
<FIELDS>
<FIELD refname=“Microsoft.VSTS.Common.ClosedDate“>
<EMPTY />
</FIELD>
<FIELD refname=“Microsoft.VSTS.Common.ClosedBy“>
<ALLOWEXISTINGVALUE />
<EMPTY />
</FIELD>
</FIELDS>
</STATE>
<STATE value=“Closed“ />
</STATES>
…
Transition rules can then be applied to the Work Item State using the Transitions node:
<TRANSITIONS>
<TRANSITION from=“” to=“Proposed“>
<REASONS>
<DEFAULTREASON value=“New“ />
</REASONS>
</TRANSITION>
<TRANSITION from=“Proposed” to=“Active“>
…
With these modifications made, you should now be able to re-import the Work Item Type definition file back into Team Foundation Server 2010.
C:\TFS>”C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\witadmin” importwitd /collection:localhost\defaultcollection /p:”{ExistingProjectName}” /f:Task.xml
Note – don’t forget to restart your Visual Studio environment before trying to use your updated Work Item in order to refresh the cache. |
Hello,
I was trying to figure out a way to build a custom rule? I am creating a top level work item template, with n number of children possible. If all children items have a completed date value, I want to set the parent status to CLOSED else set it to a count of children records that are not closed. Example: OPEN – 7 child records remain open.
Is this possible?
Hi Mike,
Sorry about the delayed response.
I’d recommend you have a look at this post on using the Event Service API by Ewalk Hofman. The example is to roll up all of the hours in sub tasks to the parent – but this shouldn’t be too hard to modify to be based on the status field instead.
http://www.ewaldhofman.nl/?tag=/TFS+2010+API%3B+Event+service
Cheers,
Nick
Hi, thank you very much for this post – helped me out with my issue of creating new states for work items. Hopefully in the future there will be a easier way to modify the work flow and add states.
The details in this link worked for me. http://tedgustaf.com/en/blog/2011/1/how-to-customize-tfs-2010-work-items-and-workflows/