Restrict Priority by Role and Custom Field using ScriptRunner Behaviours

[Neil]

Hi everyone.

This is my first post (likely not my last), I've tried searching through other questions and other sites for my answer however I am struggling to get to where I need - I get close but not close enough!

I am running Jira 7.11.0 Server and ScriptRunner 5.5.5

On all issues I have a checkbox that when checked I want to prevent users who are not in a specific Project Role from selecting a specific priority level.

I have seen the example script here however this does not do exactly what I want, I have no experience in Java/Groovy so do not know what I need to do in order to modify this to suit my needs.

My custom field id for my checkbox is 'customfield_23347', it is currently restricted so that it is only able to be edited by users in the 'Administrators' Project Role.

Minimum Requirement:

• When 'customfield_23347' is checked, if the user is not in a Role of a Project Administrator, then the list of available priorities should be restricted (e.g. the option to select Critical should not be available).
• If 'customfield_23347' is not checked then there should be no restrictions and users should see all available priority levels.

Nice to have:

• When the above restriction is in place, advise the user with a comment under the Priority field that they are unable to set a specific priority level since they are not an Administrator of the project.

There is no concern around users setting the priority and then checking the checkbox since only Administrator are able to set this checkbox and will be responsible for ensuring that the priority level is set correctly.

Thank you in advance for your help!

[PD Sheehan · Accepted solution]

Part of the trick here is that with Jira 7 ... a new Priority Scheme has been added to projects and just filtering from the list of all priorities obtained from constantsManaeger.getPrioririties() will return more values than are in your project.

Also, since you are interested in project role rather than jira admin , we need a different component (rather than userUtil).

Putting all that together with some flexible logic in case you need to change the list of restricted priorities or roles, a script like the following should work.

import com.atlassian.jira.component.ComponentAccessor
import static com.atlassian.jira.issue.IssueFieldConstants.PRIORITY
import com.atlassian.jira.security.roles.ProjectRoleManager
import com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

def projectRoleManager = ComponentAccessor.getComponent(ProjectRoleManager)
def prioritySchemeManager = ComponentAccessor.getComponent(PrioritySchemeManager)

def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def priorityFld = getFieldById(PRIORITY)

def restrictedPriorities = ['Critical', 'more if needed']
def permittedProjectRoles = ['Administrators', 'Some Other Role']

//gett role objects for the roles that are permitted to access restricted priorities
def projectRoles = projectRoleManager.projectRoles.findAll{it.name in permittedProjectRoles }


//examine each permitted roles to see if the user belongs, if they don't belong to any ... they'll be restricted
if (!projectRoles.any{projectRoleManager.isUserInProjectRole(currentUser, it, issueContext.getProjectObject() )}){
   //get a collection of priorities objects relevant for the current issue context 
   def contextPriorities = prioritySchemeManager.getPrioritiesFromIds(prioritySchemeManager.getOptions(issueContext))
   //filter to remove restrictedPriorities and construct a map object
   def allowedPriorities = contextPriorities .findAll{
      !(it.name in restrictedPriorities)
   }.collectEntries {
      [(it.id): it.name]
   }

   //apply the map object to the priority field (this overwrites the default list)
   priorityFld.setFieldOptions(allowedPriorities)

   //provide some contextual help to the user
   priorityFld.setHelpText("Access to some priorities have been disabled: $restrictedPriorities.<br>Contact a member of $permittedProjectRoles if this priority needs to be assigned.")

}

[Neil]

Thank you for your response @PD Sheehan , your code looks easy to read and follow.

I am however having some issues trying to get it to work, perhaps you could review what I am doing and advise if I am doing anything wrong or whether you can identify the problem?

1. I create a new Behaviour and paste your code into the Initialiser section.
2. I amend the priority and role values.
3. I map the Behaviour to my project (all issues).

I have checked that my Priority name is correct:

{"self":"https://jira.xxxxxx.xx/rest/api/2/priority/9","statusColor":"#ff0099","description":"This is Critical.","iconUrl":"https://jira.xxxxxx.xx//images/icons/priorities/critical.svg","name":"Critical","id":"9"}

I have checked that my Role name is correct:

"Administrators":"https://jira.xxxxxx.xx/rest/api/2/project/26600/role/10002"

[Neil]

Hi @PD Sheehan 

Apologies, I realise that this is actually my mistake. Your code works fine, I just never realised how these types of Behaviours work in different scenarios.

When creating or editing an issue using the Edit screen then this works perfectly.

The confusion on my behalf was caused since I was also trying to edit the priority on the issue directly as opposed to using the Edit screen. When trying to do the inline editing the Behaviour script is obviously not called and therefore cannot restrict the values.

This is a separate issue not related to Behaviours and something I am not sure can actually be resolved without removing the ability to edit priorities which I do not want to do. I have considered doing this and then creating a transition button for prioritising however the overhead of adding and managing this on all 820 of our Jira projects would be huge.

If anyone has any ideas on how to do this on a global level your suggestions would be greatly appreciated!

Thank you

[PD Sheehan]

Just add Priority to your behavior configuration (even if you don't apply any rules or script). When a  field is listed in a behaviour configuration, editing that field inline becomes disabled. If you try, the edit screen will pop up.

[Neil]

Thank you @PD Sheehan , this sounds great however I am struggling to follow what you mean by "add Priority to your behaviour configuration".

Are you referring to the Add Field section and then adding the Priority field? I have tried this and left all the available options off however this doesn't appear to have any affect. Am I missing something?

This is a screen shot of the area within Behaviours that I am referring to:

[PD Sheehan]

Yes, exactly like that. 

Save your behavior configuration, then refresh your issue page and attempt to do inline edit of the priority field.

Assuming this is in the same config with the same behaviour mapping as the initialiser.

[Neil]

Thank you @PD Sheehan 

I have tried adding this to the same behaviour where I use the code in the initialiser in addition to having it as a standalone behaviour mapped to the same Project/Issues as my original behaviour.

On testing however I cannot get the desired affect either way, inline editing is still available.

 

[PD Sheehan]

Maybe a SR version difference/bug. I’m on 5.5.3. 

5.5.7 reports fixing an issue with online editing. 

I would try to update the open a support call with Adaptavist if you still have a different behavior. 

[Neil]

Thank you for your help, patience and support @PD Sheehan , I am confident based on what I am seeing and the bug fix reports in ScriptRunner 5.5.7 that once I upgrade this will work fine.