Issue: updating Field AllowedValues that differ only by casing

Issue

Say you created a field and by mistake, there was a typo in one of the allowed values:

<FieldDefinition name="FieldToTestLowerUpperCase" refname="Custom.FieldToTestLowerUpperCase" type="String">
   <ALLOWEDVALUES expanditems="true">
     <LISTITEM value="Out of scope" />
     <LISTITEM value="Value 1" />
     <LISTITEM value="Value 2" />
   </ALLOWEDVALUES>
</FieldDefinition>

What you really wanted was “Out of Scope”, not “Out of scope”:

<FieldDefinition name="FieldToTestLowerUpperCase" refname="Custom.FieldToTestLowerUpperCase" type="String">
   <ALLOWEDVALUES expanditems="true">
     <LISTITEM value="Out of Scope" />
     <LISTITEM value="Value 1" />
     <LISTITEM value="Value 2" />
   </ALLOWEDVALUES>
</FieldDefinition>

Using Process Editor, even if you modify and republish the value, it does not change the casing.

Troubleshooting

I have been able to replicate your scenario with Process Tools Editor within VS 2013 Update 3 and TFS 12.0.30723.0 (Tfs2013.Update3).

I deleted the field using Process Editor to take it out of a custom Task, and then deleted it in the command line with witadmin:

witadmin deletefield

/collection:http://<tfsserver>:8080/tfs/<yourcollection> /n:Custom.FieldToTestLowerUpperCase

then re-added it using Process Editor with the right case (“Out of Scope”) and told it to rebuild the cache (“witadmin rebuildcache”). It still did not work, it still kept the same value.

I applied a simple change (add an extra space between “of” and “Scope”, saved it) and the new one had the uppercase plus the extra space (“Out of  Scope”). Then I modified the new field to use just a single space, rebuilt the cached, but it returned to using lowercase (“Out of scope”).

To see whether it was a bug with Process Editor, I did all operations using just witadmin in a command line prompt. It still did not work: even after an update, I would retrieve the work item definition and it would show the word “scope” in lowercase.

This value was cached somewhere, and not being able to update it is definitely a bug. By looking into the Fields table I confirmed that nothing really is deleted, only marked as deleted, and most likely it is reused when the value is reinserted. In addition, when a field AllowedValues is changed, the Import method (either using Process Editor, witadmin or the API) does not consider casing when checking whether the value needs to be updated.

Workaround

I found the “Out of scope” value in the TFS Constants table (within the collection database):

SELECT

PartitionId, ConstID, DomainPart, fInTrustedDomain, NamePart, DisplayPart, String, ChangerID, AddedDate, RemovedDate, SID, Cachestamp, ProjectID, TeamFoundationId, fReferenced

FROM Constants

WHERE (DisplayPart = 'Out of scope')

ORDER BY DisplayPart

Next I manually updated it to “Out of Scope”, and refreshed. This fixed the issue.

ATTENTION: Do this at your own risk, as modifying TFS tables directly is neither recommended nor supported, and might put your database in an unsupported state. I tested this on a sample TFS installation, which is not in production.

I only provided this workaround as a last resort and because it was a simple enough update of a string value. A better, supported path would be to open a case with Microsoft support using your MSDN incidents, and have it escalated to the Product Team as a Bug (I might also open a bug with Connect later, and will post the link here).

Comments are closed

Calendar

<<  March 2024  >>
MonTueWedThuFriSatSun
26272829123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Month List