Work Item Rules Workarounds: Validating Area Path

  • Article

There are many times when we get asked how to implement seemingly basic scenarios with the work item rules engine. What we’d like to do is publish a set of  blog posts with way to implement these commonly requested scenarios.

One of those questions is: “How can I validate Area Path”. For example:

image

In the above example, the company doesn’t want people to be able to select the root node of Area Path, nor the second level. Is there a way to force selection at a certain level, or to restrict selection at upper levels?

So we came up with a “workaround” of sorts. A way to make this work.  Here are the steps:

  1. Create a AreaPathValidation field
  2. Create a Form tab called “Validation Errors” and place AreaPathValidation on it
  3. Find out the AreaIDs of the restricted area paths
  4. Attached the following rules to AreaPathValidation field:

<FieldDefinition type="String" name="Area Path Validation" refname="Demo.AreaPathValidation">

  <PROHIBITEDVALUES>

    <LISTITEM value="Area path has to be at least 3 levels deep" />

  </PROHIBITEDVALUES>

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

  <WHEN field="System.AreaId" value="68">

    <COPY from="value" value="Area path has to be at least 3 levels deep" />

  </WHEN>

  <WHEN field="System.AreaId" value="105">

    <COPY from="value" value="Area path has to be at least 3 levels deep" />

  </WHEN>

  <WHEN field="System.AreaId" value="108">

    <COPY from="value" value="Area path has to be at least 3 levels deep" />

  </WHEN>

</FieldDefinition>

 

In the above set of rules:

  • The AreaPathValidation field acts as an error field. It either contains “No errors”, which means all is well, or some error message
  • The PROHIBITEDVALUES make the error message being copied into it an invalid state. The work item cannot be saved with that error message copied in.
  • The initial COPY command, initializes the field to “No errors”
  • the WHEN commands copy in the error message if the Area  Path is any of the three nodes we want to restrict.

Why are we using System.AreaId instead of System.AreaPath? -- Because you are not able to use System.AreaPath in a WHEN clause.

How do we find out System.AreaId? – You take a work item (without the rules above), set it to an Area Path that you want to find out the AreaID on. Save it. Then look in the “History” field, where we list all the changed values. AreaId will be listed as one of the changed values (for some reason), and you can find the AreaID out that way.

The next step is to place it on a form. We choose to make it look something like this:

image

Note how our new Area Path Validation field really becomes a way to display an intelligent error message to the user. Our work item form notes that a rule violation has appeared on the “Validation Errors” tab and places in yellow icon on it. Kind of handy.

A natural question is: “Why don’t we use the Area Path security for this?” The answer is, If you deny access to a top-level node in the Area Path, the area path security assumes a lower nodes inherit those permissions. So denying the top node also denies lower nodes and doesn’t solve our problem.

Well, that was our first “Work Item Rule Workaround” post. We have a few more to post. If you have ideas for scenarios you’d love to implement, or scenarios that you have implemented in some creative way, please let us know, and we’ll post about them.

Comments

  • Anonymous
    February 11, 2009
    PingBack from http://www.arjansworld.com/2009/02/11/linkblog-for-february-11-2009/

  • Anonymous
    February 17, 2009
    Jason Barile on Make Sure You Reinstall VS 2008 SP1 after Installing Team Explorer Charles Sterling on

  • Anonymous
    March 15, 2009
    The comment has been removed

  • Anonymous
    April 23, 2009
    In our last post in this series, Gregg blogged about validating area path . Let’s take a look at another

  • Anonymous
    January 06, 2010
    The community content on the VS2005 Help Topic for this issue (http://msdn.microsoft.com/en-us/library/ms181480(VS.80).aspx) gives this workaround for the TSWA issue: <WHENCHANGED field="System.IterationPath"> <COPY from="value" value="" /> </WHENCHANGED> I haven't tried it out, though.

  • Anonymous
    June 22, 2010
    Worked first time in TFS 2010.  For those of you having issues, the xml to copy paste should actually be <FIELD... />  not <FieldDefinition... />   I also wanted to show 3 different error messages depending on the AreaID, so I had to include 3 different <LISTITEM.../> elements in the PROHIBITEDVALUES section.    For the form layout (which is weird and painful even in the 2010 Process Editor), Just add a new TabPage, then add a New Control to the TabPage, then set the FieldName property on the right.  It's a dropbox that will poplate w/ all the fields..my new validation control was at the top  (so will yours if you copy/paste demo verbatim cuz it'll be Demo.AreaPathValidation that shows up first).  Again - just awesome!

  • Anonymous
    March 13, 2012
    That works if you have very few areas and they are not volatile - any way short of coding something to work around that (in my case I need to enforce certain rules when an area is 'under' a particular root which is looking much harder than I was anticipating).

  • Anonymous
    May 28, 2015
    You can adapt the approach to other uses.  E.g. forcing a field to be changed on a state transition: superuser.com/.../tfs-2010-transition-validation-to-force-field-change