Welcome to MSDN Blogs Sign in | Join | Help

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!

Published Tuesday, March 31, 2009 8:44 PM by Gregg Boer

Comments

# infoblog &raquo; Work Item Rules Workarounds: Secure creation of a work item type

# Work Item rules workaround: Saving the resolved reason

Tuesday, March 31, 2009 6:29 PM by Sunder Raman's Blog

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

# Work Item rules workaround: Saving the resolved reason

Tuesday, March 31, 2009 6:31 PM by Teams WIT Tools

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

# VSTS Links - 04/03/2009

Friday, April 03, 2009 10:23 AM by Team System News

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

# Error in TS Web Access when creating WI after this workaround

Monday, July 06, 2009 4:13 PM by Nardi

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.

Anonymous comments are disabled
 
Page view tracker