We're using a heavily customised set of TFS WorkItem Types for our development process.
One such type has a boolean field on it, however when we go to set this field you have to type in either "True" or "False", this is frustrating and I'd much rather have a checkbox or a set of suggested values we can pick from. Here's the field xml:
<FieldDefinition name="My Field" refname="My.BooleanField" type="Boolean">
<SUGGESTEDVALUES expanditems="true">
<LISTITEM value="True" />
<LISTITEM value="False" />
</SUGGESTEDVALUES>
</FieldDefinition>
However this doesn't work.
I was hoping I could change the control from a FieldControl to something more user friendly (like you can with DateTimes) but again I've had no success.
Is there a way I can create a boolean field on a TFS WorkItemType which doesn't require the user to type "True" or "False" or do I have to set it as a string to use Suggested Values?
You could change <SUGGESTEDVALUES> to <ALLOWEDVALUES>. That tells the FieldControl to render a dropdown box:
<ALLOWEDVALUES>
<LISTITEM value="true" />
<LISTITEM value="false" />
</ALLOWEDVALUES>
That should make your life easier. Type Boolean is not an available field type, so you'll have to use string as the underlying data type. Check the field definition:
type="String | Integer | Double | DateTime | PlainText | HTML | History | TreePath | GUID"
So you'll end up with:
<FieldDefinition name="My Field" refname="My.BooleanField" type="String">
<ALLOWEDVALUES>
<LISTITEM value="true" />
<LISTITEM value="false" />
</ALLOWEDVALUES>
</FieldDefinition>
A checkbox control is currently only available by deploying a custom control to the machine of all your users. There's a lot of demand for this feature, I'd expect Microsoft to support it in the future in in the form of the new Process Customization features that are available on Visual Studio Team Services.
It only took 5 years and 3 major TFS versions, but the Checkbox control is finally part of the available Field Types!
With TFS 2015.2 you'll be able to chose the boolean type for a field.
The documentation does not include the change as of July '16 but this blog post confirms it.
Be aware that some important rules are not supported by this field type, such as "MATCH", "ALLOWEDVALUES" and "PROHIBITEDVALUES".
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 am trying to edit work item templates to make use of the new Boolean field in TFS 2017, and want a particular field to be set to true before a status can be changed. Is there any way to do this? It would appear ALLOWEDVALUES and MATCH aren't supported, which could have potentially helped
You can do that by applying a conditional rule based on your requirement just as Hamid mentioned above.
Boolean is just a data type, we can add a custom Boolean field and add a checkbox for it.
Use the following syntax to add a Boolean field within the FIELDS
section of the WIT definition.
<FIELD name="Triagelc" refname="lc.Triage" type="Boolean" >
<DEFAULT from="value" value="True" />
<HELPTEXT>Triage work item</HELPTEXT>
</FIELD>
And then add the following syntax within the FORM section to have
the field appear on the form.
<Control Label="Triagelc" Type="FieldControl" FieldName="lc.Triage" />
The field will appear as a checkbox on the form.
Then apply a When rule for target filed, thus when the specified
Boolean field has the specified value, the When rule is applied to
the target field.
eg1:
Apply a "When" rule for Description field in Task work item type :
<FieldDefinition name="Description" refname="System.Description" type="HTML">
<WHEN field="lc.Triage" value="True">
<REQUIRED />
</WHEN>
</FieldDefinition>
Then when set the value to True, the Description area is required, it cannot be empty.
eg2:
You can also use READONLY rule to restrict other areas:
<FieldDefinition name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
<WHEN field="lc.Triage" value="True">
<READONLY />
</WHEN>
<ALLOWEXISTINGVALUE />
<HELPTEXT>The person currently owning this task</HELPTEXT>
</FieldDefinition>
Thus, when the Boolean field value is True, Assigned To field is read only, otherwise you can assign to the existing users.
UPDATE:
eg3:
We can not achieve that directly with the boolean data type. As a workaround you can try below ways:
Apply the When rule and embed the Copy rule (Copy True as the
value) for the "Triagelc" boolean field in this example. Thus when
the status is Done, Triagelc can set the value to "True"
automatically, then save. But in this way the value still can be
modified to false. Reference below screenshot 1:
<FieldDefinition name="Triagelc" refname="lc.Triage" type="Boolean">
<WHEN field="System.State" value="Done">
<COPY from="value" value="True" />
</WHEN>
<HELPTEXT>Triage work item</HELPTEXT>
</FieldDefinition>
Set the default value to True for Boolean field (Triagelc
field in this example), then apply When rule with READONLY rule
embedded. This way should be meet your requirement (Once done the value cannot be changed anymore). Reference below screenshot 2:
<FieldDefinition name="Triagelc" refname="lc.Triage" type="Boolean">
<DEFAULT from="value" value="True" />
<WHEN field="System.State" value="Done">
<READONLY />
</WHEN>
<HELPTEXT>Triage work item</HELPTEXT>
</FieldDefinition>
Please note that:
The Boolean data type field is only supported for VSTS and TFS 2017.2
and later versions.
Screenshot 1:
Screenshot 2:
In my WITD, I have some xml like this in my FIELD tag:
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="Yes" />
<LISTITEM value="No" />
</ALLOWEDVALUES>
<DEFAULT from="value" value="No" />
I can get the allowed values from the API by getting an instance of class FieldDefinition and referencing the AllowedValues property.
How can I get the DEFAULT tag's value from the Api?
You could create a new work item with a work item type that has your field and then check the value of the field on the new work item. You don't need to save the work item to check the field value. It should contain the default value you are after.
There's no API for retrieving default values. Another approach is to parse the value from the WITD XML using WorkItemType.Export Method
var xml = wit.Export(false);
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 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.