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:

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:

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.