Dynamic Jira permission scheme... permissions set to humans based on value in a non-human field

[Mike Rathwell]

I have a (possibly) interesting use case for Jira permission scheme that I could use some help with. The need scenario for rather tightly locked down project where users can only see issues they are specifically involved with (all this works now except for the "dynamic" part):

• Department executives should be able to see all issues related to their department but no others unless explicitly added to another issue via an existing and working CF gating "browse" permission.
• Department execs may be re-assigned to new or other departments or new execs added to split load off existing execs changing the list of issues a given human should be able to "see"
• LOTS of issues potentially "altered" for view based on some changes; static "user" fields could be a PITA to manage with changes.

Where I started:

• Created a JMCF calculated field that determines the exec based on a simple groovy script looking at the value of the department select list.
  • This works great and updates the Dept Exec field correctly as the value in the Department field is changes.
  • Provides a single, centralized place to "re-shuffle" as/when it happens whether new departments, shuffled execs, etc.

The problem: Simply stated, I can't use this uber-useful field in the Permission Scheme. This would solve for "I do different stuff now so when I land on an issue I could see before, I can't see it because I shouldn't but I can see new ones that I should be able to see"

Questions:

• Could I use Automation to look for changes in the calculated field to then copy the value to a static field?
• If I used Automation to directly populate a static field, any thoughts on how to refresh the static field on existing issues when the rules change for it? Maybe since an admin-ish kinda function, a groovy script run in a script console (JMWE or ScriptRunner)

Continuing to noodle but thoughts, hopes, dreams, and/or aspirations would be helpful.

[Dave Theodore [Coyote Creek Consulting] · Accepted solution]

You are describing (almost exactly) the built-in feature Issue Security. If you set up your Issue Security Scheme so that it uses LDAP or AD groups, you could update group memberships in your directory and this would cause the new capabilities to be automatically pushed in to Jira.

[Mike Rathwell]

Hi @Dave Theodore [Coyote Creek Consulting] 

This may well be the route I take as others are proving... complex. It'll be a little ugly with some groups having a single human in them and the reshuffling as they reshuffle both execs and departments... yay...

I'll take a shot at this as it seems the best way to go.

mike