User calling REST endpoint not considered in history of issue

[malbrecht]

Hi all,

hopefully you can help me solve the following scenario.

For some reason, we'd like to implement a button to the "more" menu in a Jira issue to flag the issue as "waiting" (->customfield). This is done by a button (only shown for certain usergroups) calling a REST endpoint. The REST endpoint updates the issue: setting the customfield and creates an entry in the history according to the action.

This worked for several months, but I realized recently, that no longer the logged-in user who is pressing the button is considered for the respective entry to the issue's history. The users appearing in the history as having set the flag in the issue seem to be randomly taken from the usergroup for which the endpoint is valid. Maybe this is related to an update of scriptrunner or of our Jira instance.

So how can I modify my script to get the user who pressed the button to have a correct entry in the issue's history?

The code for the REST endpoint is currently:

import groovy.transform.BaseScript

import javax.ws.rs.core.MultivaluedMap
import javax.ws.rs.core.Response

import com.onresolve.scriptrunner.runner.ScriptRunnerImpl
import com.onresolve.scriptrunner.runner.rest.common.CustomEndpointDelegate

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption
import com.atlassian.sal.api.ApplicationProperties
import com.atlassian.sal.api.UrlMode

@BaseScript CustomEndpointDelegate delegate

def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def issueManager = ComponentAccessor.issueManager
def cfm = ComponentAccessor.customFieldManager
def om = ComponentAccessor.optionsManager
def flag = cfm.getCustomFieldObject('customfield_10002')
def applicationProperties = ScriptRunnerImpl.getOsgiService(ApplicationProperties)

flagIssue(httpMethod: "GET", groups: ["xxgroupxx"]) { MultivaluedMap queryParams, String body ->

def issueId = queryParams.getFirst("issueId") as String
def issue = issueManager.getIssueObject(issueId)
def fieldConfig = flag.getRelevantConfig(issue)
def value = om.getOptions(fieldConfig)?.find {
it.value == 'waiting'
}
issue.setCustomFieldValue(flag, [value])
issueManager.updateIssue(user,issue, EventDispatchOption.ISSUE_UPDATED, false)

def baseUrl = applicationProperties.getBaseUrl(UrlMode.ABSOLUTE)
return Response.temporaryRedirect(URI.create("${baseUrl}/browse/${issue.key}")).build()

}

[Radek Dostál · Accepted solution]

What happens if you move the

def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser

to the flagIssue method itself?

I imagine that this endpoint gets "initialized" when you start up Jira/ScriptRunner plugin, but since the user is only calling the GET method, the user variable has already been initialized on start up so it doesn't dynamically get the current user calling the method. 

[malbrecht]

Thank you Radek! Works.

Sorry, it was so obvious... I didn't see the forest for the trees.

[Radek Dostál]

One more thing I noticed checking the documentation right now:

 # https://docs.adaptavist.com/sr4js/latest/features/rest-endpoints/rest-endpoint-examples/get-the-user-making-the-request

I think that 

ComponentAccessor.jiraAuthenticationContext.loggedInUser

might work because you are using this from the UI and the user is already logged in when they do that call in the first place.

If however you were calling that method remotely from outside Jira, it probably would get "null" for the user, but I am not sure.

So in the case you were to call this remotely I'd probably change the currentUser part to the above in their scriptrunner documentation, I haven't tested or tried, just noticed this and that's my theory what would happen, but maybe it would work either way if you supply user credentials in that remote request.

[Becky Yu]

This helped me too! Thank you Radek!

Here is the new link to the documentation you mentioned since the one is unavailable : https://docs.adaptavist.com/sr4js/latest/features/rest-endpoints/get-the-user-making-the-request