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?
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yeah... I'm not sure you've reached the correct conclusion. Can you post any errors?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Vijay -- I posted the log results fromt his morning above. I agree it is strange behavior and is likely something I'm overlooking.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi John,
Is the transition itself is failing or just the sub-task creation?
Vijay.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi John,
Can you post your post-function configuration snapshot?
Vijay
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Configuration of the post-function where you create sub-tasks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Here is the screenshot...running produces an error for each Create-sub task.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
How did you migrate the users from internal directory to LDAP? Looks like the user management tables have some issues.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have in app_user table user_key and lower_user_name as same for all the users.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.