User Display Name Changes and New Attribute for Work Item Type Definitions in TFS 2010

If you’ve had the responsibility of administering a TFS 2005 or TFS 2008 server you may have run in the “Display Name” problem before. In March 2007, the TFS Work Item Tracking team put a great post together about what’s exactly going on and it’s available here: http://blogs.msdn.com/teams_wit_tools/archive/2007/03/15/handling-display-name-changes-in-team-foundation-server.aspx

Basically, in TFS work item types, you can specify a field to hold the name of a user like in the Assigned To field. The value that gets stored is basically just a string value of the person’s Display Name in Active Directory. Not so bad except it’s not a strongly-typed object of a user but is just a string. The problem comes when the user’s display name gets changed in Active Directory like when an employee gets married and take’s their spouse’s last name. This causes a problem because all of the work items are still assigned to “Jane Doe” instead of “Jane NewLastName”. Even worse, “Jane Doe” is not even a valid user any longer so the work item becomes in an invalid state. It’s kind of a maintenance nightmare.

Background: Every hour an Active Directory synchronization job gets queued up and processes changes to Active Directory like new users, group membership changes, etc. TFS keeps a cache of AD locally to help with operations across several subsystems. For users, it caches certain information like the primary e-mail address, display name, domain/user name, SID, distinguished name, etc.

Thankfully there was something that helped us out available in the TFS Power Tools release called “TFS Users.” You had to know about the display name change so working closely with your IT department was important. Thankfully, it looks like TFS 2010 has added some abilities to notice those display name changes and proactively help you out within your system. One of those changes is a new attribute in your work item type definitions that tells TFS which fields to automatically update. I’ve bolded and underlined all of the changes from the previous default definition of the MSF Agile Bug.

<FIELD name=”Assigned To” refname=”System.AssignedTo” type=”String” syncnamechanges=”true” reportable=”dimension”> <VALIDUSER /> <HELPTEXT>The person currently working on this bugHELPTEXT> FIELD> <FIELD name=”Activated By” refname=”Microsoft.VSTS.Common.ActivatedBy” type=”String” syncnamechanges=”true” reportable=”dimension”> <WHENNOTCHANGED field=”System.State”> <ALLOWEXISTINGVALUE /> <READONLY /> WHENNOTCHANGED> FIELD> <FIELD name=”Changed By” refname=”System.ChangedBy” type=”String” syncnamechanges=”true” reportable=”dimension”> <ALLOWEXISTINGVALUE /> <VALIDUSER /> FIELD> <FIELD name=”Closed By” refname=”Microsoft.VSTS.Common.ClosedBy” type=”String” syncnamechanges=”true” reportable=”dimension”> <WHENNOTCHANGED field=”System.State”> <ALLOWEXISTINGVALUE /> <READONLY /> WHENNOTCHANGED> FIELD> <FIELD name=”Created By” refname=”System.CreatedBy” type=”String” syncnamechanges=”true” reportable=”dimension” /> <FIELD name=”Authorized As” refname=”System.AuthorizedAs” type=”String” syncnamechanges=”true” />
<FIELD name=”Resolved By” refname=”Microsoft.VSTS.Common.ResolvedBy” type=”String” syncnamechanges=”true” reportable=”dimension”> <WHENNOTCHANGED field=”System.State”> <ALLOWEXISTINGVALUE /> <READONLY /> WHENNOTCHANGED> FIELD>

If you have custom process templates or you have modified the out of the box process templates, you’ll have to do some maintenance to your existing team projects to light up the new TFS 2010 features available including the ability to automatically sync the name changes from Active Directory. If you are using the MSF Agile template you will want to update the following fields:

• Assigned To
• Activated By
• Changed By
• Closed By
• Created By
• Authorized As
• Resolved By

For all other process templates, you’ll want to update the work item types that have fields that hold display name values. There is actually some great information already available about this particular topic available in the MSDN Library: http://msdn.microsoft.com/en-us/library/dd286562(VS.100).aspx

One of the other things we notice from the changes are the addition of the ALLOWEXISTINGVALUE rule to some of the fields. This rule allows a previously entered value to still be valid even if that value is no longer a valid value. In addition, there are also some state/transition rule changes for allowing the existing value. Be sure to do a diff against your current work item type definition and the new MSF Agile work item type definitions to find all of the new changes.

For more information about managing work item type fields in TFS, see this MSDN Library Article: http://msdn.microsoft.com/en-us/library/dd236909(VS.100).aspx

Ed Blankenship