Hi Sean,
As I read this RFC, I am impressed by the amount of thought that has been put into solving the problem. That having been written, the level of complexity leads me to think that this could perhaps be an XY Problem.
This proposes solving the problem of “how do we allow upgrades from Connect to Forge without requiring explicit admin approvals”. I argue that the bigger problem is “apps need a pathway to always be running on the current app version (whether on Connect or Forge) without requiring manual admin approval, but in a way that maintains enterprise customer trust”.
Atlassian does not let customers run a year-old version of its cloud products. App vendors do not want to be doing this either, but the Atlassian version model forces them to anyway.
The Cloud platform is continually evolving: Atlassian regularly creates new permissions, and sometimes, apps need to adopt those permissions to continue functioning correctly. Despite the Atlassian platform being fluid, apps can easily get stuck on old versions because not 100.0% of admins will upgrade. Plenty of contortions have already been implemented (such as the Forge prior-version minor updates) in order to try to make this more palatable. But still, no vendor actually wants to maintain four different versions of their product because some admins forgot to push a button (especially if Atlassian-forced API changes need to be backported to ’n’ older branches). At best, it is a lot of work. At worst, the old versions cannot work properly and it generates customer complaints.
This was sort of vaguely manageable in Connect since the permissions are broad and the frequency of permission changes was relatively rare, but with the finer-grained permissions in Forge, the problem snowballs. This in itself would make me very reticent to adopt Forge from any Connect app (even just a descriptor migration and nothing else), because you get immediately tied in to the finer-grained Forge permission model (even assuming you are using classic scopes).
I propose that a better solution is to figure out a reasonable pathway (acceptable to vendors and also enterprise admins) to get all apps running on the current version, with the full set of required permissions, within a reasonable period of time. If you solve that problem, I think it automatically solves the specific problem proposed in this RFC, plus a lot of others that vendors have been complaining about for years.
Throwing out some ideas:
-
Let individual admins decide if they want to automatically auto-upgrade apps or not through a configuration option.
-
If admins do enable auto-upgrade, let them decide if they’re OK with automatically upgrading permissions within a limited set of scopes only (for example, if the app has the equivalent of Connect READ permission only, then auto-allow the app to inherit permissions to READ any other object type, but don’t allow auto upgrades to WRITE-type permissions). Or perhaps the admins can also decide that they want to automatically accept all permission upgrades. Maybe there are also options to consider here related to accepting Forge egress permissions and other sensitive features.
-
For permission changes that are not auto-approved by config setting, give admins a (say) 14-day review period to review the proposed upgrades (while the app is still running the prior version with old permissions). Also allow the admins themselves to decide what to do if the delay expires without action on their part: either disable the app (until the change is manually approved later), or auto-upgrade upon expiration of the review period. This ensures that, after a certain window, there are no active apps running old code, and it allows admins to tailor the upgrade strategy to their security policies.
-
Nag product admins sufficiently during the review period to get them to take action (and continue nagging afterward if there are disabled apps). This might include sending emails, banners in the UPM or the fancy new admin app interface, pop-up flags on the dashboard when admins log in, etc
-
Have CCP (or whatever) enforce that new permissions be accepted before letting the “renew” button be clicked for an app.
I recognize that this effort would likely exceed the presumed scope of responsibility of the Forge team that is responsible for writing this RFC. Regardless, I still think it is the right thing to do and that it would be worth the effort to coordinate.