TFS workitem should be edited by only assigned users

Question

Dear All,

I am customizing a workitem type according to my companies requirement. Here I need to validate the user in the AssignedTo field/control, Like when a task is assigned to particular person, he should only be able to edit the task and other users can just have read permission. Even if other users try to edit the task it should not allow. Let me know how to achieve this.

Thanks very much in Advance,

Nagaraj

Answer 1

You can make the field Read Only for particular group of users by using the Read-Only Element Rule. Check this: http://msdn.microsoft.com/en-US/library/aa337590(v=VS.100).aspx

Answer 2

To add on to Jehan's point, there isn't really a way to limit editing to just the creator of the work item.  I would be interested to know what scenario you are trying to prevent as there might be another way to get it done.  Remember, you have full logging and can set up pretty sophisticated alerting around changes made.

---

Ryan Hanisco MCSE, MCTS:SQL 2005, Project+ http://techsterity.wordpress.com

Answer 3

Hi Nagaraj,

How about the issue, is it solved?

Best Regards,

---

Cathy Kong [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 4

We don't want to be alerted to changes...We need to prevent changes before hand.

While we can set all of the fields to read only this isn't an ideal solution because of the number of fields being added to the template over time.

Is there any solution for making the workitem template read only but editable for the creator (without having to specify all of the fields)?

Answer 5

I really don't think so unless you want to write your own interface from scratch.

---

Ryan Hanisco MCSE, MCTS:SQL 2005, Project+
techsterity.wordpress.com

Answer 6

Sigh. Where is the generate connect button when you need one. I keep finding that we're running into these obvious pain points with a half polished product.

Answer 7

As a total aside, and maybe one of the MSFT employees will step into the discussion to spank me for this, but when looking at the templates, even the CMMI one, the focus is on enabling agile teams.  That doesn't mean everyone drinks the kool-aid and becomes a zealot, but there are some underlying things that are simply aligned there.  I personally think it is a good mix and flexible enough to work for (almost, apparently) any situation.

Given that context, I have a hard time coming up with a business case that would want to make work-items read only for the originator.  Even in the situation of things like trouble tickets and externally generated work items, the audit trail has provided enough to satisfy compliance and governance for even some huge clients.  The self governing part come when everyone has access to the history and further allowing notifications when anyone else edits a ticked you created.  That has been enough to deal with the issue organizationally without the need to take the flexibility hit from a true lockdown.

If you want to get experimental, you might try something like a rule that says. 

<FieldDefinition reportable="dimension" refname="System.ChangedBy" name="Changed By" syncnamechanges="true" type="String">
  <NOTSAMEAS field="System.CreatedBy" />
</FieldDefinition>

It might throw the error before commit, but it wouldn't warn them until they tried to save.

Update: Yeah my thinking was backwards.  Why don't we have a SameAs or Must Equal?  That would be useful.

---

Ryan Hanisco MCSE, MCTS:SQL 2005, Project+
techsterity.wordpress.com

Answer 8

Got it working....

<FieldDefinition reportable="dimension" refname="System.ChangedBy" name="Changed By" syncnamechanges="true" type="String">
  <COPY from="currentuser" />
  <FROZEN />
</FieldDefinition>

So there isn't a good error message with it or anything, but it does enforce the functionality.  Since Copy is processed before everything else, we can use it to force the value on load before any of the other rules are posted (like the frozen one).  Then we freeze the value (the rule doesn't fire if the field is empty).

If the user that created the work item goes to edit it again, they are allowed as the value it tries to copy is the same so it never commits to trigger the frozen constraint.

If a different user tries to edit the work item, the value is copied over top, but then the frozen constraint is triggered as it does the validation pass before it releases the work item into edit mode generating the error.

This is even more flexible as you can specify a group or account that you want to have override capability to edit the WI.  In your case, though, you'd keep it as above.

Whew, hope this helps!

---

Ryan Hanisco MCSE, MCTS:SQL 2005, Project+
techsterity.wordpress.com

Answer 9

Thanks Ryan. We're trying to implement SOX compliance and FDA Part 11 Electronic Records compliance. We have these auditors and lawyers looking over work items very very careful and we must comply with the legal requirements.

Answer 10

BTW, when the next version of TFS comes out or even a service pack, test this.  If it starts marking the System.ChangedBy value dirty when overwriting the same value, the solution will break.

---

Ryan Hanisco MCSE, MCTS:SQL 2005, Project+
techsterity.wordpress.com

Answer 11

I've got the solution!

Becouse of some problems with the solution via frozen System.ChangedBy field:
1. problem with dirty value in System.ChangedBy (for example when someone server service makes changes to WI)
2. problem with incorrect error message
3. impossibility to allow making changes to specific fields

I was very interested for another solution...
And i've got this and it's fully resolve all problems! :)

So it's only 2 simple steps:

1. Modify Work Item definition:

a) Add the hidden filed: 

<FIELD name="Allowed user" refname="YourCompanyName.AllowedUser" type="String">
<WHENNOT field="System.AssignedTo" value="">
<COPY not="[global]\Project Collection Build Service Accounts" from="currentuser" />
</WHENNOT>
</FIELD>

b) Add a protection to specific field. For example "System.Title":

<FIELD name="Title" refname="System.Title" type="String" reportable="dimension">
<WHENCHANGED field="YourCompanyName.AllowedUser">
<CANNOTLOSEVALUE /> 
<FROZEN />
</WHENCHANGED>
</FIELD>


2. Make the service that will do only one operation (on the server side):

The operation is: "Once the target work item is changed service will copy value from System.AssignedTo to YourCompanyName.AllowedUser".

To make this I used TfsAggregator source code (it's open source project on CodePlex). I made "MyOperation" function and added parameter to config file:

<AggregatorItem operationType="MyOperation" linkType="Self" workItemType="Task">
<TargetItem name="Allowed user"/>
<SourceItem name="Assigned To"/>
</AggregatorItem>


That's all!
What we have done?
1. When somebody creates a work item with not empty "Assigned To" field and save it... the server service will copy "Assigned To" value to "Allowed user" field.
2. When somebody trying to modify work item his name saved in "Allowed User" field.
2.1. If this user trying to modify protected field the rule WHENCHANGED is fired! ...and the magic starts! :-)