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.
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.
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.
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.
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.