Work Item rules workaround: Closing down an iteration

  • [アーティクル]

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.

Comments

  • Anonymous
    March 10, 2009
    PingBack from http://www.anith.com/?p=17357

  • Anonymous
    March 11, 2009
    Hi Sunder, I've tried this exact approach on my TFS, but it only seems to work for the Visual Studio interface, not the Team System Web Access. Is this a known limitation? I'm using TFS & Visual Studio 2005, if that makes any difference. Thanks, Mal.

  • Anonymous
    March 12, 2009
    The comment has been removed

  • Anonymous
    March 17, 2009
    In our last post in this series, Sunder blogged about Closing down an iteration . Let’s take a look at

  • Anonymous
    March 17, 2009
    Hi Mal, The rules used here are validated the same way in VS and Team System Web Access. This workaround should work from Web Access as well. Can you let me know what didn't work? Was there an error? Or is the validation not happening? Thanks, Sunder

  • Anonymous
    March 25, 2009
    Buck Hodges , one of our Dev Managers, recently referenced one my posts and I got a couple of emails

  • Anonymous
    April 08, 2009
    Mal, we have that trouble too. We are using TFS 2008, and this idea is great, but it doesn't work in TSWA. The validation error is displayed, but setting a value in the iteration dropdown does not clear the error. We only set this up today, so it may be a caching issue, but it doesn't look too good. A shame, as this is a good tip otherwise. Dylan.

  • Anonymous
    April 09, 2009
    Dylan, Sorry to hear the workaround didn't work out for you in TSWA. I didn't try this out on TSWA as the rules are evaluated the same way. I will try this out and see if I am seeing the same issue you are and post back here. Sunder

  • Anonymous
    April 23, 2009
    Dylan, I tried this out as well and we found the issue where Web Access isn’t refreshing on the WHEN rule. We logged a bug for us to address in our upcoming release. I will update the post and note this for other users as well. Thanks a lot for your feedback, it helped us catch this issue! Sunder

  • Anonymous
    April 24, 2009
    In the last post in this series , Gregg blogged about restricting a bug such that only the creator can

  • Anonymous
    April 24, 2009
    In the last post in this series , Gregg blogged about restricting a bug such that only the creator can

  • Anonymous
    June 04, 2009
    Any updates on when the fix will be released?  We'd like to start using these workarounds and most of our users use TSWA.  Thanks.

  • Anonymous
    July 09, 2009
    Skimla, We are tracking to fix the TSWA issue in our next release. Sunder

  • Anonymous
    July 14, 2009
    There is a workaround to the TSWA issue mentioned in the Community Content section of this page:  http://msdn.microsoft.com/en-us/library/ms181480(VS.80).aspx. I tried this and it appears to work just fine!  Unfortunately, using System.AreaID and System.IterationID breaks the Process Template Editor, see this thread:  http://social.msdn.microsoft.com/Forums/en-US/tfspowertools/thread/7fb3da21-1535-4077-8679-889e17e41275

  • Anonymous
    July 15, 2009
    Thanks Sunder!  Brian, thanks for the workaround.  I'll take a look at the links.

  • Anonymous
    February 11, 2011
    Thanks for the workaround but it seems a little bit weird to me...I will not update my work item type definition each time I change Iteration (every 2 weeks for example in Agile) ?!? Crawling the web, I see several work item rules issues were recorded for a while now. When can we expect some improvement ? (I use TFS 2010) I think to really basic ones : MATCH rule could easily at least use Regex expression (I try to find a reason why it does not already, since it seems it only needs less code than current implementation...), WHEN could have simple comparison operator (>, <, =, !=, contains,...) and even better simple boolean algebra (OR, AND & precedence). By the way, I find Work Item Type definition use really great and flexible in TFS. Clément PS: where can we see list of submitted requests to TFS ? (nothing to browse/search on connect.microsoft.com/VisualStudio ?)