VSTS Work Item – ensuring that an associate work item does not close a work item by default
In How Do I: Remove Resolve as the Default Check-in Action? ... Richard strikes again! we referred to one option of changing the default behaviour that a work item that is associated with a check-in is closed automatically and often ends up in a black hole … gone.
In the “Advanced Work Item Tracking Tips and Tricks” session, delivered by Gregg Boer, at TechReady8 today, we saw another solution and I will be quoting straight out of Gregg’s presentation:
Steps
We assume you know how to export a team project template and how to use the process template editor power tool, or notepad++.
1. Ensure that work item can only be closed by the initiator
Create a ClosedByValidation field
Create a Form tab called “Validation Errors” and place ClosedByValidation on the validation form tab
Add rules to ClosedByValidation field in the “Demo” team project, in this case:
1: <FIELD name="Closed By Validation" refname="Demo.ClosedByValidation" type="String">
2: <COPY from="currentuser" />
3: <FROZEN not=“[project]\Project Administrators”/>
4: </FIELD>
5:
6: ...
7:
8: <STATE value="Closed">
9: <FIELDS>
10: <FIELD refname="Demo.ClosedByValidation">
11: <COPY from="currentuser" />
12: </FIELD>
13: </FIELDS>
14: </STATE>
Line (3) not only freezes the field from further changes, i.e. different user closing the work item, but also excludes the “frozen” validation from the Project Administrators. The resultant validation error results in:
…
2. Ensure that work item can only be closed if remaining work is zero (0)
Create a RemainingWorkValidation field
Add it to the form under the Validation tab
Add rules to RemainingWorkValidation field
1: <FieldDefinition type="String" name="Remaining Work Validation" refname="Demo.RemainingWorkValidation">
2: <ALLOWEDVALUES>
3: <LISTITEM value="No Errors" />
4: </ALLOWEDVALUES>
5: <WHEN field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
6: <COPY from="value" value="No Errors" />
7: </WHEN>
8: </FieldDefinition>
Add rules to transition to Closed
1: <Transition from="Active" to="Closed">
2: <REASONS>
3: <REASON value="Deferred" />
4: <REASON value="Obsolete" />
5: <REASON value="Cut" />
6: <DEFAULTREASON value="Completed" />
7: </REASONS>
8: <FIELDS>
9: <FIELD refname="Demo.RemainingWorkValidation">
10: <WHENNOT field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
11: <COPY from="value"
12: value="Remaining work has to be zero before closing the work item" />
13: </WHENNOT>
14: </FIELD>
15: </FIELDS>
16: </Transition>
Add rules to Active state
1: <State value="Active">
2: <FIELDS>
3: <FIELD refname="Demo.RemainingWorkValidation">
4: <COPY from="value" value="No Errors" />
5: </FIELD>
6: </FIELDS>
7: </State>
Add rules to Closed state
1: <State value="Closed">
2: <FIELDS>
3: <FIELD refname="Demo.RemainingWorkValidation">
4: <WHENNOT field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
5: <COPY from="value" value="Remaining work has to be zero before closing the work item" />
6: </WHENNOT>
7: </FIELD>
8: </FIELDS>
9: </State>
Now we get an additional validation error if remaining work is not zero (0):
Resolution review
- We ensure that work items can only be closed by the initiator of the work item, or a team project administrator.
- We ensure that while there is work remaining, the work item cannot be closed.
So, unless the developer associating a check-in with a work item also created the work item initially, or the developer is a team project administrator, and the remaining work property is zero (0), we have an elegant solution of solving the challenge as well.
Be careful when customising process templates … future possible migration and upgrade constraints may be an issue when working with custom templates.
The tips and tricks presented here-in are shared from Gregg’s presentation … he and his team must take full credit for these great tips and tricks!