If you customize work item type definitions in TFS, you may have already encountered this error. Witimport works fine and imports your type with no errors; however, saving your work item gives you the following error: "TF26201: This work item has unsupported fields, or user does not have permissions." Go figure... If you do have permissions for saving that work item, you have just encountered a bug in the rules engine.

Before I explain how to take care of the issue, let me explain briefly the process of rules evaluation in TFS. Rules get evaluated when a new revision is created (all fields), after field's value was changed by user (affected fields only), and before the work item is saved (all fields). Evaluation occurs in two steps (it's a little bit more complicated, but this is enough to explain the issue):

  1. Processing copy & default rules;
  2. Processing all remaining rules.

Internally the system stores all rules in a form of a flat list; each rule record includes the rule itself, a field it applies to, and a condition defining when the rule applies. Evaluation of rules occurs according to the following algorithm:

  1. Get the next rule.
  2. Apply the rule if its condition is satisfied
  3. Go to step 1.

Normally the list includes all rules defined in the work item type, but after a single field change it is included to rules defined for that field and all dependencies. Now consider a work item type with the following field definitions:

  <FIELD refname="Sample.Field.1" name="Sample Field 1" type="String">
    <COPY from="value" value="Value 1"/>
  <FIELD refname="Sample.Field.2" name="Sample Field 2" type="String">
    <WHEN field="Sample.Field.1" value="Value 1">
      <COPY from="value" value="Value 2"/>
  <FIELD refname="Sample.Field.3" name="Sample Field 3" type="String">
    <WHEN field="Sample.Field.2" value="Value 2">

Whether the COPY rule for Field 2 will be executed during the phase 1 after creating a new work item depends on the order in which copy rules will be processed, and that order is not deterministic (although it always stays the same for a single team foundation server). If COPY rule for Field 1 evaluates first, it modifies Field 1, and condition on Field 2 evaluates to true causing its COPY rule to be executed. However, condition on Field 2 does not evaluate to true if Field 2's COPY rule was obtained first (because Field 1 had not been modified); Field 3 will not appear required. Saving the work item will trigger another round of rules evaluation, which will set Field 2 to Value 2 and will implicitly make Field 3 invalid. Saving the work item fails, and you are getting the ugly TF26201 message.

At this time we do not have a reliable solution for this problem. Here are some tips to ease the pain:

  • After saving a work item failed with this message, you may be able to identify the field causing that failure by analyzing each field's IsValid property.
  • Avoid "chaining" conditions to results of applying a COPY/DEFAULT rule if that rule is located within a condition.