I have custom field of string type in TFS work item with allowed values: "Yes", "No", And "Probably".
<FIELD reportable="dimension" type="String" name="Help Authoring"
refname="Custom.HelpAuthoring">
<HELPTEXT>Should 'Help Authoring' team to update own stuff</HELPTEXT>
<ALLOWEDVALUES>
<LISTITEM value="Yes" />
<LISTITEM value="No" />
<LISTITEM value="Probably" />
</ALLOWEDVALUES>
<DEFAULT from="value" value="No" />
</FIELD>
After importing work item into TFS project the 1st symbol case of "Probably" was changed to lower case. So now it is "probably". It looks ugly. while "Yes" and "No" are still in "Camel"-format.
Q1. Why allowed field value is changed?
Q2. How to prevent that?
P.S. To have values consistent I've tried to change "Yes" and "No" to "yes" and "no" but after importing they left in 'Camel'...
Unfortunately, once a constant like this is imported into work items for a Team Project Collection, it's there to stay. If you feel strongly about this, log a bug with Microsoft on the Visual Studio Connect site.
One possible(?) workaround is to create a global list with the values that you want, then use that for the ALLOWEDVALUES.
<?xml version="1.0" encoding="utf-8"?>
<gl:GLOBALLISTS xmlns:gl="http://schemas.microsoft.com/VisualStudio/2005/workitemtracking/globallists">
<GLOBALLIST name="Help Authoring Values">
<LISTITEM value="Yes" />
<LISTITEM value="No" />
<LISTITEM value="Probably" />
</GLOBALLIST>
</gl:GLOBALLISTS>
Use witadmin importgloballist /collection:http://yourserver:8080/tfs/collection /f:FileName to import it.
Then in the work item type, replace your <LISTITEM>'s with:
<ALLOWEDVALUES>
<GLOBALLIST name="Help Authoring Values" />
</ALLOWEDVALUES>
Related
I have a custom TFS form. In this form i need to add a check box as
Select test:
Test1
Test2
Test3
Test1, Test2 and Test3 should be check box controls and the user can select any number of check boxes. How can I achieve this in TFS? I installed a code plex project http://witcustomcontrols.codeplex.com/
But there is no documentation on how I can use the controls or samples.
The download file from http://witcustomcontrols.codeplex.com/ contains an installer for the Windows controls and a .zip file for the Web Access controls.
To install windows control:
Simply run the msi setup and restart Visual Studio.
Fields associated with multivalue control should have list of suggested values and each value enclosed in square brackets. For example:
<FIELD name="Triage" refname="Microsoft.VSTS.Common.Triage" type="String" reportable="dimension">
<HELPTEXT>Status of triaging the bug</HELPTEXT>
<SUGGESTEDVALUES expanditems="false">
<LISTITEM value="[Approved]" />
<LISTITEM value="[Investigate]" />
<LISTITEM value="[Rejected]" />
<LISTITEM value="[Submit]" />
</SUGGESTEDVALUES>
</FIELD>
Then use MultiValueControl as controltype for that field in Form section, for example:
<Control Type="MultiValueControl" FieldName="Microsoft.VSTS.Common.Triage" Label="Triag&e:" LabelPosition="Left" />
Check: http://witcustomcontrols.codeplex.com/wikipage?title=MultiValue%20Control
To install web control:
Navigate in your browser to the configuration panel for the web
extension of TFS: http://servername:8080/tfs/_admin/_extensions
Click on the Install and upload the CodePlex.WitCustomControls.MultiValueControl.zip-file, make
sure to use the .zip file matching you TFS server version.
Enable the extension.
Check: http://witcustomcontrols.codeplex.com/releases/view/616048
As of the recent release of TFS 2015 Update 2, this can be done with the witd in on-prem TFS like this (example is from a Bug).
Definition:
<FIELD name="CustomerReported" refname="X.X.CustomerReported" type="Boolean" reportable="dimension">
<DEFAULT from="value" value="True" />
</FIELD>
Layout:
<Control FieldName="X.X.CustomerReported" Type="FieldControl" Label="Customer Reported" LabelPosition="Left" />
I currently have a TFS process template using a Bug Work Item type that contains the "Found In" and "Integration Build" fields.
They are defined like this in the work item definition XML file :
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
<HELPTEXT>The build in which the bug was fixed</HELPTEXT>
<SUGGESTEDVALUES expanditems="true">
<LISTITEM value="<None>" />
</SUGGESTEDVALUES>
</FIELD>
<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
<HELPTEXT>The build in which the bug was found</HELPTEXT>
<SUGGESTEDVALUES expanditems="true">
<LISTITEM value="<None>" />
</SUGGESTEDVALUES>
<REQUIRED />
</FIELD>
I wanted to use the auto-populated builds global list so I added the following lines as suggested on msdn :
<SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
<GLOBALLIST name="Builds - ProjectXYZ" />
</SUGGESTEDVALUES>
But I would like to share the same work item definition for ALL our projects. So my question is really simple, is there a way to replace "ProjectXYZ" by a variable that contains the name of the project that is using the work item definition ?
Basically this is what I would like :
<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
<HELPTEXT>The build in which the bug was found</HELPTEXT>
<SUGGESTEDVALUES expanditems="true">
<LISTITEM value="<None>" />
</SUGGESTEDVALUES>
<SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
<GLOBALLIST name="Builds - ${TeamProjectName}" />
</SUGGESTEDVALUES>
<REQUIRED />
</FIELD>
No it is not possible to use a variable there.
If you don't have many team projects you could use a when clause for each team project.
This would only work if you only had a few projects as It would get cumbersome otherwise.
On a work item I've got 2 combos where the 2nd combo's values are dependent on the 1st.
e.g. The 1st combo has 2 allowedvalues ("vowels", "consonants"), 2nd combo would show a,e,i,o,u if the first was set to vowels etc.
Any idea how I can do this?
someting like dis works
<FIELD name="Response" refname="Response" type="String" > <!-- values change depending on Category-->
<WHEN field="Category" value="1">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="111" />
<LISTITEM value="1111" />
</ALLOWEDVALUES>
</WHEN>
<WHEN field="Category" value="2">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="222" />
<LISTITEM value="2222" />
</ALLOWEDVALUES>
</WHEN>
</FIELD>
While you can do this it does not work with large lists as you can quickly hit the maximum limit for the size of a work item. It is not really a recommended practice.
On vs2013: tools > process editor > work item types > open WIT from server.
By editing the Task work item rules, I have come out with the following xml item definition:
<FieldDefinition name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure">
<WHENCHANGED field="Microsoft.VSTS.Scheduling.OriginalEstimate">
<COPY for="[global]\Project Collection Valid Users" from="field" field="Microsoft.VSTS.Scheduling.OriginalEstimate" />
</WHENCHANGED>
</FieldDefinition>
What I am trying to achieve is sth more like this:
<FieldDefinition name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure">
<WHENCHANGED field="Microsoft.VSTS.Scheduling.OriginalEstimate">
<WHEN field="Microsoft.VSTS.Scheduling.RemainingWork" value="">
<COPY for="[global]\Project Collection Valid Users" from="field" field="Microsoft.VSTS.Scheduling.OriginalEstimate" />
</WHEN>
</WHENCHANGED>
</FieldDefinition>
The problem is what I have now is not working for me (whenever I change Original Estimate, Remaining Work is not being updated), and I can't figure out how to stick in the WHEN clause.
I finally changed the Task tfs field definition for my project, via witadmin export/import:
On a Developer Command Prompt for VS2013
> witadmin exportwitd /collection:http://myTFSserver:8080/tfs/DefaultCollection /p:myTFSProject /n:Task /f:"c:\tfs\Task.xml"
replace the relevant section on Task.xml
<FIELD name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure" formula="sum">
<WHENCHANGED field="Microsoft.VSTS.Scheduling.OriginalEstimate">
<COPY for="[global]\Project Collection Valid Users" from="field" field="Microsoft.VSTS.Scheduling.OriginalEstimate" />
</WHEN>
</FIELD>
with
<FIELD name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure" formula="sum">
<WHEN field="Microsoft.VSTS.Scheduling.RemainingWork" value="">
<COPY from="field" field="Microsoft.VSTS.Scheduling.OriginalEstimate" />
</WHEN>
</FIELD>
then convey the change
> witadmin importwitd /collection:http://myTFSserver:8080/tfs/DefaultCollection /p:myTFSProject /f:"c:\tfs\Task.xml"
I can't think of a way to do what you want with just WITD.
Another (more complex) option is to create an ISubscriber plug-in that you deploy to your TFS. It can detect whenever your work items are changed and update fields appropriately using any logic you can write in C#.
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.