Hi @AngelinaIgnatova - Responding here because the RFC-106 thread was auto-closed:
I understand the theoretical vision of having permissions being related to app features, and while it is a good one, the reality of developing for the Atlassian platform makes practice different from theory:
The set of permissions is often a moving target, even in the presence of static application features. Disjointed teams from across Atlassian work on product APIs, and new permissions sometimes appear without warning, or permissions change on old APIs.
For example, Confluence V.2 RBAC APIs were recently introduced, and these require the new read:space.permission:confluence permission. Previously, the V.1 APIs required only read:space:confluence.
History suggests that RBAC will be made mandatory at some point and the old APIs removed, so all apps will be forced to switch.
At this point, I am not even adding new features to my app: I am required to make this change so that my app remains functional, and it will break for any admin who does not update. (What would I even name this new “feature” in my Forge manifest for your future milestones? The please-dont-break-my-app-with-rbac feature?)
This is just one recent example, but there have been a few others like this in the last year as well. I am also sure that Atlassian will continue to regularly introduce new product concepts that include new permissions, and apps will be forced to adopt these permissions just to remain in a working state.
Connect apps were somewhat insulated from these issues because the scopes were broad, but this becomes an instant problem for Forge apps. The last official word I recall was that apps must remove all Connect scopes in the next four months in order to avoid being penalized on revenue share, so apps cannot reasonably use the inherited-Connect-scopes workaround either starting in 2026. (Please correct me if I am wrong.)
I would gently suggest that this overall scenario also “does not align with customer expectations” and I hope that Atlassian would consider this in future milestones. Finding better ways to nag admins to upgrade only goes so far and you are not going to get 100% compliance.
Not every customer is the same, and while I am sure that some sensitive customers may indeed require approval for every single granular permission elevation, I suspect that there are also plenty of customers (perhaps even the majority) who would be receptive to receiving automatic updates within the same general sets of scopes (read, write, admin, impersonate, etc), perhaps after some notice period.
I can add that effectively every customer has already been operating under this model for years (with Connect) and still passing whatever audits that allowed them to use Marketplace apps.
Perhaps Atlassian could consider allowing customers to decide whether they need to audit every single permission change, or if permission “upgrades” are deemed acceptable if they remain within the existing higher-level scopes.
If this has not already been done, maybe Atlassian could also consider running a focus group or whatever to gather the data it needs to back a decision such as this? It admittedly seems unlikely that something that was acceptable (even if grudgingly) for the last 10 years has suddenly become completely unacceptable to all customers.
In short, there has to be a happy middle ground somewhere that will align with customer expectations (realizing that not all customers are identical) while also allowing app vendors to minimize headache and ship apps that actually work. As a vendor, that would be my end goal.