Freigeben über


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):

clip_image002

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." />
  </PROHIBITEDVALUES>
  <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." />
    </WHEN>
 </FIELD>

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

  • Anonymous
    July 06, 2010
    Hi, 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">        <PROHIBITEDVALUES>          <LISTITEM value="IterationIdChanged-Restricted" />        </PROHIBITEDVALUES>        <WHENCHANGED field="System.IterationId">          <COPY for="[Project]Managers" from="value" value="IterationIdChanged-AccessOk"  />          <COPY not="[Project]Managers" from="value" value="IterationIdChanged-Restricted" />        </WHENCHANGED>      </FIELD> 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 Patrick

  • Anonymous
    July 14, 2010
    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" /> </WHENCHANGED>

  • Anonymous
    July 21, 2010
    The comment has been removed