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:
We assume you know how to export a team project template and how to use the process template editor power tool, or notepad++.
- 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:
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:
- Create a RemainingWorkValidation field
- Add it to the form under the Validation tab
- Add rules to RemainingWorkValidation field
- Add rules to transition to Closed
- Add rules to Active state
- Add rules to Closed state
- 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!