Can anyone from Atlassian comment on this? @scottohara raises a very valid point in that there might be a situation where such an innocent mistake should be reversible. I’d rather not use more resources than needed and simply reversing such a small mistake would be preferable to a lot of people.
@nmansilla @cmacneill Ran into more ore less the same issue as scottohara Is there really no way? We are using our instance for years. So we cannot create a fresh instance.
2 Likes
It seems this also occurs when trying to install the same add-on in development mode from different locations. So even when not mixing it with the marketplace version. Can somebody confirm this?
One and a half years later, this issue continues to annoy developers all around the world on a regular basis. As others have written, if one person installs the app on a test instance from the Marketplace once, whether for testing purposes or by accident, that instance is ruined forever.
It is still unknown what the security incident was that led to this, why it couldn’t be fixed by showing a warning rather than preventing the action, and why this was also activated for development instances rather than just regular instances.
10 Likes
Same problem here. Any update on this, Atlassian?
I also feel the pain. We just recently got into developing private apps for internal use only.
Had setup a free-tier dev cloud instance for testing apps running on local devmachine via ngrok tunnel.
We had followed official guides on how to add apps to the Marketplace privately and enabled private listing in “Manage apps > settings” in our production instance.
Then we successfully installed the app by pasting the URL of the descriptor via “Manage apps > Upload app”.
When uninstalling the app you’ll get a notification that the app has been successfully uninstalled. Upon re-installing (a newer version of the app) you will get this error as described in the first post.
So the confusion from UX standpoint would be: how come I can’t re-install an app I had successfully installed and uninstalled previously in the first place?
Devs google the error message and ended up here.
4 Likes
just run into this issue and as a result can no longer use my cloud instance for development. We have a private DEV plugin and I just wanted to test the release candidate from the url given my the token. Now I can’t use my ngrok tunel version anymore, which makes my personal jira cloud instance unusable for me
Hi @m.herrmann I too have rendered my dev instance unusable due to this issue. Important to note but not altogether obvious is that when using private tokens you must copy and paste the token ID into the UPM. Not the generated link which points to the marketplace.
Same problem here 
. IMHO, there should be a way to unblock the installation of the development version of the app. I don’t see any security problem if the unblocking is done by Atlassian if the owner of the instance explicitly ask for this via a support ticket.
1 Like
We ran into this issue as well and asked help from Atlassian. They have this suggestion ticket too: [CONFCLOUD-72600] Allow admins to reset app state for private listings - Create and track feature requests for Atlassian products.
1 Like
Not sure why this is news? We have not been allowed to install dev apps with the same key in the same instance where prod has been installed for a year now. Not a new behaviour at all
We are fixing a similar issue. I really want this limitation to be removed.
Same here, staging instance that needs the staging version, not the production one!
1 Like
To anyone having this issue: I just got my instance “unlocked”, i.e. can install my plugin via URL again, after asking for help via a support ticket. This is also mentioned as a workaround on the suggestion ticket mentioned by @m.khairuliana
https://jira.atlassian.com/browse/CONFCLOUD-72600
2 Likes
Not sure why the hell this is still a problem, but it is. I’m having to burn time helping a fellow developer with this. The app listing is/was/will always be a private listing so this “security change” is not applicable in this scenario, its just another hurdle in Atlassian Marketplace development.
1 Like
@tpettersen this is really poor devex. Broke our staging environment, blocked automated tests, took us some time to figure out it was an Atlassian problem, then a marketplace support ticket, and then a general product support ticket to resolve.
@boris this is a fairly ancient problem and I suspect I’m missing some context, so forgive me if I’m asking a naive question or misinterpreting the issue here.
Would a reasonable workaround be to just augment the key for non-prod instances (e.g. have my-cool-app for your prod version on Marketplace, and my-cool-app-staging for a staging version, and my-cool-app-bberenberg for local dev). I vaguely recall using a pattern like this in a former team of mine that owned a family of Connect apps.
Also from the tone of your comment, are you impacted by some recent change to this contract? Or is it the original issue of key conflicts described by OP?
To be honest, no it wouldn’t. The app key is tied to a lot of other stuff as well (for instance the Email API). Also it doesn’t feel fair to put the burden on app developers.
1 Like