I have a project where one group has access to edit and view issues for a number of different constituent groups. There is an Issue Security Scheme implemented where each constituent group has users that are in a group, and that group is applied to a security level for that group's issues. The one group that needs access to every issue is in every Security Level. This all works as intended.
My issue now is that I have a new constituent group that should get the same treatment, but with one exception. In addition to being able to create/edit issues in their own security level, this group needs to have read-only access to all of the other security levels as well.
So, something like this . . .
Group1 | View & edit issues in all Security Levels
Group2 | View & edit issues in Security Level "SL2"
Group3 | View & edit issues in Security Level "SL3"
Group4 | View & edit issues in Security Level "SL4"; Also, View only issues in "SL2" and "SL3"
Is this possible?
That's what I thought. Thanks. I believe I can accomplish this using Behaviors in the SciptRunner plugin though. Basically, set the Permission Scheme and Security Levels so that the users can view/edit all issues, but then use Behaviors to set all fields in an issue as read-only when the Security Level is not SL4 and Group is not Group4.
The Jira Marketing team is putting together an ebook on migrating to Data Center. We're looking for pro tips on how you staffed your project team and organized your Proof of Concept. Share yo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs