nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Any way, via REST API, to mark an issue as approved by someone other than the authenticated user?

Philip Colmer

We're trying to develop some automation which, as part of its workflow, needs to occasionally mark issues as approved but on behalf on someone else.

It looks like this isn't possible but I thought I'd ask here as a double-check ...

Calling the "Answer Approval" API marks the issue as approved by the authenticated user. The documentation says "The approval is assumed to be owned by the user making the call." which sort of suggests that there is a way to mark the approval as owned by someone else but the API documentation doesn't suggest how.

We've tried editing the custom field that holds the approval data so that the "approverDecision" value for a different user is set to approved but that doesn't seem to write back, even though we don't get an error.

I appreciate that this may be by design. I was just wondering if there was something I hadn't thought of that might allow me to achieve what I'm after.

Accepted answers

Philip Colmer

We've solved this, in the end, by installing a Jira app that doesn't really do anything other than store the app's credentials. We then use those Connect app credentials to create a new "run as" JWT for the user we want to impersonate.

All comments

Joseph Chung Yin

@Philip Colmer -

You may already try this, if not, take a look at the following high-level suggestion:

1) Ensure the authentication user has the necessary rights as the approver + the ability to edit the issues in your JSM project.

2) Update the issue's approver to the authentication user first, and then approve the issue at question. At the same time, you should also add a comment to the issue for the action (meaning the new approver is approving the issue on the behalf of the original approver assignee).

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Technology Applications Team

Viasat Inc.

Philip Colmer

Thanks for the suggestion. We had considered this as a "last resort" option. We're trying to keep the data as clean/accurate as possible and, unfortunately, posting a comment to explain who really did the approving isn't as clean as we would like.

This is for an internal-only application so I'm now giving some thought as to whether or not we can implement a minimal Connect app and use the credentials from that to go through the process of impersonating the original user. But that is not for this forum - I'll post it over on the developer community.

Thanks, though.

Philip Colmer

José Henrique Lincoln Da Fonseca Felizardo_l566zt

Hey @Philip Colmer , can you provide more details about how do you solve this issue? Your environment is JIRA Cloud? Your team create this Jira app? I have same issue here and need to help to solve.
Thank you!

Philip Colmer

Hi @José Henrique Lincoln Da Fonseca Felizardo

I wrote a very small Python script which gets deployed to AWS as a Flask app. The script implements routes for:

/atlassian-connect.json - returns the contents of the static configuration file

/events/installed - checks that the authorization header is valid, retrieves the base URL, oauth client ID and shared secret from the payload and stores it in an AWS secret.

/events/uninstalled - checks the authorization header is valid, retrieves the base URL from the payload and stores that in the AWS secret with None as the client ID and shared secret.

The configuration file has a name, description, key, base URL for the Flask app (so you have to deploy it to get the base URL then update the config file and deploy again), vendor, authentication type, scopes (important - READ, WRITE, DELETE, ACT_AS_USER), api version and lifecycle - which specifies the installed and uninstalled routes.

That then gets published to Atlassian Marketplace as a PRIVATE application. Do not do anything other than a private app for this.

So, at the end of all that, you should have an AWS secret that contains a client ID and shared secret ... so you can now have code running elsewhere that retrieves that and makes the appropriate calls to the Atlassian API to impersonate a user and get a JWT as if they were that user.

Hope that is enough but do ask for more clarification if you need it.

Regards

Philip

unknown

Hi @Philip Colmer ,

Could you help describe the mechanism in more detail? I'm a bit lost at it, so you create another separate service to do the impersonation? While the REST API for approval is being executed in another app?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management