TFS 2008: Can you restrict users from selecting certain iteration paths?

An interesting post from Coop (Chris Cooper) this week.

-- Trev



This week I was asked if there was a way to restrict users from selecting certain iteration paths. For instance, he wanted Project Administrators to have the ability to place bugs in the “Deferred” iteration path, but not the developers. Since there is no easy way to set permissions on iteration paths, we had to come up with some sort of work around.

Looking for a place to start, I found the following post on the WIT Tools Blog. Using that as a starting point, I proposed the following solution.

We would copy a PROHIBITEDVALUES value “You do not have permission to put work items into the Deferred iteration path” into the new field when the iteration path of “Deferred” was selected by the contributors group. When someone from the Project Administrators group would attempt to place the work item into the “Deferred’ iteration path, we would copy a non-prohibited value of “No errors” into that field. This prevents anyone from saving the work item when the value is set to the defined prohibited value.

The result of that would look like this (click pic to see full size):


The steps to achieve this validation are as follows:

1) Create an IterationPathValidaion field

2) Create a form tab called “Validation Errors” and place IterationPathValidation on it.

3) Find out what the iteration IDs for the iterations you wish to restrict

4) Add the code at the bottom to IterationPathValidation

How do I find the Iteration IDs for the Iterations I wish to restrict?

To obtain the Iteration IDs of the Iterations you wish to restrict, find a work item that is saved with the Iteration you wish to restrict and look at the “History” field, where you find all of the changed values. IterationId will be listed as a changed value.

Next, create a form tab called “Validation Errors” add the field IterationPathValidation . Attach the following rules to that field:


<FIELD name="Iteration Path Validation" refname="Custom.IterationPathValidation" type="String" reportable="dimension">
  <PROHIBITEDVALUES expanditems="true">
    <LISTITEM value="You do not have permissions to put work items in the Deferred iteration path." />
  <COPY from="value" value="No Errors." />
    <WHEN field="System.IterationId" value="70">
        <COPY for="[project]\Contributors" from="value" value="You do not have permissions to put work items in the Deferred iteration path." />
        <COPY for="[project]\Contributors2" from="value" value="You do not have permissions to put work items in the Deferred iteration path." />

This rule will prevent anyone from the Contributors or Contributors2 groups from saving the work item with the Iteration path is set to “Deferred” .

-- Chris

Comments (3)

  1. Patrick B. says:


    We have a different situation here for wich I tried to find inspiration from Chris's post but could'nt solve it yet.

    Here is our case: Only members of TFS group called [project]Managers should be allowed to change iterationPath field.

    Since IterationPath, as a System field, cannot hold any custom rules I tried something like this using WHENCHANGED with IterationID field:

    <FIELD type="String" name="Test-ValidateAccessToIteration" refname="Test.ValidateAccessToIteration">


             <LISTITEM value="IterationIdChanged-Restricted" />


           <WHENCHANGED field="System.IterationId">

             <COPY for="[Project]Managers" from="value" value="IterationIdChanged-AccessOk"  />

             <COPY not="[Project]Managers" from="value" value="IterationIdChanged-Restricted" />



    The problem I get with this is that the For/Not Optional PlainRule attribute doesn't work properly. My current user (ex: Darren) is a member of [project]Managers but the "COPY not" condition always pass.

    I was intrigued so I, for a test, added a READONLY for="[Project]Managers" for that field and guess what… it turns READONLY meaning the for= read TFS groups properly.

    Any idea/clue why this doesn't work within WHENCHANGED ?

    Thanks for your help


  2. Hi Patrick. Chris replied thusly:

    I had the same experience trying it that way, so I went the route in the example posted. I think the work around other than to open a support incident for further investigation would be to add all the groups. I have not tested this though.

    <WHENCHANGED field="System.IterationId">

    <COPY for="[Project]Managers" from="value" value="IterationIdChanged-AccessOk"  />

    <COPY for="[Project]Contributors" from="value" value="IterationIdChanged-Restricted" />

    <COPY for="[Project]Readers" from="value" value="IterationIdChanged-Restricted" />


  3. Patrick Bourbeau says:

    Hi Trevor,

    Thanks for following up.

    Bottom line, the real problem I experience is that s that the For/Not Optional PlainRule attribute doesn't seems work properly with COPY in TFS2008. I did some tests with users included or excluded in [Project]Managers and I always get the same result: the field tells me the user is not in the group. It looks like  the for/not attribute is not supported in TFS2008, that's probably why you can't specify that option when using the process template editor even thow you can use it directly in XML WIT definition without any error or warning when loading the file on the server.

    As a workaround for the moment is I just added 2 hidden fields called IterationPathChangedBy and IterationChangedDate like this:

    <FIELD reportable="detail" type="String" name="Iteration Path changed by" refname="XXXX.VSTS.IterationPathChangedBy">

    <WHENCHANGED field="System.IterationId">

     <SERVERDEFAULT from="currentuser" />


    <FIELD reportable="detail" type="DateTime" name="Iteration Path changed date" refname="XXXX.VSTS.IterationPathChangedDate">

    <WHENCHANGED field="System.IterationId">

     <SERVERDEFAULT from="clock" />


    Those two fields keep track when and by who IterationPath was changed. You can then easily use those fields in a query to check if unauthorized people had changed iterations. This is the workaround we delivered to managers while seeking another way to implement the field secutiry restriction. It is a PULL strategy but it's better than nothing for the moment 🙂

    It would also have been nice to combine those two fields with custom alerts but since custom fields are not part of TFS "Core fields" they are not included in the messages sent by TFS events I cannot use =, <>.. operators but only Changes, Change from and Changeto. If there is a way to include some strategic custome fields within event messages then I could switch to a PUSH strategy where the system alert the user when unautorized people changes IterationPath field.

    I'll post back any further development info later on after holidays 🙂

    Best regards


Skip to main content