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" />
Related
Noticed StateChanged field is missing within XML definitions of some work items in scrum template of tfs 2017 RTM : pbi, testplan, testsuite, feebackrequest, codereviewrequest, and some more.
I assume i should add it manually to them. Right ?
If you mean the State Change Date field, yes, by default it's not added in some work items in scrum template.
Actually the control is not added to layout eventhough in the existing work items such as Bug, Feature. That means, you cannot see the field in work item layout. However you can add the control to display the field based on your requirements.
Yes, you can also add the State Change Date field manually to the work items which not exsiting in them. See Add a field, or apply a rule, or change an attribute for details.
You can also use the TFS Process Template Editor to edit the WITs definitions.
Field:
<FieldDefinition name="State Change Date" refname="Microsoft.VSTS.Common.StateChangeDate" type="DateTime">
<WHENCHANGED field="System.State">
<SERVERDEFAULT from="clock" />
</WHENCHANGED>
<WHENNOTCHANGED field="System.State">
<READONLY />
</WHENNOTCHANGED>
</FieldDefinition>
Layout Control:
<Group Label="Status">
<Column PercentWidth="100">
<Control FieldName="Microsoft.VSTS.Common.StateChangeDate" Type="DateTimeControl" Label="State Change Date:" LabelPosition="Left" />
</Column>
</Group>
Page Section:
<Section>
<Group Label="Status">
<Control Label="State Change Date:" Type="DateTimeControl" FieldName="Microsoft.VSTS.Common.StateChangeDate" />
</Group>
</Section>
In TFS 2010 a requirement work item had also an implementation and a change request tab.
In TFS 2012 the requirement work item also had an implementation and change request tab as written in the documentation, but the picture of a newly created requirement doesn't show anymore these tabs.
Now, in TFS 2015 those two tabse aren't mentioned any more, though the CMMI process shows the work item hierachy as
Epic > Feature > Requirement > Task
I am missing the implementation and change request tab in the standard configuration the CMMI project, because they are very useful in tracking the whole work from defining the features down to the requirements and their implementation with testing as well as subsequent change requests.
Are there any ways to get back these tabs in the standard configuration? I don't like to change the predefined work item types, because you never now what happens with next upgrades of TFS.
I had to go back all the way to 2010 to find the tab definitions you're missing. You can't "configure" TFS to show additional tabs without changing the process definition. To add them back in you have two options.
Create a custom template.
Patch the Requirement form definition after project creation.
The latter option should work well in combination with the way exiting process templates are "upgraded" using the Feature Activation Wizard, though with the new Work Item Form's and the new way Process template customization is done on Visual Studio Team Services, it would not surprise me when the next version of TFS will require manual intervention after upgrade.
1. Create a custom template
Download the CMMI process template from TFS using Visual Studio, update the process template definition (ProcessTemplate.xml) file and give it a new name and GUID:
Then go to the WorkItem Tracking\TypeDefinitions folder and edit the Requirement.xml. Add the two old tabs and link controls back in:
<Tab Label="Implementation">
<Control Type="LinksControl" Name="HierarchyForm" LabelPosition="Top">
<LinksControlOptions>
<WorkItemLinkFilters FilterType="include">
<Filter LinkType="System.LinkTypes.Hierarchy" />
</WorkItemLinkFilters>
<WorkItemTypeFilters FilterType="include">
<Filter WorkItemType="Requirement" />
<Filter WorkItemType="Task" />
</WorkItemTypeFilters>
<ExternalLinkFilters FilterType="excludeAll" />
<LinkColumns>
<LinkColumn RefName="System.ID" />
<LinkColumn RefName="System.WorkItemType" />
<LinkColumn RefName="System.Title" />
<LinkColumn RefName="System.AssignedTo" />
<LinkColumn RefName="System.State" />
<LinkColumn LinkAttribute="System.Links.Comment" />
</LinkColumns>
</LinksControlOptions>
</Control>
</Tab>
<Tab Label="Change Requests">
<Control Type="LinksControl" Name="ChangeRequestsForm" LabelPosition="Top">
<LinksControlOptions>
<WorkItemLinkFilters FilterType="include">
<Filter LinkType="Microsoft.VSTS.Common.Affects" FilterOn="reversename" />
</WorkItemLinkFilters>
<WorkItemTypeFilters FilterType="include">
<Filter WorkItemType="Change Request" />
</WorkItemTypeFilters>
<ExternalLinkFilters FilterType="excludeAll" />
<LinkColumns>
<LinkColumn RefName="System.ID" />
<LinkColumn RefName="System.WorkItemType" />
<LinkColumn RefName="System.Title" />
<LinkColumn RefName="System.AssignedTo" />
<LinkColumn RefName="System.State" />
<LinkColumn LinkAttribute="System.Links.Comment" />
</LinkColumns>
</LinksControlOptions>
</Control>
</Tab>
Upload the custom process template using Visual Studio and create your new Team Projects using that template.
2. Update existing Projects
Use witadmin to export the definition for the requirement work item type from an existing project:
witadmin exportwitd /collection https://server/tfs/DefaultCollection /p MyProject
/n Requirement /f Requirement.xml
Edit the XML file using your favorite text editor (I use Visual Studio Code) and add the above mentioned XML snippet back in. Now that you have a definition for Requirement with the right layout, you can push it to existing projects. First, validate your changes:
witadmin importwitd /collection https://server/tfs/DefaultCollection /v
/f Requirement.xml
If no errors are found, import the definition:
witadmin importwitd /collection https://server/tfs/DefaultCollection /p MyProject
/f Requirement.xml
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.
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>