Filed Against and Custom Attributes
Now, when a user WITHOUT the Release Manager role changes the Filed Against field with out changing the Release Label field ... an error occurs
Problem:
You don't have permission to Save Work Item [server]
Reason:
In order to carry out this operation, you would need permission to perform the following additional actions:
Action:
Modify the 'Release Label' attribute
ID
modify/releaselabel
The user did not change the release label but gets the error when changing the Filed Against. The user can change everything else and will not get the error.
Any ideas why this might be happening or how to troubleshoot the issue?
3 answers
Comments
Changing the FiledAgainst property of a work item does not create a new instance of all attributes (and therefore is probably not an example of what you are calling Cut and Paste). And yes, FiledAgainst is just another attribute that can be changed, with some side effects.
I used the cut and paste as an analogy. One side effect of changing the Filed Against value to a sub-category that is associated with a sub-team is to impact the other attributes of the work item in some way that I do not know, so that if the user does not have permission to modify any of them, saving the change fails. This happens with V4.0.1.
I finally received an answer from IBM Development on the PMR related to this issue:
* <o:p> </o:p>
Changing 'Filed against' is more than just an attribute change. It can also lead to a change in the process (team/project) area the work item belongs. <o:p> </o:p>
To move a work item from one process area to another you need the same rights as when creating a new work item in the target area: <o:p> </o:p>
- You need the 'modify' rights for each attribute which is not the default value I realize that our model is too restricted to be used the way you want it. <o:p> </o:p>
So, this is not a bug, but as designed. To make our current model more powerful regarding team area change, we would need to look at this in a enhancement request.
*
The current behavior probably does make sense. Suppose you had permissions to do everything in a team area. If this check against all property values was not done, you could just give a work item any properties you wanted, and then change the FiledAgainst to reassign it to a different team area where you do not have permission to set those values.