How to change upper/lower case in a TFS work item field definition (WIT)?

Question

I have a weird problem with the configuration of TFS 2010 work items. It seems to be impossible to change the case of characters in the allowed values collection of a field e.g. change "Works for me" to "Works For Me". Every other string e.g. "Works For Me 123" is valid.

Even if I try to change the name to another string first (since i know the similar case problem with files in Visual Studio projects) it is just not accepting the upper case version and returns always to the lower case string.

Background information:

We have a custom WIT file to define the "Bug" work item. This includes the definition of the allowed values for the field "Resolved Reason". Initially our list contained lower case words e.g. "Works for me". Since we want to synchronize the TFS work items with HP Quality Center we need an exact match of the state names now.

The desired version:

<FIELD name="Resolved Reason" refname="Microsoft.VSTS.Common.ResolvedReason" type="String" reportable="dimension">
        <HELPTEXT>The reason why the bug was resolved</HELPTEXT>
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="Duplicate" />
          <LISTITEM value="Fixed" />
          <LISTITEM value="Wont Fix" />
          <LISTITEM value="Invalid" />
          <LISTITEM value="Works For Me" />
          <LISTITEM value="Forwarded" />
        </ALLOWEDVALUES>
      </FIELD>

The actual version:

<FieldDefinition reportable="dimension" refname="Microsoft.VSTS.Common.ResolvedReason" name="Resolved Reason" type="String">
  <ALLOWEDVALUES>
    <LISTITEM value="Duplicate" />
    <LISTITEM value="Fixed" />
    <LISTITEM value="Wont fix" />
    <LISTITEM value="Invalid" />
    <LISTITEM value="Works for me" />
    <LISTITEM value="Forwarded" />
  </ALLOWEDVALUES>
  <HELPTEXT>The reason why the bug was resolved</HELPTEXT>
</FieldDefinition>

Any ideas are welcome. Thanks, Robert

Answer 1

As Grant explained, the old work items are stuck with the old casing.

A manual workaround would be to create a new ListItem with the desired case (leaving the old one in the definition for now), edit the existing work items that contain the undesired case to the newly created ResolvedReason, and finish by removing the undesired item from the definition. I have done a similar thing in the past, but not specifically a case change.

If you are familiar with the TFS API (I'm not), you can programmatically update the Microsoft.VSTS.Common.ResolvedReason field values on the server. If you have access to the SQL Server 2008 instance, you might be able to edit the field values there to the new case (many layers of bureaucracy prevent me from testing this for you).