Filed Against and Custom Attributes
Recently, we added a custom field of type Tag to our Defect and Story editor pages called Release Label with id releaselabel. A role called Release Manager was created and given the permission to modify the field. No other roles were given the permission to modify it.
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
Hi Aaron,
I'm not sure what could be causing this issue. How did you setup the permissions to modify the field? https://jazz.net/library/article/997/#dynwflow explains how to make a field read-only based on the role. |
Sounds like you have a script based Advisor which is posting an incorrect error message.
|
We are experiencing the same problem. The way that it appears to work is:
When the Filed Against category is changed, the work item is moved to the new category, and the move appears to be implemented as a Cut and Paste, The Paste effectively creates a new instance of all attributes, and the user permissions do not allow the new custom attributes to be saved. I don't know the actual implementation, but I have seen this error with the cut and paste implementation elsewhere.
What we expect is that Filed Against is just another attribute that can be changed, but it has additional side effects.
We are preparing to submit an RFE to address this.
Comments 
Geoffrey Clemm
commented Jun 25 '13, 12:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
*
Geoffrey Clemm
commented Aug 01 '13, 5:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.