Possible bug in Script Runner

I have installed the latest version of Script Runner (2.1.9) with JIRA 6.0.4. I have a project with two Issue Security levels - Public and Private. I have two user groups: Internal users are in both security groups, External users are in the Public one only.

I have used a workflow Post Function on the 'Create' step with one of Script Runner's "built-in" scripts to set the issue level security based on the creating user's group. I added the script and then moved it down the list so the step appears after the standard "Create the issue" step. My assumption was that any default JIRA behaviour would happen first, then the script would override the Security Level field.

This appeared to work fine and when I view the Security Level column in the JIRA issue navigator the issues listed are correctly restricted based on the Security Level assigned by the Post Function - it does correctly hide the "Private" issues from external users. HOWEVER, attempting to drill-down to some of the "Public" issues as an external user resulted in a permission denied error even though I could clearly see it in the list and it said security level was "Public".

As an internal user, if I drilled down to the same public issue (that the external user had a problem with) then I noticed that the Security Level shown on the edit page was "private"! So, JIRA appears to actually have two Security Level fields.

My internal users have the permission that lets them see and set the Issue Level Security value. Regardless of what they set this to on issue creation, the Post Function overwrites it. Well, it overwrites the SL value that is shown in issue navigator list and the SL value that JIRA uses to apply security to search results. But there appears to be another SL field that it displays on edit pages and it uses the value in that field when determining if the user has rights to issue opn the issue. This SL field seems to retain the value that happened to be selected in the user's Create screen (or, if I take away that permission, then it retains the 'default' SL from the Issue Security Scheme - none of which helps me as it needs to be group specific).

Surely this has to be a bug in JIRA or Script Runner? The only thing I can imagine is happening is that it is due to some sort of case sensitivity issue. A wild guess but perhaps the JIRA Create page sets the "Security Level" attribute and that same spelling is searched for by drill-down and JIRA edit pages. Let's then say the JIRA search and Issue Navigator looks for a lower-case spelling "security level" and it happens to do a case-insensitive match. However, let’s say Script Runner sets the attribute in lower case ("security level") then under the hood each issue now has two values - one part of JIRA is displaying and using one of them and the other part is using the other.

Any help or advice welcome. I need to get this sorted ASAP.

1 answer

1 accepted

1 vote

AFAIK this needs to be first in the list of post-functions. Does it work as expected if it's first?

See the red callout in the docn: https://jamieechlin.atlassian.net/wiki/display/GRV/Built-In+Scripts#Built-InScripts-SetIssueSecurity

Hi, yes, that fixed it. Can't believe I didn't spot the big red callout box. I guess I got side tracked because it appeared to partially work. Thanks for the speedy response, Jamie!

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,323 views 14 20
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot