ScriptRunner post-function Create Sub-task Permission question

John Benjamin June 18, 2014

I'm running 6.0.2 of JIRA and using the ScriptRunner built-in script to create a sub-task as a post-function. Recently, the post-function stopped working and I traced it back to a permissions change I had made: I had removed the Anyone group from the Create Issues permission.

I thought the user that was initating the workflow transition became the Reporter for the sub-task and would therefore be the user account with the permissions.

Is there something else I'm missing here? Why does the create sub-task post-function require anonymous ability to create the issue?

5 answers

0 votes
John Benjamin June 18, 2014

Attached is exercpt from Jira and Jira-Security logs from when I reran this morning...Error is

[onresolve.jira.groovy.GroovyFunctionPlugin] Error executing post-function
com.atlassian.jira.exception.CreateException: An unknown exception occured executing Validator com.atlassian.jira.workflow.validator.PermissionValidator@4fb5902c: root cause: java.lang.NullPointerException

I did confirm I was logged in (my USerID is OPR9465). We are using LDAP authentication...could that require anything unique?

(PermissionsQuestion.txt)

0 votes
John Benjamin June 18, 2014

here is screenshot

0 votes
John Benjamin June 18, 2014

I will switch it back and look for any errors when I run it again (couldn't find any from yesterday's run). I do see this in the stream when the subtasks were created it appears to be creating the links to the original parent under Anonymous. I'm creating three subtasks in the post-function.

0 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 18, 2014

Yeah... I'm not sure you've reached the correct conclusion. Can you post any errors?

0 votes
Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 18, 2014

Hi John,

Thats strange. As I am using the same post-function and I dont have anonymous access to create the issue and it works perfectly well for me.

May be there is some error in logs that would help. Can you try to paste the logs here?

Vijay

John Benjamin June 18, 2014

Hi Vijay -- I posted the log results fromt his morning above. I agree it is strange behavior and is likely something I'm overlooking.

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 18, 2014

Hi John,

Is the transition itself is failing or just the sub-task creation?

Vijay.

John Benjamin June 18, 2014

Just the sub-task...I tried the same with a non LDAP user with elevated permissions and it did create the sub-tasks sucessfully. I'll keep trying to isolate it...

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 19, 2014

Hi John,

Can you post your post-function configuration snapshot?

Vijay

John Benjamin June 19, 2014

Is that what you are looking for?

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 19, 2014

Configuration of the post-function where you create sub-tasks.

John Benjamin June 19, 2014

Here is the screenshot...running produces an error for each Create-sub task.

John Benjamin June 19, 2014

It appears that users in the JIRA internal directory successfully execute the transition / create the subtasks; while users in the LDAP directory cannot. Still trying to confirm that.

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 19, 2014

Hmm very wierd. I am able to do this and I have users from both directory doing this :(

Is your LDAP integration full or just for password authentication. I dont have full LDAP Integration.

John Benjamin June 19, 2014

It is just password authentication. We did have a bunch of users that we had created in local and had to go through process to move them and rename. Wonder if that might be a complicating factor? Did you have similar path or were all users simply created in one directory or another?

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 20, 2014

We also had JIRA internal directory for few years and I had to migrate all users to LDAP directory sometime last year. Now I still have some users that are system/technical users not in LDAP and the post function works well for all.

John Benjamin June 20, 2014

Another update...it appears that the script is looking at the "original" internal ID and not the ID associated with AD???

I see things like Assign To is "OPR9465(jbenjamin)" in the logs; where the OPRXXX is the current ID tied to AD and jbenjamin is the original internal one. I believe it keeps both when users are renamed or merged.

It wasn't until I recreated the jbenjamin again in the internal directory that it started working again after I gave the user the correct permissions -- key was finding "User 'jbenjamin' doesn't have the 'Create Issue' permission" in the log.

This makes me think that if the original internal directory User ID does not exist, the script doesn't find it for determining permissions and therefore sends null causing the error. With Anyone / anonymous permission for Create Issue, it works because a User ID isn't required.

Does that pass the reasonable test?

Any resources / thoughts on how to clean up my user mess?

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 20, 2014

How did you migrate the users from internal directory to LDAP? Looks like the user management tables have some issues.

John Benjamin June 25, 2014

Vijay -- We are not exactly sure. We intended to follow the directions using the JIRA migrate users from one directory to another process (under User Management), but the individual that performed this steps thinks they might have switched the order of when to rename them. I.e, they renamed the users after they migrated them to the LDAP directory.

Trying to make sense of what I see in the app_user_table:

ID = 10006

user_key = jbenjamin --> original ID

lower_user_name = opr9465 --> my LDAP ID


This seems to support the rename after the migration occurred. I'm curious if the rename happens before the migration if the user_key and lower_user_name are the same. Would you be able / willing to check in your setup where it works how migrated users look in this table?

Thanks.

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 26, 2014

This is strange. As the cwd_users table of my JIRA has column user_name and user_name_lower always same, just second is lower case of first.

I dont have any case where they are different as in my JIRA, i have created all users with lowercase.

How was the rename done? Directly on DB?

Vijay

John Benjamin June 26, 2014

Thanks for the continued assistance.

Our cwd_users is same as you describe; I'm curious how your app_user table looks regarding the user_key and lower_user_name.

We used an Add-on based script to do a Merge User (vs. a DB direct change or using the rename / edit username under User Management).

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 26, 2014

In the KB below I see some steps to verify the app_user table has valid users.

https://confluence.atlassian.com/display/JIRAKB/JIRA+Login+Fails+With+the+Message+-+User+exists+but+has+no+unique+key+mapping

The error is different but may be worth a try to verify if the migration/merge of users was well done.

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 26, 2014

I have in app_user table user_key and lower_user_name as same for all the users.

John Benjamin June 26, 2014

Thanks for the additional information...with them all the same in your environment, it makes me think you didn't have to rename any users when moving them to LDAP? Is that true? If you have had to rename users, could you share which process you used? I guess version 6 and above gives some additional options here.

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 27, 2014

yes, its true I dint have to rename any user as since the beginning of JIRA usage, the policy was to create the users with same username as in ldap, even when ldap was not integrated. So for me it was easier.

If I had to rename, i would have used the groovy script to do so.

If I was not able to do with groovy, would have renamed the users in cwd_user table and not touched app_user table.

John Benjamin June 27, 2014

I think I might have a break through...not sure why this didn't come up in searches before, but I found this:

https://jamieechlin.atlassian.net/browse/GRV-348

Basically a potential fix in the latest release. I upgraded to 2.1.16 and I've had success creating the subtasks without the anonymous access. Still some more testing, but I'm very hopeful (and a little frustrated I didn't find it before).

Vijay Khacharia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 27, 2014
Good to know.

Suggest an answer

Log in or Sign up to answer