Work items fields like "Assigned To" in TFS show way too many users by default. I understand I can limit this by editing the WIT to be more project or group specific like with the following:
<FieldDefinition name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
<ALLOWEXISTINGVALUE />
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<LISTITEM value="[project]\Contributors" />
</ALLOWEDVALUES>
<HELPTEXT>The person currently working on this bug</HELPTEXT>
</FieldDefinition>
This helps, but I'm using a structure where all projects are located in a single Team Project, so the user list is still much too large.
Is there a way to populate a string drop down (like "Assigned To") based on team, similar to how area and iteration paths populate based on what team you are creating work items under?
No this kind of customisation is not possible with TFS.
Once you have your work broken down by area and iteration, it should be easy enough to view on the backlog when planning work who will take what and if anything is assigned to someone who's not on the team.
Related
TFS defaults Area Path for new items to Parent Area, and people forget to populate it properly, with the consequence of having items wrongly assigned to parent area (we have the children areas well specified).
I've tried to set it as blank by default, so it is mandatory to populate the value before saving the item in New state, but TFS does not allow that as AreaPath is kind of "special" field.
How could I workaround this? I'm of course open to any other alternative that can work here.
Like you said, the AreaPath field is kind of "spacial" field, so we can't restrict values on this field. but there is a workaround:
1) Create a new field, for example: AreaPathValidation.
2) Find out the AreaIDs of the restricted area paths.
3) Make a rules to the new field like the following:
<FIELD name="Area Path Validation" refname="Company.AreaPathValidation" type="String">
<PROHIBITEDVALUES>
<LISTITEM value="Root Area Path" />
</PROHIBITEDVALUES>
<COPY from="value" value="No Errors" />
<WHEN field="System.AreaId" value="54">
<COPY from="value" value="Root Area Path" />
</WHEN>
</FIELD>
The 54 it's only an example to Area Path Id, change it to your root Area Path Id.
Now when the user not will change the Area Path he couldn't save the work item :)
In TFS there is possibility to link work items between each other - for example PBIs to Features, or Impediments. Does anybody know - how to make these links mandatory, so for example it will be not possible to save PBI if it was not linked to feature?
I'm using TFS2015 on premises.
According to the request, you need to set the Required rule for the links control, but as far as I know the default Links control not support Required rule.
So, as workaround you can add a hidden field, then set 'Required' rule for the hidden field, thus it will prompt that you need to link to Features or other workitems when you save the PBI without any linked workitems.
Here is the example. You could add field called Links, which is hidden field and it would have the following syntax:
<FIELD name="Links" refname="lc.RelatedWorkItems" type="Integer">
<WHEN field="System.RelatedLinkCount" value="0">
<REQUIRED />
</WHEN>
<WHENNOT value="0" field="System.RelatedLinkCount">
<DEFAULT from="field" field="System.RelatedLinkCount" />
</WHENNOT>
<HELPTEXT>This is a hidden/internal field that will help to force the user to associate the work items.</HELPTEXT>
</FIELD>
Is there a way to apply rules in a specific order?
I want to offer YesNo ONLY if two specific values are selected from another field... my rules in XML look like this:
<WHEN field="xxx.yyy.FoundInVersion" value="xxx">
<ALLOWEXISTINGVALUE />
<ALLOWEDVALUES not="[project]\xxx" expanditems="true">
<LISTITEM value="No" />
<LISTITEM value="Yes" />
</ALLOWEDVALUES>
</WHEN>
<WHEN field="xxx.yyy.FoundInVersion" value="yyy">
<ALLOWEXISTINGVALUE />
<ALLOWEDVALUES not="[project]\xxx" expanditems="true">
<LISTITEM value="No" />
<LISTITEM value="Yes" />
</ALLOWEDVALUES>
</WHEN>
<ALLOWEDVALUES not="[project]\MigrationAccounts" expanditems="true">
<LISTITEM value="No" />
</ALLOWEDVALUES>
This works. If either of the both WHENs are correct Yes and No are allowed.
But TFS somehow automatically (on the different/target instance) moves the last ALLOWEDVALUES rule to the top, and only No is allowed and selectable, even if I select one of the values "yyy" or "xxx" in the other field.
It seems to cache somewhere, or try to be intelligent or sth.
How can I force/workaround the rules to my own order?
Rules are typically processed in the sequence in which they are listed. However, when you use the WHEN*, DEFAULT, and COPY elements, additional behaviors may apply.
You can gain some idea of how rules are evaluated when you apply multiple rules to a field. How rules are evaluated is not completely deterministic. This section describes the expected behavior and interactions when you are using the WHEN*, DEFAULT, and COPY rules.
The following steps show, in the correct sequence, the interactions that TFS performs and by the user of a work-item form. Only steps 1, 8, and 13 are performed by the user.
1.From a Team Foundation client─such as Visual Studio, Team Explorer, Team Web Access, or Team Explorer Everywhere─, a user creates a new
work item or edits an existing work item.
2.Fill in field defaults. For all fields, use any DEFAULT rules that are outside WHEN* rules.
3.Copy field values. For all fields, use any COPY rules that are outside WHEN* clauses.
4.For all fields with a WHEN rule that matches, first do DEFAULT and then COPY rules inside.
5.For all fields with a WHENNOT rule that matches, first do DEFAULT and then COPY rules inside.
TFS always processes WHEN rules before WHENNOT rules.
6.For all fields that have had their values changed since step 1 and that contain WHENCHANGED rules, first do DEFAULT and then COPY rules
inside.
7.Allow the user to start editing.
8.The user changes a field value and then moves focus from the field.
9.Raise any WHEN rules for that field that match the new value.
10.Raise any WHENNOT rules for that field that match the new value.
11.Raise any WHENCHANGED rules for that field that match the new value.
12.Return editing ability to the user.
13.The user saves the changes to the database.
14.For all fields, perform SERVERDEFAULT operations that are defined for the field either directly or indirectly under a WHEN or a WHENNOT
rule.
In TFS 2010, is it possible to give a group of users the ability to update certain work item types, but restrict to read-only access on all others?
One way you can do it is by adding required field to work item types you want to control.
What you need to do:
Export WI type definition xml using witadmin:
witadmin.exe exportwitd /collection:http://localhost:8080/tfs/DefaultCollection /p:<project name> /n:<WI type name> /f:C:\type.xml
Modify WI type xml by adding new field definition to the FIELDS node:
<FIELD name="Block" refname="Test.Block" type="String" reportable="dimension">
<ALLOWEDVALUES>
<LISTITEM value="NotUsed" />
</ALLOWEDVALUES>
<REQUIRED for="[Project]\RestrictedUsers" />
<DEFAULT for="[Project]\RestrictedUsers" from="value" value="You don't have permissions to create work items of this type."/>
</FIELD>
Import updated xml back to the server:
witadmin.exe importwitd /collection:http://localhost:8080/tfs/DefaultCollection /p:<project name> /f: C:\type.xml
Now members of the RestrictedUsers project group won't be able to create/update work items of this type. When they try to save the work item of this type, they'll get an error saying:
The field 'Block' contains the value 'You don't have permissions to create work items of this type.' that is not in the list of supported values.
No I don't believe this is possible to do by Work Item Type. You can restrict access to Work Items based on which Area they are in however. But the security by Area permissions would apply equally to all Work Item Types in that area.
Updated question with additional info as solution was not applicable.
Sorry, I will have to ask this question once again. My objective is to implement some TFS automation for the Assigned To field. This field is to be populated certain values in the module and category field are selected.
Is there a way to create an "And" operator within the TFS WI XML that can handle this? I asked this question a couple of months ago and received an answer. Unfortunately, I haven't had time to implement it due to several items that came down the pipe. When I tried implementing the solution and when importing the WIT, TFS would throw a "WHEN" has an invalid child element "WHEN" error.
Example:
If "Module" field = value X and "Platform" field = value Y, then "Assigned to" field is set to specific user
Given solution does not work:
<FIELD name="QA Owner" refname="<QAOwnerFieldReference>" type="String">
<VALIDUSER />
<WHEN field="<ModuleReferenceName>" value="Compliance">
<WHEN field="<AnotherFieldName>" value="SomeValue">
<DEFAULT from="value" value="<QATester>" />
</WHEN>
</WHEN>
</FIELD>
I do have an idea, is it possible to merge the second "WHEN" condition with the first, such that:
<WHEN field="<ModuleReferenceName>" value="Compliance" && WHEN field="<AnotherFieldName>" value="SomeValue">
Link to previous post: Assigning users in TFS if two fields have specific values
What you need to do is to cascade two conditions, to create an and effect. Not ideal, but what'll you do :)
Here's what your WIT field definition could look like:
<FIELD name="QA Owner" refname="<QAOwnerFieldReference>" type="String">
<VALIDUSER />
<WHEN field="<ModuleReferenceName>" value="Compliance">
<WHEN field="<AnotherFieldName>" value="SomeValue">
<DEFAULT from="value" value="<QATester>" />
</WHEN>
</WHEN>
</FIELD>
The only viable solution I could find for this is to create a custom control that will process a set of rules before saving the work item.
Check out Gregg Boer's blog for a short guide to creating WI custom controls. Note that this will need to be installed on each desktop client's machine.
Note that you will want to write a handler for the BeforeUpdateDatasource event.
Also, if you need this to run on the web, you'll need to create a web-access custom control (see Ewald Hoffman's post on WA controls).