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).
Related
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.
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.
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>
I'm introducing TFS 2010 in our company.
After a lot of work on item customizations, I'm considering using custom fields as some system fields.
One example...
I've got some management requirements for the field "System.priority". This field should be set to "REQUIRED", so everyone has to do an estimation about the priority of a bug or task.
Are there any well known problems with creating an custom mypriority field and using it? (except the whole customizing afterwards for the basic reports...)
I know i cant delete the system fields but i can delete the references for system.priority from the layout tab and then im going to use my own customized ones ..
Is this possible?
Avoid creating custom fields when the default ones can serve the purpose. E.g.: Use the REQUIRED rule where needed:
<FIELD name="Priority" refname="Microsoft.VSTS.Common.Priority" type="Integer" reportable="dimension">
<REQUIRED />
</FIELD>