How can you make a work item editable by only certain users, but still allow anyone to add an attachment?
We are using RTC 6.0.4. I have a request to have a work item editable by only certain users, but to allow any user to add an attachment. We have been able to accomplish this by making attributes read-only by using the operational behavior "Read-Only attributes for type and state". The problem with this solution is that there are many roles and we had to add this behavior to each role and select all the attributes on the work item (except for comments) which was cumbersome. Plus we had to add all the needed permissions to this new role, since we restricted editing on the other roles and had to delete those roles for the users that need to edit the work item. This allowed us to restrict edit access to only one role. However, when we add new roles, we will need to remember to restrict edit access on that role as well. Therefore, our solution is not the best.
Does anyone know of another way to be able to restrict edit access for a work item (so only certain users can edit it), but still allow anyone to be able to add an attachment to the work item?
|
One answer
Ralph Schoon (63.1k●3●36●46)
| answered Aug 14 '19, 2:02 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Aug 14 '19, 2:03 a.m. RTC uses roles to manage permissions. Every user that has access has the default role "Everyone".
Permissions to modify attachments are available in
So it should be possible to grant everyone permissions to modify permissions, while not all roles have the permission to do a lot more, other roles could. Permissions aggregate over roles. Users can have one or many roles. Dynamic control of read-only should not be needed.
Attachments are a necessary evil and you want to avoid too many attachments. If your process revolves around attachments I would be concerned.
Further Reading:
Comments
Ralph Schoon
commented Aug 14 '19, 2:06 a.m.
| edited Aug 14 '19, 2:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To emphasize, roles grant permissions, they do not revoke any permissions. So if the default role "Everyone" has the permissions to add attachments, anyone with access has that permission. Additional roles can add more permissions. Another possible approach would be a work item save advisor (pre-condition). However, that would have to be written, maintained and also needs information to work e.g. roles. In addition it needs to be managed in the process behavior which can be tricky. I would not suggest that if the basic permissions should be sufficient.
In addition to using the "Everyone" role, it would be possible to revoke permissions to work item attachments for all roles, including the "Everyone" role. Then add a role "Attachment modifier" and assign that to all users.
Yes, I am fully aware of the permissions, but the attributes on this work item are used on other work items as well. Therefore, if I limit who can edit these attributes it would limit their ability to modify those attributes on other work items. The basics of what I am trying to accomplish is to only allow one role to be able to edit the work item except for adding attachments which should be allowed by all users.
I am currently using a pre-condition to make those attributes read-only by role but was hoping there was an easier way.
I have the impression you try something that RTC was not designed for and I have not seen a compelling reason why this should be attempted. Why do you want to do that, what is the purpose and business reason?
I am also not clear what scope of this is - e.g. what does "attributes on this work item are used on other work items as well".
If you use https://rsjazz.wordpress.com/2015/08/07/a-custom-condition-to-make-attributes-required-or-read-only-by-role-version-2/ that was a last ditch effort to implement something that goes against all design and implementation goals RTC is based on, to implement something a customer wanted, regardless if it was a good idea or not.
|
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.