I am working on a custom work item template for TFS 2012. Currently "System.State" has 3 states "Active", "Approved", "Completed", in order to select "Completed", the System.State has to be set to "Approved". However, there are certain scenarios where the template should skip "Approved" and transition from "Active" to "Completed". I want to allow the user to skip approved if another field ("Sample.Field") equals "Skip". I have tried adding the following WHEN rule but it doesn't work. Has anyone done this before or have a work around? Thanks,
<FieldDefinition name="State" refname="System.State" type="String" reportable="dimension">
<WHEN field="Sample.Field" value="Skip;">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="Active" />
<LISTITEM value="Completed" />
</ALLOWEDVALUES>
</WHEN>
</FieldDefinition>
That would be done in the <TRANSITION> statement. But I don't think it is possible to condition a transition on states; the only allowed ones are for and not user groups. The sub-statements control behavior of fields for the transition. http://msdn.microsoft.com/en-us/library/aa337653.aspx.
Related
Currently working on customizing work items in Team Foundation Server.
So Bug/Product Backlog Item has the Priority field:
<FIELD name="Priority" refname="Microsoft.VSTS.Common.Priority" type="Integer" reportable="dimension">
<HELPTEXT>Business importance. 1=must fix; 4=unimportant.</HELPTEXT>
<DEFAULT from="value" value="2" />
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="1" />
<LISTITEM value="2" />
<LISTITEM value="3" />
<LISTITEM value="4" />
</ALLOWEDVALUES>
</FIELD>
Then I created a custom control for the work item deadline:
<FIELD name="Deadline" refname="Custom.Controls.Deadline" type="DateTime" reportable="dimension" />
What I want to do is set the value of the deadline base on the chosen priority. This should be editable if the user wishes to.
e.g. if priority is 1 deadline should be 2 day from current date,
if priority is 2 deadline should be 3 days from current date and so on.
I was able to add the field in the screen but stuck on how to make custom logic like mentioned above. Any small nudge to the right direction would greatly help.
TFS version is Team Foundation Server 2018 on premise (not Azure DevOps).
First to say, there is no build in due-date field for Bug/Product Backlog Item. Actually the comment is only half correct.
It's not hard to use a combination of WHEN conditions and COPY rules to Automatically change a field based on another in TFS .
But that value is statically. What you need is a dynamic work item field (item start date+ x days). It need to calculate a field, which is not available at present:
Support for calculated fields and roll-ups
https://developercommunity.visualstudio.com/idea/365423/support-calculated-fields-in-tfs.html
Otherwise, you have to use TFSAggregator. This plugin will allow you to calculate the fields.
Example: Calculate Fields
I need help in TFS work item customization please.
Here is the scenario:
I have fields called “Priority” (Ref Name: ‘ABC.VSTS.Common.Priorities’) and “State” (Ref name: ‘System.State’)
Priority has drop down list of (ALLOWEDVALUES):
High,
Medium,
Low,
Minor,
Urgent,
Emergency.
State transitions are as follows:
Closed,
Approved,
Rejected,
Completed,
In Progress,
Cancelled,
Submitted.
Pending mgr Approval.
What I’m looking is, When user picks ‘Urgent’, I want to see state filed values ‘Submitted’, ‘Approved’, and ‘Rejected’. I don’t want to see other remaining status values.
Similarly When I pick Minor, I want to see only ‘Submitted’ and ‘Completed’. I tried several ways but could not figure out. All status values are showing up always.
Have you tried the conditional rules in TFS?
<FIELD refname="MyCorp.Severity" name="Customer Severity" type="String">
<ALLOWEDVALUES>
<LISTITEM value="Blocking" />
<LISTITEM value="Major" />
<LISTITEM value="Minor" />
</ALLOWEDVALUES>
<WHEN field="MyCorp.CustomerReported" value="true">
<REQUIRED />
</WHEN>
</FIELD>
I am using TFS 2010.
My requirement is to set allowed values for a field based on two conditions.
I have tried using nested WHEN, but i got error and i found in the forums that it is not possible.
How can I achieve this?
Field ‘Step’ value of “Code Review” and the field ‘Test Group’ value was “UAT only”, then the selection in the field ‘Step’ drop down would be “Code Review”, “Unit Test”, or “UAT”
Field ‘Step’ value of “Requirement”, then have the selections in the drop down box “Requirement”, or “Design”
For Example
<FieldDefinition name="Assigned To" >
<WHEN field="System.AreaId" value="9">
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<LISTITEM value="1" />
</ALLOWEDVALUES>
</WHEN>
<WHEN field="System.StateId" value="103">
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<LISTITEM value="2" />
</ALLOWEDVALUES>
</WHEN>
</FieldDefinition>
In the above XML, System will check OR condition either Area ID = 9 or StateID = 103. But my requirement is to check AND condition, if both the condition satisifies, then i have to set few allowedvalues.
The way I typically handle this is just to combine the 2 fields into one, and give all possible combinations as allowed values.
So for example you might have a drop-down with the following choices:
UAT Only - Code Review
UAT Only - Unit Test
UAT Only - UAT
Requirement - Requirement
Requirement - Design
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.
I have a weird problem with the configuration of TFS 2010 work items. It seems to be impossible to change the case of characters in the allowed values collection of a field e.g. change "Works for me" to "Works For Me". Every other string e.g. "Works For Me 123" is valid.
Even if I try to change the name to another string first (since i know the similar case problem with files in Visual Studio projects) it is just not accepting the upper case version and returns always to the lower case string.
Background information:
We have a custom WIT file to define the "Bug" work item. This includes the definition of the allowed values for the field "Resolved Reason". Initially our list contained lower case words e.g. "Works for me". Since we want to synchronize the TFS work items with HP Quality Center we need an exact match of the state names now.
The desired version:
<FIELD name="Resolved Reason" refname="Microsoft.VSTS.Common.ResolvedReason" type="String" reportable="dimension">
<HELPTEXT>The reason why the bug was resolved</HELPTEXT>
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="Duplicate" />
<LISTITEM value="Fixed" />
<LISTITEM value="Wont Fix" />
<LISTITEM value="Invalid" />
<LISTITEM value="Works For Me" />
<LISTITEM value="Forwarded" />
</ALLOWEDVALUES>
</FIELD>
The actual version:
<FieldDefinition reportable="dimension" refname="Microsoft.VSTS.Common.ResolvedReason" name="Resolved Reason" type="String">
<ALLOWEDVALUES>
<LISTITEM value="Duplicate" />
<LISTITEM value="Fixed" />
<LISTITEM value="Wont fix" />
<LISTITEM value="Invalid" />
<LISTITEM value="Works for me" />
<LISTITEM value="Forwarded" />
</ALLOWEDVALUES>
<HELPTEXT>The reason why the bug was resolved</HELPTEXT>
</FieldDefinition>
Any ideas are welcome.
Thanks,
Robert
As Grant explained, the old work items are stuck with the old casing.
A manual workaround would be to create a new ListItem with the desired case (leaving the old one in the definition for now), edit the existing work items that contain the undesired case to the newly created ResolvedReason, and finish by removing the undesired item from the definition. I have done a similar thing in the past, but not specifically a case change.
If you are familiar with the TFS API (I'm not), you can programmatically update the Microsoft.VSTS.Common.ResolvedReason field values on the server. If you have access to the SQL Server 2008 instance, you might be able to edit the field values there to the new case (many layers of bureaucracy prevent me from testing this for you).
Once a string in a work item type is created with a particular casing, it is stuck with that.