A quick question: how or where the end user / Jira admin will see maintenance end date for the apps? I understand it’s a side question, but if you are to fix pain here, this would be way more important one from my experience.
2 Likes
Just want to note that continuing to have a REST API to install apps from URLs is essential. I can deal with it being via admin.atlassian.com instead of the actual Jira instance.
For example, we run func tests in our repo on push. The build will start a Cloudflare quicktunnel so that it has a public domain like four-random-words-here.cloudflare.com, then will use a development Jira instance and install four-random-words-here.cloudflare.com/atlassian-connect.json via a POST to the-jira-dev-instance.atlassian.net/rest/plugins/1.0/.
If I instead have to POST to Administration or something that’s fine. But having to use a headless browser to click around would suck.
Thanks!
11 Likes
To add to @AdamAhmed’s feedback, our integration tests are already regularly being broken by various UI modals / popups / ads that Atlassian teams put into the products. The more we can do in our tests without having to go through the UI, the more consistently we can release products to customers without manual interventions.
5 Likes
I completely understand that an improvement for managing apps on large deployments is very welcome to the people that manage those deployments.
But from a development perspective removing the ability to install/manage apps within the product itself (current “Manage apps”) will result in significant development delays next to a significant increase in developer frustrations having to click 2-3 times as much for the same action.
Why not keep the original Manage/Find Apps sections and add the new admin sections?
2 Likes
Time for some sweet bug reports from installing private apps using link from descriptor 
Feel free to reach to me if you will not be able to reproduce them.
As others pointed out, it takes now more clicks to perform same actions, so to prove it just count clicks and refreshes.
All actions made in new UI unless specified.
I didn’t discover different behavior when using and not using custom domain.
Didn’t observe difference between Jira and Cofnleunce apps.
A. Providing Trial token does not affect status of an app
- Install app
- Provide trial token
Expected:
In new and old UI, status of app changes to “Active trial”
Actual:
App still says unlicenced, despite providing valid token
Recovery step:
Use old UI
B. Unable to Stop Trial when app was activated using token in old UI
- Install app in old UI
- Provide trial token in old UI
- Go to new UI
- Click “Stop trial”
- Click “Usubscribe”
Result:
"Something went wrong
Unsubscribe failed"
Note:
Clearing token does not help
Note 2:
There is a risk of leaving many apps in uninstallable state, if activated with tokens in old UI
Recovery steps:
Uninstall in old UI
C. After Install app is not visible on list of apps
- Install app
- Go to Installed apps tab
Expected:
App appears on the list
Actual:
App is not on the list
Recovery steps:
Refresh whole page
D. After Uninstall app is still visible on list of apps
- Install
- Click uninstall
Expected:
App disappears from the list
Actual:
App is on the list
Recovery steps:
Refresh whole page
2 Likes
I appreciate you taking the time to record the videos Remie 
One note on the entry point: you won’t have to go through the admin.atlassian.com to get to your app list. The UPM “manage apps” entry point will take you straight to your app list.
The deprecation will occur in Feb next year. Until then both experiences will be running alongside. You will see improvements becoming available in Connected Apps over the coming months and community feedback will help us in our work
1 Like
Definitely understand the pain of having to rely on headless browsers for such tasks!
On this one, we don’t expect the UPM backend to be decommissioned any time soon, so the REST API should remain available even after the change in this post.
Moreover, as we’ll still need an API for the admin.atlassian.com frontend even if the UPM backend were to disappear at some point in the future, I see no reason for us not to continue to provide access to the direct API call for development purposes.
8 Likes
Hi @dmitry.astapkovich this is an interesting point. Have you received customer requests re app maintenance dates? How regularly is app maintenance run and does this always result in down times?
Hello @JakubGladykowski ,
Thanks for reporting the bugs and the issues that you have been facing.
The team is taking a note of the issues and will be working on this soon.
For A and B, I believe these issues will go away in the new UI when license state testing is made available by end of week. Previously, the UI would set some defaults (such as Active Trial) on any token update but post the release of license state testing on new UI, there will be an explicit option to select the license state while setting the token.
We have noted all these issues regardless and appreciate the time you have put into describing them.
Thanks
@JuliaDaehne given that there is still a lot of room for improvement and that this impacts Marketplace Partners, can you please share with us why this wasn’t created as an RFC instead of an announcement?
CC: @ibuchanan
5 Likes
Hi @markrekveld the entry point for developers through product will remain, so you can still go through your known in product “apps/manage apps” path. This will direct you to the Connected Apps page where you have 1 additional click to make to install apps.
App discovery will remain available through product, marketplace and now Connected Apps in admin.atlassian.com
I hope this helps
This redirect is the problem in my opinion. Being redirected out the production you are developing for means you need to go back so you can actually continue the flow after the app is installed.
Also, on the Connected Apps page all the apps for all the productions are listed, will the install/upload action to install an app remember where you came from and auto fill the production? Or will the redirected developer need to remember where he came from?
1 Like
Hi @JuliaDaehne, thanks for the writeup and share.
I’m trying to think through the implications of this alongside the proposal captured in RFC-60. Are you able to elaborate, or even share early thinking, around how these two things may intersect in 2025?
Thank you,
Nick Muldoon
Easy Agile
2 Likes
Hey @markrekveld - in terms of redirecting breaking the flow, the admin site would be opened in a new tab, meaning in theory it would be easier to continue the flow after app installation (you can close the tab and return to the page you were using to test the app).
As for prefills, as the new links aren’t in place yet we don’t have that, however such convenience features that keep context of the product you came from is something we can explore. Let us know if you have any other ideas or preferences that could help you avoid losing context.
That will make the context switch back to the original product easier to do.
I would like to suggest that this becomes a priority, at least from a developer standpoint. I’m not an administrator for a large deployment so cannot comment on how impactful this change will be where. Context switching from even from tab to tab is killing your productivity if you need to think on every switch. If the switch is effortless then the productivity hit is far smaller.
In terms of ideas you could look into sending additional contextual information with the new tab being opened. Like the source site name and product. This could then be used on the admin site page to assist with followup actions like installing an app. The install app dialog could then pre-fill the site/product to install the app on or could ask the user if the action is meant for the site they make from.
Maybe getting to solution specific but I see easy low hanging fruit solutions to overcome the context switching frustrations.
Also to reiterate @remie point, why was this not an RFC?
1 Like
Hi @JuliaDaehne
I first read this as “we will maintain the existing ‘Manage Apps’ page in the product in parallel with the new admin.atlassian.com experience”.
Upon closer reading (and after seeing the banner just added to the top of the current Manage Apps page which says that it will be deprecated by Jan 2025), I now understand that Atlassian will completely remove the Manage Apps page from within the product.
Assuming that this is the case, can we get better visibility for app-specific “Configure” and “Get Started” buttons?
These buttons are often used to access critical product functionality from the UPM, where they are front and center, but they are almost unnoticeable in the new version.
On admin.atlassian.com, there is a tab named “App Settings”, but this tab curiously does not contain any app settings (instead it just has access tokens that are not regularly used).
The actual app settings (app-specific Configure/etc buttons) are hidden in the “…” dropdown on the top right. Can these buttons be shown directly to the user instead of hiding them in a dropdown?
This is a full-page display for one single app and it does not seem like there is any shortage of screen real estate, so I would hope there is space to show them as buttons somewhere on the main page, without having to click any tabs.
The existing “App settings” tab could also stand to have a better title, given its content.
5 Likes
@scott.dudley I agree - the ‘app settings’ name is somehow misleading, or rather: the expectation would more likely be around app settings and configuration. We are looking into making this clearer and configuration more prominent
@JuliaDaehne or anyone else from Atlassian, can you please respond to the open questions by myself, @markrekveld or @nick?
1 Like
Hi @remie could you please elaborate which question I have not answered yet? I believe the points from @markrekveld have been addressed but thanks for pointing me to @nick open question which I had not seen.
@nick RFC-60 was about Marketplace monetization strategies. Are you asking how we will handle the license de-coupling and app edition use cases from an app management point of view?
@JuliaDaehne I didn’t see a response to my last comment
The gist of it, Why was this not an RFC? Context switching will be killing for developers even if new tabs are used as the new tab doesn’t include the origin context. Why only look at org admins and not devs?