I still think the best way to handle upgrades would be automatic, similar to AndreasEbert’s comment or james.dellow’s comment above. As I wrote last year in RFC-71:
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.
That having been written, the scope of this RFC suggests that the Forge team is looking in a different direction.
My suggestions in this thread to be able to completely brick our own apps (by turning off modules and triggers if permissions are not correct) is second-best, but it is probably workable if the “better” approach above is not in scope for the short term.
One of the main downsides of the latter approach is that it imposes a lot of work on every app vendor, since we would all need to define the current permission set, tag every module and trigger, and generally jump through hoops. Multiply this by a thousand vendors and there is a lot of effort that could have been avoided.
What about creating some sort of single top-level flag in the manifest to the effect of “please treat the app as unlicensed if not all permissions X,Y,Z are present”?
Vendors already need to handle the condition of being unlicensed (reducing the duplication of effort), and the handling of “apps without license” case is probably very close or identical to the scenario we would want to present if the user had an outdated app. If needed, you could probably also annotate the license check APIs to identify this specific case (user is actualy licensed but app is outdated), in the event that the app needs to deal with it differently.
Ideally, apps in this state should have this information surfaced in the UPM (or whatever it’s called now), calling out to the admin that they need to upgrade.