This seems cogent. I’m going to assume this is correct, unless I hear otherwise.
30 days from when?
That’s the recommendation or as I now understand it, treat as a new install if:
- Not signed & clientKey doesn’t exist
- Signed but has new clientKey in the body, but don’t delete the data from the old install for at least 30 days
@HeyJoe Question about the 30 days:
I’ve had customers whose license expired. They were then in an expired state for longer than 30 days (about 2 months if I remember correctly), and then they got a new yearly license retroactively from the date that their license expired.
As a marketplace partner, we have no insight into these (custom) licensing processes, but I feel the period of 30 days is way to short.
1 Like
Does the import operation, which results in a change of clientKey, change the app’s license status on the source site? Does it become Unlicensed? Yo, @cmacneill. Yo, @HeyJoe.
Hey all! Attempting to answer some of the newest questions. I’ve also pinged Conor to jump in,t oo 
Does the import operation, which results in a change of
clientKey, change the app’s license status on the source site? Does it become Unlicensed?
The import operation uninstalls apps in the destination site. After the import, apps are manually re-installed.
I’ve had customers whose license expired. They were then in an expired state for longer than 30 days (about 2 months if I remember correctly), and then they got a new yearly license retroactively from the date that their license expired.
As a marketplace partner, we have no insight into these (custom) licensing processes, but I feel the period of 30 days is way to short.
Ideally, you will have a customer-visible data retention policy that explains the behaviour of your app in this circumstance. 30 days is our recommendation, but you could set a different duration. Atlassian’s policy (Track storage and move data across products | Atlassian Support) is 60 days.
30 days from when?
30 days from when the record in your database, identified by its clientKey, becomes detached from the site URL, by virtue of not being the most recent valid installation against that site URL.
There’s a tonne of information in this thread. Can we make sure that it gets published as part of the Jira Cloud developer documentation
OK, so the fact that the secret key is currently shared across all sites was news to me. TIL. I appreciate the note about not relying on that, though I have to point out that it is a bit cheeky to then rely on exactly that in the retry process being suggested.
I know, sorry for being cheeky! I guess what I"m trying to say is that we’d prefer to minimise the circumstances where this behaviour is baked into the contract, since there’s some internal discussions happening right now that could result in changes, and it would be good to minimise the blast radius of any corresponding breaking change.
So it seems to me vendors must have a way to actively verify the “is this client key still active” status. An orphan is only an orphan when this verification fails and then the 30 days start ticking.
You could implement some kind of heart beat process to verify that the client key is still active, but if you receive a valid installation request for a new client key on the same site base URL, you can assume that the old client key is no longer active.
Can this be run by Atlassian Security team please?
I’ll follow up and get back to you!
1 Like
Thanks Joe. What about on the source site? Does the app become unlicensed on the source site?
1 Like
No, the export doesn’t alter the state of the source site.
@HeyJoe @cmacneill Greetings, may I know if the follow-up installation request works for manually uploading app in UPM as well? I am trying to replicate the behaviour in my development instance, but I did not receive any follow-up installation requests so far. How would you recommend to test it otherwise?
Currently there is a single secret for the app shared across all installations/all sites. There are some downsides to this approach, so I’d recommend avoiding relying on this mechanic where possible (ie. assuming that the secrets can be different per site would be a more future-proof assumption).
This is new to me as well. Is it because of this? Moving away from per-installation shared secrets for apps
Via @marc
I’ve had customers whose license expired. They were then in an expired state for longer than 30 days (about 2 months if I remember correctly), and then they got a new yearly license retroactively from the date that their license expired.
As a marketplace partner, we have no insight into these (custom) licensing processes, but I feel the period of 30 days is way to short.
I think it would be acceptable to increase the grace period for cleaning up these installations, in accordance with your published customer terms.
We purge unlicensed sites after a subscription is lapsed at the 15 day or 60 day mark ((Ref: Atlassian Cloud Licensing | Atlassian)
Data retention
After you have been unsubscribed, Atlassian retains your data for 15 days for trial sites or 60 days for paid subscription sites.
Your data will be deleted 15 days for trial sites or 60 days for paid subscription sites after you have been unsubscribed due to missed payment for an Atlassian product subscription.
Via @ChinTiongTan,
Greetings, may I know if the follow-up installation request works for manually uploading app in UPM as well? I am trying to replicate the behaviour in my development instance, but I did not receive any follow-up installation requests so far. How would you recommend to test it otherwise?
This behaviour does not work for locally-installed/manually-uploaded apps. It only works for apps installed via the Atlassian Marketplace.
2 Likes
Greetings, appreciate the prompt reply. Now it seems to us that the follow-up installation request is just signed with the old sharedSecret, but the JWT issuer is still the new clientKey. Is that right?
Exactly, I’ve read the thread until this point, and I’m not even sure anymore what was the problem… Should be much easier to clarify what is going on in each relevant case by just drawing some simple diagram
Btw we encounter such “fixed” issues now again with the newest libs (spring boot) it’s really confusing what’s going on
So… did the documentation ever materialize? These threads do not make a developers life easy to have a definitive picture of all mechanisms in play.