ScriptRunner post-function Create Sub-task Permission question

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

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

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

Hi John,

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

Vijay.

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...

Hi John,

Can you post your post-function configuration snapshot?

Vijay

Is that what you are looking for?

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

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

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.

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.

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?

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.

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?

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

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.

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

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).

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.

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

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.

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.

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).

0 vote

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

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.

here is screenshot

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)

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,331 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