Work Item Rules Workarounds: Secure creation of a work item type


In our last post in this series, Sunder blogged about Deactivating a work item type. Here’s another popular request: “Secure creation of a work item type”. For example, people say:

  • “Only my Testers can create bugs”
  • “Only my Business Analysts can create Requirements”

This is a legitimate request and we don’t have a good answer in Work Item Tracking, but do have AN answer.

First you add the following rules to the default transition.

<Transition from="" to="Active“ for=>
  <REASONS>
    <DEFAULTREASON value="New" />
  </REASONS>

</FIELDS>

   <FIELD refname="System.State">
      <READONLY not="[project]\Business Analysts" />
   </FIELD>

  </FIELDS>
</Transition>

The group “[project]\Business Analysts” should then be populated with the users that can create this work item type.

Now if a user who is NOT in the group attempts to save a work item of that type, this is what he/she will see:

image

This is the approach we’ve found that works the best. But be aware of these issues:

  • It doesn’t prevent a non-approved user from creating a work item of that type, only from saving the work item of that type. Not the best experience.
  • The error message, of course, isn’t the best.

But it does do its job.

Someone who many have tried to solve this problem before, may be asking. Why aren’t we using transition security? Transition is the ability to allow only certain users to make a transition between work item states. Using this method, you would do this:

<TRANSITION from=“" to=“Active"

     for="[project]\AllTesters" not="[project]\Business Analysts">

</TRANSITION>

The reason we didn’t like that method, is because of the error message you received:

“The field ‘State’ contains a value that is not in the list of supported values”

So … when choosing a method, we chose the one that displayed the error message closest to what we’d like to show.

That’s it!

Comments (7)

  1. In our last post in this series, Gregg blogged about securing a work item type on our team blog . Another

  2. In our last post in this series, Gregg blogged about securing a work item type . Another question along

  3. The Teams WIT Tools Blog on Work Item Rules Workarounds: Secure creation of a work item type and Work

  4. Nardi says:

    I’ve followed this suggestion and everything works good when creating WI using Team Explorer (just testers can create bugs). However, when doing exactly the same using TS Web Access, it doen’t work (if I undo the change in the bug WIT, it works again).

    I’ve got the "Object reference not set to an instance of an object." message with this stack trace:

    [NullReferenceException: Object reference not set to an instance of an object.]

      Microsoft.TeamFoundation.WebAccess.WorkItemTracking.Controls.WorkItemEditorState.IsTriggerField(String fieldReference) +527

      Microsoft.TeamFoundation.WebAccess.WorkItemTracking.Controls.WorkItemEditorState.GetTriggerFields() +143

      Microsoft.TeamFoundation.WebAccess.UI.Controls.EditWorkItem.CreateWorkItemInfo(WorkItemEditorState editorState, RegistrationMethod registerMethod) +348

      Microsoft.TeamFoundation.WebAccess.UI.Controls.EditWorkItem.RegisterWorkItemInfo(WorkItemEditorState editorState, RegistrationMethod registerMethod) +18

      Microsoft.TeamFoundation.WebAccess.UI.Controls.EditWorkItem.OnPreRender(EventArgs e) +224

      System.Web.UI.Control.PreRenderRecursiveInternal() +80

      System.Web.UI.Control.PreRenderRecursiveInternal() +171

      System.Web.UI.Control.PreRenderRecursiveInternal() +171

      System.Web.UI.Control.PreRenderRecursiveInternal() +171

      System.Web.UI.Control.PreRenderRecursiveInternal() +171

      System.Web.UI.Control.PreRenderRecursiveInternal() +171

      System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +842

    Any tip about how to fix this?

    I’m using TFS 2008 SP1 and SQL 2008.

    Thanks.

  5. montch says:

    Has anyone seen the behavior of this solution change with TFS 2010?  When I attempt to make this enhancement to a WIT I get the following message when trying to create a work item that I do not have authority to do – "The value for field 'State' must be the same as the original value'.

    The ehancement suggestion above does stop the user from creating the work item but the message is miss-leading.

    Here is the XML

    <Transition from="" to="Proposed">

     <REASONS>

       <DEFAULTREASON value="New" />

     </REASONS>

     <FIELDS>

       <FIELD refname="System.AssignedTo">

         <DEFAULT from="currentuser" />

       </FIELD>

       <FIELD refname="System.State">

         <READONLY not="[Project]Contributors" />

       </FIELD>

     </FIELDS>

    </Transition>

    Thanks, Chris

  6. rnysuen says:

    Yes Chris, i'm see the same message as you.  

    i'm trying a different approach, it looks like I can secure both creation and editing of the work item:

         <FIELD name="Changed By" refname="System.ChangedBy" type="String" syncnamechanges="true" reportable="dimension">

           <ALLOWEXISTINGVALUE />

           <PROHIBITEDVALUES expanditems="true" filteritems="excludegroups">

             <LISTITEM value="[project]GroupA" />

           </PROHIBITEDVALUES>

           <!–<VALIDUSER />–>

         </FIELD>

    When I try to create a new work item or edit an existing work item, I'm seeing:

    TFS20015: The field 'Changed By' contains the value 'Some User in Group A' that is not in the list of supported values.