Re-read user's permissions in an event listener

[Greg Fischer]

I am writing an event listener using ScriptRunner Listeners in Jira.  The listener catches a specific update to an issue, and I need to add the user to a specific group, update an issue field which can only be edited by users in that group, then remove the user from the group.  Since the user is not an administrator, I "execute" curl on the server to make a REST API call where I can pass in admin username/password to add the user to the group.  This works, but the event listener does not realize the user has been added to the group (I can use GroupManager and see that the user is not listed in the group after the REST API call returns).  So I am figuring the user context with permissions is not dynamically updated and remains the same as when the listener was invoked in the first place.

Is there a way to force a re-read of the user's permissions in the listener?  And remember, the user is not an admin so it needs to be a function that any user can invoke.

Thanks,

-Greg

[Alexey Matveev]

You should make all changes to the user permissions in the code of listener. I guess your curl command works longer then the listener code.

[Greg Fischer]

I do a waitForProcessOutput after the curl command before I continue in the listener.

So since the listener is running as a non-admin user, how can I update the user's permissions by adding that user to a group?  And making sure Jira knows the user is now part of that group when I set the attribute value?

[Alexey Matveev]

Anyway I would try to use Jira Api. You can set the user under which the listener is performed with JiraAuthenticationContext

[Greg Fischer]

Tried that - did a ComponentAccessor.getJiraAuthenticationContext().setLoggedInUser(adminUser);

and also got an admin user and used that ApplicationUser in the update calls on the attribute - neither worked, and in the log file the message saying the update failed because the user doesn't have the correct permissions has the invoking user in the message.

[Alexey Matveev]

It means that even the admin user can not update the field? Are you sure that is the correct behaviour? Moreover, there are no permissions to secure a field. That is why it all looks unusual to me.

[Greg Fischer]

The admin user absolutely can update the field.  If I login as admin, I can update the field directly on the screen.

Moreover, there are no permissions to secure a field. That is why it all looks unusual to me.

When the field you are trying to allow all users to update is a Portfolio field that only Portfolio users can touch, and Atlassian won't address the enhancement request to allow non-Portfolio users to update those fields without having the ability to create Portfolio plans.... :-( .

[Alexey Matveev]

Ah, we are talking about Portfolio. I am confused why curl does not work for you, if you wait till the end of the curl execution, but I would still do all changes with the user in the listener by Jira Java Api. It should work.