Interacting with Other Atlassian Apps
There are several cases for making an HTTP request from a host application to another Atlassian application, for example:
Create a Confluence space when a Jira project is created
Automatically create Confluence pages for certain types of issues
Create release notes when a Jira version is released
Automatically decline a pull request when the associated Jira issue is closed as Won’t Fix
Typically these are done through calls to the REST API of the other application, or to a script endpoint. However you can also use remote events, or remote control to do the same thing.
Via App Links
Application Links exist to handle authentication when making calls between applications.
App Link Configuration
App links can be configured in one of three ways
However only the first of these is currently recommended by Atlassian, and is the kind we will focus on.
Note that all of the examples provided below also work with Trusted applications.
OAuth comes in two flavors: OAuth authentication and OAuth with impersonation. Impersonation should only be used where the sets of users on both apps are the same.
If you can enable OAuth with impersonation you should do so, as it allows you to make requests from code on behalf of the user that invoked the function (eg event, workflow function etc), without any interaction on their behalf.
The following image shows the outbound configuration the source app, and the inbound configuration for the target app, when two-legged oauth with impersonation is enabled.
Configuration with 2 legged-oauth
If you create a new reciprocal app link, and check the box confirming that the set of users are the same on both apps, you will get the configuration above.
Making Requests as the Current User
If you wish to make a remote REST request on behalf of the current user, you can do so using
com.atlassian.applinks.api.ApplicationLink.createAuthenticatedRequestFactory(). The following example calls a Jira endpoint that returns details of the user making the request, so is useful for experimenting.
This example should work calling Jira from Bitbucket Server, Confluence, and Bamboo. To call another app you should change the endpoint, as this one exists only in Jira. Note also that in Jira you will get the
ComponentAccessor rather than
Line 13: Get the primary Jira application link - if you have multiple, see Two-legged OAuth Without Impersonation.
Line 15: Get the OAuth provider.
Line 28: The response is JSON, so convert it to a
Line 32: Execute the request.
You should see a log message like:
2016-05-05 10:15:34 [http-bio-8080-exec-10] DEBUG c.o.s.runner.ScriptRunnerImpl - Making the request as: admin
Making Requests as Another User
That’s great, but let’s say you want you want to create a new page in Confluence on a Jira transition. If the user executing the Jira transition does not have permission to create a page, this will fail. You may well want this to happen, indeed it’s probably the safest course. But let’s say you want to create a Confluence space on a transition, perhaps as part of a provisioning process. If this is the case you will need to temporarily impersonate a user on the target system that has the create page or create space permission etc.
How you do that is unfortunately not standardized across applications, so what follows are examples for each application supported by ScriptRunner:
It’s advisable to create a user called for example:
deployment, which has admin rights. You can create a password which can’t be used, so you will know whenever you see this user in the audit log, that these changes are the results of your integrations.
From Bitbucket Server
Two-legged OAuth Without Impersonation
If you have different sets of users between your apps, you cannot use two-legged authentication with impersonation. The problem here is that user jbloggs on Jira may actually refer to a different jbloggs on Confluence. Atlassian expresses this in their documentation as "users must have the same password", but I believe they mean that the user for any given ID should be the same person.
If you just have some a subset of users in one app that all exist in another app you should be OK using 2-legged with impersonation.
If not, your alternatives are:
specify a user on the target app that all remote requests via this link will execute as. However, as you can’t specify a user with admin rights this may not be useful
prompt the end-user to do the login dance, which will allow them to grant the source app to make requests to the target on their behalf.
This code sample focuses on doing the dance.
Once the user has clicked the link which takes them to the page below, the code will proceed beyond the
The problem you may encounter is that there may not be any easy way to present this URL to the user in the web UI. In this case, you could just fail the transition or whatever, or in Jira, add a message into the UI: