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

This widget could not be displayed.

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

This widget could not be displayed.

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

This widget could not be displayed.

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.

This widget could not be displayed.

here is screenshot

This widget could not be displayed.

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 Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Aug 06, 2018 in Jira Service Desk

A is for Activate: Share your top Jira Service Desk onboarding tips for new users!

Hi, everyone! Molly here from the Jira Service Desk Product Marketing Team :).  In the spirit of this month's  august-challenge, we're sourcing stories of Jira Service Desk activation fro...

578 views 25 15
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