I added a TFS group [Projects]\Business Analysts. Some of the people assigned to this group do not show up in the dropdown. Anyone know why this would happen?
Additionally, when I access the AssignedTo field from the context menu on the backlog page the names are completely different than those on the Product Backlog AssignedTo List.
Here is work item definition for the group:
<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
<ALLOWEXISTINGVALUE />
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<LISTITEM value="[Project]\Business Analysts" />
</ALLOWEDVALUES>
<HELPTEXT>Organizer of product feature</HELPTEXT>
</FIELD>
Are the people that are not showing up part of the project in any way? Did you put the full group inside one of the OOB groups (contributors, Admins, etc.) or in a team in this project. If the missing individual don't have access to the project they won't show up in the dropdowns this rule doesn't add them to the project just filter user in that group in the assigned to field.
Some of the people assigned to this group do not show up in the
dropdown.
The drop down is actually a cached list of users you have assigned tasks to in the past.
So, you just need enter their first name or email address to search him and assign to him. Next time, you will see him in the drop down list.
Details steps:
When assigning a user to a task, enter their first name and click the search button. The user should be brought back by the search. Assign the user to the task.
Next time you go to assign a user to a task, if you click on the drop down list should now display the user as it is now cached.
For details please take a look at Ewald Hofman's response in this question: TFS-2015 limiting user list
If you still not able to see those users after manually search their name/e-mail, then you may have to check the corresponding permission. Make sure all of them have sufficient permissions.
Hope this helps.
Related
Is it possible to restrict users from editing a field in TFS based on a user? For example suppose there is a state field and owner field. The user selected in the owner field should only be allowed to updated the state field, it should be readonly to rest of the users.
You can define a rule of a field to achieve it.
Just edit the process template and make the field only editable by Admins. (You may need to install the power tools or use witexport and a good XML editor to do all the work)
<FIELD refname="System.Description" name="Description" type="PlainText">
<READONLY for="[Project]\Contributors" not="[Project]\Project Collection Administrators" />
</FIELD>
More info from MSDN: Apply a rule to a work item field
Restrict modification of a field to a group of users:
Use not to exclude a group from a rule. This example defines the Triage Description field as read-only for everyone except those users in the Triage Committee group.
<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>
Update
You can also add some restriction during the transition of two state. Please see below steps and screenshot for more info.
Detail steps:
Open the Work Item Type from server(need tfs power pools)
Right click the transition select 'open details'
Select for or not, add the owner to a group, if you select this group. The user in this group can only be allowed to updated the state field.
For example, if there is a Product Backlog Item in Removed State, how can I prevent team to add tasks or test cases to it?
I originally thought of setting the workitem as FROZEN. But it might not work if we need to be able to reactivate the PBI when requirement changes.
Education.
You need to train your users in use of the system so that they don't make amateur mistakes like that.
There is no way in the tool to prevent links based on state.
I'd go for #MrHinsh's answer by default.
I haven't tried this myself as yet, but I think it should work... I'll delete the answer if it doesn't.
To make a work item read only for most people, while still allowing selected users to edit it you can put the work item into a situation where the validation rules fail for most but succeed for the selected users. That way, people can make the changes but can't save them.
For example, add a field such as the following:
<FIELD name="ReadOnly" refname="My.ReadOnlyFlag" type="String">
<WHENNOTCHANGED FIELD="System.State">
<PROHIBITEDVALUES expanditems="true" for="[Project]\Contributors">
<LISTITEM value="true" />
</PROHIBITEDVALUES>
<HELPTEXT>The work item is now locked. No changes can be saved</HELPTEXT>
</WHENNOTCHANGED>
</FIELD>
Then in the transitions to the Removed state, set the My.ReadOnlyFlag value to true.
See how you go with that approach and whether it works for you.
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.
I created a new field in our bug template that has values like A,B,C,D. Now I’d like to set permissions for that specific field so that only one group of TFS users can update it while others see it as read=only. Is something like this possible?
You can do this by editing the Work Item Type definition and edit your field. Switch to the Rules tab and add a "ReadOnly" rule. For this rule, insert the allowed group in the Not textbox, so this rule will not be taken into consideration for them (example for Description field):
<FieldDefinition name="Description" refname="System.Description" type="HTML">
<READONLY not="[Project]\AllowedGroup" />
</FieldDefinition>
Just installed TFS 2010 and noticed that the main text in work items can be edited. We'd like to freeze all editing of work items (except for admins), in order to keep a more auditable trail of discussion for each bug and minimize confusion over what the original bug was, etc.
Is there a way to configure TFS 2010 so that the main text previously entered for a work item is not editable by most users?
You can edit the process template and make the field only editable by Admins.
If you have not already, you will need to install the power tools and then open the work Item and change:
<FIELD refname="System.Description" name="Description" type="PlainText" />
To:
<FIELD refname="System.Description" name="Description" type="PlainText">
<READONLY for="[Global]\Project Collection Valid Users" not="[Global]\Project Collection Build Administrators" />
</FIELD>
You can obviously replace the groups with project specific ones. This makes this field perminantly readonly.
The entire history of the work item fields is available in the "History" -- it will show you what fields have cahnged and by whom.
What you might want to do is change your template so that both the description and history show on the same tab. Make it a standard of convention that only the history is updated, not the description.
Then, if the description does ever get changed, you can review it in the history window (along with any manually entered notes).