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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.