How can I prohibit State change from Proposed to Active in TFS Requirement work-item based on value of another field?

Question

I've added department approvals to the standard CMMI-Template Requirement work-item. I'd like to limit the System.State field such that it can only be changed from Proposed to Active when all department approvals are set to "Yes".

I've tried the following change to Requirement.xml

<FIELD name="State" refname="System.State" type="String" reportable="dimension">
  <WHEN field="Approval.Marketing" value="No">
    <READONLY />
  </WHEN>
  <WHEN field="Approval.Quality" value="No">
    <READONLY />
  </WHEN>
  <WHEN field="Approval.RD" value="No">
    <READONLY />
   </WHEN>
   <WHEN field="Approval.System" value="No">
     <READONLY />
   </WHEN>
   <WHEN field="Approval.ProgManagement" value="No">
     <READONLY />
   </WHEN>
</FIELD>

This causes the State field to become READONLY if any of the approval fields are set to "No" which is what I want. However it causes problems when creating a new requirement since the approvals are all "No" initially and thus the initial "Proposed" default for State doesn't get set due to READONLY condition. What I'd like is to do is add logic to the WHEN conditions above to AND them with the condition System.State="Proposed". I tried nesting WHEN clauses such as

<FIELD name="State" refname="System.State" type="String" reportable="dimension">
  <WHEN field="System.State" value="Proposed">
    <WHEN field="Approval.Marketing" value="No">
      <READONLY />
    </WHEN>
         . . .
  </WHEN>
</FIELD>

But this gets an error on import that WHEN clause cannot contain WHEN. How can I prohibit State change from Proposed to Active when any of the Approval fields are set to "No"

Answer 1

I spent some time figuring out if I could come up with a variation that would work since you cannot set a default value for System.State in the way you can other fields. I probably went through 50 or so variations before I came up with something that works. Granted, it is not ideal but it would solve your problem after the initial creation.

You could, inside each of the transition states, add your when clauses. For my example I was using the priority field and doing something like:

<State value="Proposed">
  <FIELDS>
    <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
      <EMPTY />
    </FIELD>
    ...
    <FIELD refname="System.State">
      <WHEN field="Microsoft.VSTS.Common.Priority" value="2">
        <READONLY />
      </WHEN>
    </FIELD>
  </FIELDS>
</State>

You would have to add your clauses of course to the other states: active, closed and Resolved.

Once you do that, create a new Requirement. When you create a new requirement you have two options:

You can either set all the options to yes, set state to proposed and save. Then go back and set them to no and save.

Or

Change your custom fields all to default to yes. Create Requirement and save. Edit it, switch all the values to no, Save.

Either way you choose to go, once this initial hurdle is over with the requirement creation. It will act how you wanted it to. In other words, if any of the values are no then it will make state readonly.

That was the best I could come up with given the restriction for the System.State field.