We have 2 Atlassian connect app, one for confluence (The main app) and another on Jira.
We want to associate the confluence clientkey with the Jira clientkey, one user will need to add both plugins and we want them to communicate between them when they are dealing with the same user.
We have thought about baseUrl, but we think it’s fragile and can change for some reasons…
We saw an endpoint : /rest/applinks/3.0/applinks. Maybe we can use it ? But it doesn’t look like it’s a public rest api.
Does it have a clear method to do this?
So far in our little investigation in the ecosystem, here are the current solutions we’ve heard:
- Some vendors do it by matching the BaseURL, but it seems unreliable,
- No-one uses the /rest/applinks/3.0/applinks list,
- Most vendors have 2 Connect apps and then do a user handshake, which has the added bonus of allowing multiple instances to be connected.
We’d be happy to hear about an officially recommended method from Atlassian.
There is a concept of a
cloudId which ties a group of tenants of different product types together. At one point the
cloudId was going to be added to the installation payload, but there was some controversy within Atlassian about the exact semantics of cloudId and the plans never went ahead.
The relevant issue is AC-2379, but this has limited visibility. This is the only way I know of to reliably associate tenants without some kind of manual user assistance.
You may also be interested in the following article: Relationship between cloud id and client key
Excellent answer, @dmorrow . Although it doesn’t give us the perfect solution (we’ll implement a user handshake), at least we know that there is no perfect solution for this.
@dmorrow do you know any method of fetching cloudId from a Connect app?
I don’t think there is any way for a Connect app to retrieve the
CloudId corresponding to a given tenant because the development team has been reluctant to expose it since there was some controversy within Atlassian about the exact semantics.
@dmorrow This information is exposed when you are using api.atlassian.com in “self” property of Jira issues:
self: "https://api.atlassian.com/ex/jira/$CLOUD_ID/rest/api/3/issue/10000", so it makes me wonder why this information is not generally available.
I have a use case when users can download the same Jira issue using both methods: via Connect, or via api.atlassian.com, and it’s difficult to guess whether it’s the same entity.
Should I look for a permanent workaround, or the controversy around cloudid in connect can somehow be resolved in future?
Yes, the cloudId is exposed to OAuth 2.0 (3LO) apps. My guess is the team implementing OAuth 2.0 (3LO) app didn’t have the same debate as the Connect team before including it in the API. The Connect team saw the CloudId being exposed to OAuth 2.0 (3LO) apps and consequently started work to include the CloudId in the app installation payload, but this work stopped when architects raised a flag questioning the future of CloudId in the domain model. I don’t see any effort to resolve this, so my advice would be to find a workaround if you can.
I’ve been wondering about this, so a user handshake sounds like the best approach right now?
Yes @james.dellow, a user handshake seems like the current way to do it.
- We’re happy with our little experiment about it, because it allows the customers to link 1 Jira to 2 Confluence instances, or reverse.
- I’m happy with it, because it required our developers to think in terms of “Ok, what if we have more than 1 linked instance =>we can’t assume there is a default one, we need to put lists everywhere and iterate, and so on.” I’d say it is much future-proof to make our software support the n-to-n relationships by default.