Work Item rules workaround: Closing down an iteration

  • Article

In our last post in this series, Gregg blogged about validating area path. Let’s take a look at another question: “How do I close an iteration so that no one can log new items against it? ”

image

For this example, let’s say we have completed Iteration 0 and don’t want users to log work items against this iteration. We also don’t want to allow work items against the root iteration path.

Since there is no direct way to enforce rules against iteration path, here’s how we can work around it:

  1. Create an IterationPathValidation field
  2. Create a tab on the work item form called “Validation Errors”, like the previous example on area path validation, and display the IterationPathValidation field
  3. Find the IDs for the restricted iteration paths
  4. Add the following rules to the IterationPathValidation field:

 

<FIELD type="String" name="Iteration Path Validation" refname="Demo.IterationPathValidation">

  <COPY from="value" value="No Errors" />

  <WHEN field="System.IterationId" value="113">

    <COPY from="value" value="Iteration path must be 2 levels deep" />

  </WHEN>

  <WHEN field="System.IterationId" value="115">

    <COPY from="value" value="The selected iteration has been completed. Log bugs against a future iteration." />

  </WHEN>

  <PROHIBITEDVALUES>

    <LISTITEM value="Iteration path must be 2 levels deep" />

    <LISTITEM value="The selected iteration has been completed. Log bugs against a future iteration." />

  </PROHIBITEDVALUES>

</FIELD>

 

 

The next step is to add this validation field to the work item form, let’s use the same form definition as the area path validation example. Here’s how the form would look when a user assigns a work item to Iteration 0:

image

The IterationPathValidation field shows a meaningful error message when a work item is assigned to the closed iteration.

How does this workaround work?

  • IterationPathValidation, like the previous example on area path validation, acts as an error field
  • The initial COPY rule initializes this field to “No errors” that is displayed when the rules on the field are satisfied
  • The PROHIBITEDVALUES list defines strings that are not valid for this field. We are using these as meaningful error messages as well.
  • Using the WHEN rule we can copy the error strings to this field for iterations we want to restrict

How do I find out the iteration ID?

  • Assign any work item (without the above rules) to Iteration 0
  • Save the work item
  • Expand the changed fields section in the work item history field and this will have the System.IterationID as one of the changed fields with the ID of Iteration 0

If you have ideas on other workarounds or scenarios you want to accomplish, please let us know and we will post them here. We have a few more workarounds coming your way in the upcoming posts.

Sunder Raman

Program Manager, Team Foundation Server

 

[Update 4/23/2009] Thanks to one of our readers, Dylan for his comment that this workaround didn't work for him in TSWA. I reproed this workaround and we found the issue where Web Access isn't refreshing on WHEN rule. We are tracking this bug to be fixed in our upcoming release. Caution to users, if you are using TSWA, note that this workaround doesn't work in TSWA.