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” />


Troubleshooting a Broken TFS Data Tier

I have seen a number of questions out there around troubleshooting a broken data tier in TFS 2010 in cases where the application tier appears to be working correctly, but the whole system is down because the AT can no longer reach the core databases.   Here are the steps I have gone through to resolve the issue and to get back into production.

Start at the Data Tier

  1. For now, let’s ignore anything that isn’t App Tier (AT) or Data Tier (DT) as almost all of that can be rebuilt or you probably have it elsewhere (though possibly not the case for SharePoint documents).
  2.  First, check your database backups and their logs to make sure you have them in a safe place.  I am hoping you went through the real backup procedure (either through the painful process with all the SQL statements or through the Oct version of the Power Tools) rather than just clicking “backup” on the databases.  Make a copy of them elsewhere in case the problem comes down to a bad disk or something with the hardware.  If you can have them in a safe place, first, that is some measure of security.
  3. Check access to the databases with SQL Management studio.  You need to make sure you are using the account that you expect TFS to be using for data layer access.  Try connecting to Tfs_Configuration and to your collections Tfs_[Collection Name]
  4. Triage issues in the event logs

Validate Network Connectivity

  1. Log on to the AT server
  2. Validate that you can ping the Data Tier by its server name and its full name (FQDN)
  3. Triage issues in the event log

Validate AT Connection

  1. Open the TFS Administration Console
  2. Check the TFS logs here
  3. Click on the Application Tier Node and scroll down in the main pane to confirm that the data connection is right
  4. At this point you can try resetting the database registration in TFS
    Attempt to repair the connection
    Attempt to Re-register from scratch RegisterDbs
    RemapDbs (more complex/ split server scenarios)
  5. If you are still not at the problem, I would go through the steps as though this were a data tier move…  that means you will try to reattach the working AT to the DT.  You should first try this with the existing databases, but these may have gotten munged so you’d then move to the backup.;EN-US;955601

If you didn’t have the right backups, you may have to recover the collections once connected, but this would result in possible data loss of the unsynched portions (usually only a few seconds of difference)

The TFS 2010 Admin Tool is Finally Here!

Managing permissions can be frustrating.  Managing them in TFS 2010 can be a nightmare!  Permissions for each of the three tiers (TFS Application Tier, the Reporting Server, and the SharePoint Portal) each having different authorization management tools and settings makes configuration more painful than even the average masochist is willing to sign up for.  Even worse is when you are in a troubleshooting scenario with an end-user or client where things just don’t seem to be working correctly and you’re chasing down screwy permissions — Enter the TFS Admin Tool.

We all got spoiled using a pervious version of the tool in out 2005 and 2008 environments and it worked great until TFS 2010 came out.  Then it would only function if you had Visual Studio  2008 SP1 installed, leaving those of us who upgraded in the dust wanting for some way to wrangle our user permissions back under control.  I was a little worried about it working in my production scenario with SharePoint 2010 Enterprise in the mix as well as SSL encryption, but here it is and life is good again.

Special thanks to the hard work of  Ladislau Szomoru as well as the other contributors on CodePlex who have made my week.

You can download the TFS Admin Tool here: