Making a work item only editable by its creator in TFS 2010

I was recently confronted by someone building a TFS template for a client that had an interesting business rule they had to support.  They needed to be able to allow only the creator of the Work Item to edit or make changes to it once it was created.  There is a lot of magic you can do with the TFS rules and field comparisons, but this one was a bit harder than most.

When TFS uses a work item, there are actually three passes that are made through the fields putting the rules in an order of precedence (For the full explanation check out this article):

  1. The first pass sets and copies values we well as dealing with any conditional rules (WHEN and WHENNOT, etc.)
  2. The second pass evaluates any fields that were changed in the first pass and then evaluates the WHENCHANGED rules, releasing the work item for editing
  3. The last pass is on commit when the Work Item is saved to the database.  This catches any rules triggered during the editing process and finally the SERVERDEFAULT rules.

The Solution

We can take advantage of this ordering to get that locking functionality to work by creating new rules on System.ChangedBy

<FieldDefinition reportable=”dimension” refname=”System.ChangedBy” name=”Changed By” syncnamechanges=”true” type=”String”>
      <COPY from=”currentuser” />
      <FROZEN />

How it works

  1. Since Copy is processed before everything else, we can use it to force the value on load before any of the other rules are posted (like the frozen one).  Then we freeze the value (the rule doesn’t fire if the field is empty).
  2. If the user that created the work item goes to edit it again, they are allowed as the value it tries to copy is the same so it never commits to trigger the frozen constraint.
  3. If a different user tries to edit the work item, the value is copied over top, but then the frozen constraint is triggered as it does the validation pass before it releases the work item into edit mode generating the error.

The downside here is that there isn’t a nice error message or prompt telling the user that they don’t have the ability to edit a work item that they didn’t create.   While that would be truly awesome, we might be content with the fact that the business rule is maintained (perhaps that makes an auditor somewhere happy.)

As an extension of this, we can also take advantage of the <FROZEN/> field by specifying the groups that are affected (or not in this case) by the change.  Here we allow Collection Administrators the ability to override, but keep the rule for everyone else.  Neat!

<FieldDefinition reportable=”dimension” refname=”System.ChangedBy” name=”Changed By” syncnamechanges=”true” type=”String”>
      <COPY from=”currentuser” />
      <FROZEN not=”[Global]\Project Collection Administrators” />


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s