Removing access to a single field gives error when changing status

Franca Zober (15●13) | asked Jan 24, 8:22 a.m.
edited Jan 24, 8:23 a.m.

I want to steer via roles/permission which fields can be changed by whom.

For this I have done the following:
1. Created a new custom field, let's call it 'ABC'

2. Created a new role 'XYZ'

3. Revoked permission from all roles to "Modify the 'ABC' attribute"

4. Granted permission to the role 'XYZ' to "Modify the 'ABC' attribute"

5. Add the role 'XYZ' to all members who should be able to modify 'ABC'

With the above, modification of 'ABC' works as expected. If the user has the role 'XYZ' it works, if not the item cannot be saved if 'ABC' was changed and a respective error message is displayed.

The problem I am encountering: if anyone tries to close the item, i.e. changing the status accordingly, it is not possible to save the item, instead an error message is displayed saying "You don't have permission to perform the following actions: modify/resolutionDate."

Anyone with a clue why this is happening?

Comments

Ralph Schoon commented Jan 24, 8:44 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Can a user with role XYZ perform the close?

I can't find any permission modify/resolutionDate and the resolution date should only be modifiable by internal code anyway.

I would consider to open a case with support. Maybe there is an issue with the process.

Franca Zober commented Jan 24, 9:01 a.m.

No user can close the item, not even the ones with the role XYZ.

When closing, the system would automatically update the Resolution Date, and that is what triggers the error. But yes, I also have no clue why the permission on a single field would impact that...

Where do I open a case with support?

Davyd Norris commented Jan 24, 5:47 p.m.

Do all roles have permission to modify everything else? It sounds like you've set permissions to prevent other fields being changed.

Are all these roles added at the top project wide level, and are all the work items owned by the top level project? If you are using subteams and work items are owned by different sub teams then the roles have to be set at that level too, otherwise they will inherit from the Everyone role, and that may be the one restricting the save

Franca Zober commented Jan 25, 3:13 a.m.

@davyd, I have never been succesful in distinguishing access to single fields based on the error from the initial post.

I do have a user role for read_only (as well as role everyone not being able to modify anything), but obviously those roles never save an item, hence no problem. If I withdraw modify access from a regular user from any item (at least with all I tried with so far), I get the error.

No subteam setup, items, roles and users are all on top level.

Be the first one to answer this question!

Register or log in to post 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.

It's all about the answers!

Related questions

Removing access to a single field gives error when changing status

Be the first one to answer this question!