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?
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?
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 -- 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?
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?
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.
The error is different but may be worth a try to verify if the migration/merge of users was well done.
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:
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).
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.
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?
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
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!
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