I want to use a custom datetime attribute to track, when an item entered a given state for the first time (serverdefault:clock).
To avoid later manipulation, this custom field at the same time should be set to readonly for everyone.
It seems however that in all combinations I come up with the "readonly" takes precedence and immediat es ly blocks the "serverdefault" that seems to be executed with the rights of the user iniziating tha transition.
For e.g. "created date" however the behavior seems possible for the system itself ...
Is there a way to achieve the same behavior for custom fields?
You can define your field like this:
<FIELD name="Custom Date" refname="My.CustomDate" type="DateTime">
<WHENNOTCHANGED field="System.State">
<READONLY />
</WHENNOTCHANGED>
</FIELD>
and then add this XML to the TRANSITION node for the given state:
<TRANSITION from="Resolved" to="Closed">
<FIELDS>
<FIELD refname="My.CustomDate">
<SERVERDEFAULT from="clock" />
</FIELD>
</FIELDS>
</TRANSITION>
Related
I have a need to set the value of a date field when the value of substate field changes only if no value already exists in the date field. Is it possible?
<FIELD refname="MyCorp.StateDate" name="Date Of Last State Change" type="DateTime">
<WHENCHANGED field="MyCorp.State">
<COPY from="clock" /> ** AND do this only of MyCorp.StateDate != Empty **
</WHENCHANGED>
</FIELD>
I read https://msdn.microsoft.com/en-us/library/ms194966.aspx but I am not able to find any way to implement what I need from the WIT language definition.
If you are using Visual Studio Team Services, add rules to work item is not supported now.
If you are using on-premise TFS, you can add field action in state transition, for example:
<TRANSITION from="New" to="Committed">
<REASONS>
<DEFAULTREASON value="Commitment made by the team" />
</REASONS>
<FIELDS>
<FIELD refname="starain.ScrumStarain.StateChageDate">
<WHEN field="starain.ScrumStarain.StateChageDate" value="">
<COPY from="clock" />
</WHEN>
</FIELD>
</FIELDS>
</TRANSITION>
I am modifying a workflow in TFS 2013 and have bumped into a snag. Right now, when a developer completes their work and moves the work item into 'dev complete' I set the name of the developer moving the work item to a custom field as a string:
MYCOMPANY.Agile.Lean.CodeCompleteBy
<FIELD name="Code Completed By" refname="MYCOMPANY.Agile.Lean.CodeCompleteBy" type="String" reportable="dimension" syncnamechanges="true">
<ALLOWEXISTINGVALUE />
<HELPTEXT>The developer who wrote code related to this work item.</HELPTEXT>
</FIELD>
And here is the transition:
<TRANSITION from="Development in Progress" to="Code Review">
<REASONS>
<DEFAULTREASON value="Ready for Code Review" />
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<DEFAULT from="currentuser" />
</FIELD>
<FIELD refname="MYCOMPANY.Agile.Lean.CodeCompleteBy">
<DEFAULT from="currentuser" />
</FIELD>
</FIELDS>
</TRANSITION>
As the process continues the item eventually reaches QA. IF the QA person finds a problem and rejects the work then I have a transition to move the work item back into the 'Development in Progress' state. All of that works fine.
The Problem
I want to re-assign the work item, upon transition from QA in Progress back to Development in Progress, back to the original developer who did the work.
<TRANSITION from="QA in Progress" to="Development in Progress">
<REASONS>
<REASON value="Requirements Not Met" />
<REASON value="Rejected" />
<DEFAULTREASON value="Failed Testing" />
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<DEFAULT from="MYCOMPANY.Agile.Lean.CodeCompleteBy" />
</FIELD>
</FIELDS>
</TRANSITION>
Unfortunately, when I attempt to apply my new WIT transitions it throws the following error:
TF212019: Work item tracking schema validation error at row 931, column 24: The 'from' attribute is invalid - The value 'MYCOMPANY.Agile.Lean.CodeCompleteBy' is invalid according to its datatype 'http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typelib:CopyFrom' - The Enumeration constraint failed.
TF237070: Importing the definition failed. The definition you are trying to import did not validate against the schema. Edit the definition, then try to import it again.
I see that this is an Enumeration constraint issue, but I'm not familiar enough with TFS internal workings to know how to get around the problem.
Does anyone have a slick way of accomplishing what I am trying to do (even if I just need a completely new approach)? I may just be going down the wrong path altogether.
Thanks!
Instead of using the default which will simply try and set that as the value, try using the Copy rule.
Something like this:
<TRANSITION from="QA in Progress" to="Development in Progress">
<REASONS>
<REASON value="Requirements Not Met" />
<REASON value="Rejected" />
<DEFAULTREASON value="Failed Testing" />
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<COPY from="field" field="MYCOMPANY.Agile.Lean.CodeCompleteBy" />
</FIELD>
</FIELDS>
</TRANSITION>
Update the syntax like following:
<DEFAULT from="field" field="MYCOMPANY.Agile.Lean.CodeCompleteBy"/>
Refer to this link for details: Define a default value or copy a value to a field
I have a user who is attempting to change the State of a TFS Change Request from Development to Testing but when he presses Save gets the following error:
Save failed: The field 'Changed By' contains a value that is not in the list of supported values
From what I can work out (please correct me if I'm wrong) Changed By relates to the History tab showing what has changed on the item.
So I've Exported the Work Item Types for our project, and opened the XML for Change Requests. When I searched for Test the State is listed as this:
<STATE value="Test">
<FIELDS>
<FIELD refname="System.AssignedTo">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="[project]\Contributors" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</STATE>
And the Transition from Development to Test is as follows:
<TRANSITION from="Development" to="Test">
<REASONS>
<DEFAULTREASON value="Signed Off" />
<REASON value="Executive Signed Off" />
</REASONS>
<FIELDS>
<FIELD refname="System.ChangedBy">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="[project]\Owners" />
</ALLOWEDVALUES>
</FIELD>
<FIELD refname="System.AssignedTo">
<REQUIRED />
</FIELD>
</FIELDS>
</TRANSITION>
I have checked both groups ([project]\Owners and [project]\Contributors). They are not a member of the Contributors group, but I checked another user who isn't having this issue and they are not either, so I think I can rule out that permissions group? And the Owners group has them listed (albeit under the group for their team) so I think that is correct.
The Field called ChangedBy populates from the Owners group and the user appears in that list (when checked from another point).
What could be causing this save issue? Am I missing something obvious?
Based on that XML, that says that only people in the Contributors group can save a WI in the Test state. If your user isn't a contributor that explains the error.
Try adding your user the Contributor group and try again.
Is it possible to assign DEFAULT rule for DateTime Field while adding a Work Item in TFS? But not using CLOCK value. Giving some Default Date.
Yes, you can do this by hardcoding the value in the Work Item Type Definition. In the appropriate TRANSITION element under the FIELDS\FIELD element for that field, instead of using ServerDefault and clock which you have probably seen like this:
<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
try doing this:
<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
<COPY from"value" value="01-Feb-2014" />
</FIELD>
It is possible, try this:
<FIELD name="Custom Date" refname="Custom.Date" type="DateTime">
<DEFAULT from="value" value="2100-01-01" />
</FIELD>
The date that will be displayed is a day before of whatever date you're setting.
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"
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.