Can anyone explain why <ALLOWEXISTINGVALUE> is not allowed for System.Reason. I would think this is just an ordinary string field.

Thanks.

Robert,

So what is the trick to creating new fields?

My attempts at creating new fields end up with

TF26201: This work item has unsupported fields, or user does not have permissions.

I am suspicious that Microsoft.VSTS... or System... are sacred places you can not add fields to, so I have tried creating them in MPRI.mynewname.  But still no dice.  It may be because I still have one field Microsoft.VSTS.Scheduling.EstimateOfWork that I haven't changed to MPRI.EstimateOfWork.

But there doesn't seem to be any way to determine just which field is unsupported

<FIELD name="DashReason" refname="Nowcom.Dash.Reason" type="String">

<WHEN field="System.State" value="Active">

<DEFAULT from = "value" value = "New" />

<REQUIRED />

<ALLOWEDVALUES>

<GLOBALLIST name="Bug.Reasons.Active" />

</ALLOWEDVALUES>

</WHEN>

<WHEN field="System.State" value="Ready to Test">

<DEFAULT from = "value" value = "Completed" />

<REQUIRED />

<ALLOWEDVALUES>

<GLOBALLIST name="Bug.Reasons.ReadyToTest" />

</ALLOWEDVALUES>

</WHEN>

<WHEN field="System.State" value="Resolved">

<DEFAULT from = "value" value = "Completed" />

<REQUIRED />

<ALLOWEDVALUES>

<GLOBALLIST name="Bug.Reasons.Resolved" />

</ALLOWEDVALUES>

</WHEN>

</FIELD>

</FIELDS>

<WORKFLOW>

<STATES>

<STATE value="Active">

<FIELDS>

<FIELD refname="Microsoft.VSTS.Common.ClosedDate">

<EMPTY />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ClosedBy">

<EMPTY />

</FIELD>

</FIELDS>

</STATE>

<STATE value="Ready to Test" />

<STATE value="Resolved" />

</STATES>

<TRANSITIONS>

<TRANSITION from="" to="Active">

<REASONS>

<DEFAULTREASON value="New" />

</REASONS>

<FIELDS>

<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">

<COPY from="currentuser" />

<VALIDUSER />

<REQUIRED />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">

<SERVERDEFAULT from="clock" />

</FIELD>

<FIELD refname="System.AssignedTo">

<DEFAULT from="currentuser" />

</FIELD>

</FIELDS>

</TRANSITION>

<TRANSITION from="Active" to="Ready to Test">

<REASONS>

<DEFAULTREASON value="Completed" />

</REASONS>

<FIELDS>

<FIELD refname="System.AssignedTo">

<DEFAULT from="currentuser" />

</FIELD>

</FIELDS>

</TRANSITION>

<TRANSITION from="Ready to Test" to="Active">

<REASONS>

<DEFAULTREASON value="Reactivated" />

</REASONS>

<FIELDS>

<FIELD refname="System.AssignedTo">

<DEFAULT from="currentuser" />

</FIELD>

</FIELDS>

</TRANSITION>

<TRANSITION from="Ready to Test" to="Resolved">

<REASONS>

<DEFAULTREASON value="Test Passed" />

</REASONS>

<FIELDS>

<FIELD refname="Microsoft.VSTS.Common.ClosedDate">

<SERVERDEFAULT from="clock" />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ClosedBy">

<COPY from="currentuser" />

<VALIDUSER />

<REQUIRED />

</FIELD>

<FIELD refname="System.AssignedTo">

<DEFAULT from="currentuser" />

</FIELD>

</FIELDS>

</TRANSITION>

<TRANSITION from="Resolved" to="Active">

<REASONS>

<DEFAULTREASON value="Reactivated" />

</REASONS>

<FIELDS>

<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">

<COPY from="currentuser" />

<VALIDUSER />

<REQUIRED />

</FIELD>

<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">

<SERVERDEFAULT from="clock" />

</FIELD>

</FIELDS>

</TRANSITION>

</TRANSITIONS>

</WORKFLOW>

This field is read-only until System.State gets changed; once System.State gets changed, reason will be overwritten by DEFAULTREASON rule.

Are you saying that you cannot edit and save a work item which has an obsolete reason?

Thanks,

Alex

No, I just added the <ALLOWEXISTINGVALUE> rule to the defintion of System.Reason, like this

<FIELD name="Reason" refname="System.Reason" type="String" reportable="dimension">
<HELPTEXT>The reason why the defect is in the current state.</HELPTEXT>
<ALLOWEXISTINGVALUE />
</FIELD>

Witimport then returns

Error: TF26062: Rule '<ALLOWEXISTINGVALUE />' is not supported for the field 'System.Reason'.

What is the reasoning behind making this field readonly until a state change? In our process there are mulitple values of reasons within a certain state.

For example, in our process,

In Active state for a work item type Suggestion we have New, Reviewing, and Accepted. For Resoloved we have Duplicate, Won't Do, and Implemented. The Dev, or QA needs to be able to change the reason even if they are not changing the state.

The reason is that the rule defining list of allowed reasons is scoped to a state transition. Once the work item is saved, we lose the information about its previous state (for perf reasons), so we cannot figure out which list of values to use.

Imagine the following situation: your type has 3 states: State A, State B, and State C; for transition State A => State B valid reasons are Reason A-B-1 and Reason A-B-2. For transition State C => State B valid reasons are Reason C-B-1 and Reason C-B-2. Your work item is currently in State B. What are valid reasons for that work item?

Thanks,

Alex

Maybe its just my thinking on how this would work. I am not looking at the general viewpoint that you guys might have but a very specific viewpoint.

I don't care what the previous state is. I have a list of allowed values per state. Once in that state I want the user to be able to change the reason within a defined set of reasons for that state.

Using your example:

State A:

<AllowedValues>

New

</AllowedValues>

State B:

<AllowedValues>

A-B-1

A-B-2

</AllowedValues>

State C:

<AllowedValues>

C-B-1

C-B-2

</AllowedValues>

As far as I am concerned the Transition only gives me a defaultvalue and a list of possible choices. I want to be able to change to another reason with in my defined set of reasons without changing the state again. But I can't do this with System.Reason because once it is saved it becomes readonly.

Like I said, maybe its my limited understanding on why this field exists. I ended up making my own that works perfectly fine the way I descibed it.

System.Reason was designed for explaining why certain transition occured - i.e. someone must have a reason for moving a work item from one state to another, and this reason would be stored in that field. What you want is the reason to be in that state. And it was totally OK that you've added a new field & rules to adjust the work item type for your needs - after all, we were trying to make the type definition customizeable, and our default workflow doesn't fit your needs.

Thanks,

Alex

I'm still not completely with you about reasons and states.
As an example I look at the factory definition of a task for the MSF Agile Process.
This has an Active-Closed transition with following reasons: Completed, Deferred, Cut, Obsolete.
I think it's not hard to find a scenario that requires an Active-Closed transition with "Deferred" reason, but at some later moment in time, it is deciced that the task will be cut.
In order to accomplish this, you have to change states twice: from Closed to Active with reason 'Reactived" and then from Active to Closed with reason 'Cut.
This is not very 'performant' for the user.

This is one of the main reasons we hated other bug tracking tools. Too many steps to transition states. At least with TeamSystem we can make our own fields and workflow.

Obviously there must be a large percentage of people out there that are very happy with the way MS has designed the State and Reason fields. We might just be the small minority.