We are looking to introduce optional scopes in Forge.
Currently, all scopes mentioned in the manifest file are required by default. These cannot be selectively chosen by admins, or consented to for a limited time period.
Feedback
We’d love to hear your feedback to understand the following -
What use cases do you see for optional scopes?
What type of scopes would you like to make optional? Would you like to keep some as required?
Would you require your app to find out about scope selection and changes? How would you want this to happen (e.g. app context, new events)?
With the introduction of app editions, we’d like to offer additional features that require extra scopes. Therefore, it would make sense to define different scopes for each app edition.
Cheers
Mainly, we are an API heavy app with a lot of optional features that can be configured. Requiring all scopes (e.g. incident, assets, …) upfront is
a) Looking scary from an admin perspective
b) Requiring major updates for every scope change, which rarely happen, because it’s just not discoverable by admins that an update is pending
This leaves us with a fractured app install base (which thankfully is a bit less problematic with Forge, as you can backport to older major versions now).
Yes, we’d like to have a basic set of scopes as required scopes, while others could be optional. Ideally those could be consented afterwards from any app page (like an configuration page of our app where we’d say: you need to consent first to use this feature and then open a prompt to do so. Maybe as a Forge Javascript API.
I’d hope that this could apply to almost all scopes, either OAuth 2.0 based ones or Forge based ones, e.g. I could also think of having the Rovo one optional.
The Forge app updated event (avi:forge:upgraded:app) would be a good place for this, I think, but we could also work with an additional one (e.g. avi.forge.scope.change:app or something).
My understanding of scopes is currently that they also require the host product to be installed, for example when requesting JSM scopes, your app will fail installation if JSM is not installed.
If this is still unresolved, its a huge blocker to use the JSM API as this would tie your app to JSM only customers, even when you have functionality that works on all Jira editions.
Wait what - is that also the case with Connect on Forge? //edit: Just tested, does not seem to be the case. We have JSM scopes and you can install it on non-JSM instances. phew.
have a look here: https://jira.atlassian.com/browse/ECO-87
I have an app that includes JSM scopes (specifically read:servicedesk-request) and I installed it on a fresh Jira instance that doesn’t have JSM enabled — and it seems to work fine. @ernst.stefan, can you clarify in which cases apps with JSM scopes would not work?
the issue was reported before the auto consent was implemented, so my guess would be its already fixed but the public FRGE and ECO tickets are not updated. It would be good to get that confirmed. I have not had issues myself but I also have not moved to a production release yet.
The issue with Jira-JSM is resolved, i.e., if we create an app with JSM scopes, we can install it on a site which has only Jira installed (but not JSM).
I understand where you’re coming from - I don’t have particular use cases or scopes - but rather feature requirements to support the various infinite list of scopes additions that we and the customer will need to use.
We’d need some way of explaining why blocks of scopes are needed (remember if we use scopes properly - we have to a lot of scopes). So it would be awesome to be able to for Feature X - the following scopes are necessary.
The administrator needs an easy way of going back and approving previous skipped scopes. (And not just one or two scopes - the bundled scopes from above).
Then finally we’d need a way of knowing which bundles of scopes are available (so we can disable or remove features from end users) as well as a way to get reporting on which features aren’t available to what customer (so that we can manage the support requests when they asks when things aren’t working).
The majority of marketplace vendors are very small and lean. We don’t have the resources or desire to fight against unnecessary complexity by building bloated over-staffed organisations.
The simpler the code the better.
Optional scopes potentially means infinite complexity in code.
I’m also vaguely aware of how app versioning plans to be “solved” and that too will add infinite complexity to the app code.
One use case I see is to avoid major version and need for SiteAdmin’s consents:
If introducing new scopes, all marked as optional, would allow bulk-upgrade of the app,
this could benefit teams developing the apps.
Until we transition more apps to Forge and receive feedback or concerns from customers regarding our apps having excessive permissions, it is challenging to identify further benefits from the optional scopes.
Additionally, managing scopes by Site Admins appears to be cumbersome for them. With the extensive range of scopes introduced by Forge, they would either require the scopes to be grouped and clarified by the app (indicating how enabling or disabling them would impact the app’s functionality) or would need to experiment with the app to truly understand the consequences.
Adding optional scopes to the app should not negatively affect UX of the app, so checking by REST calls seems not good enough. I believe the information should be available in app context(s) but some apps might also need events to properly start/disable they scheduled processings.
I can see this capability being very useful for extending the scope of automatic app updates.
Let’s take a scenario where an app declares new permissions but marks them all as optional. In this case, even if a new major version is generated automatically, it could still be auto-updated with the additional permissions disabled. This would allow end users to immediately benefit from all improvements that don’t require new permissions, and at the same time enable vendors to ship fixes and enhancements in a single update without having to maintain legacy code for an undefined period. Both benefits could be realised without having to wait for an administrator’s decision, which might be postponed indefinitely.
For this to work effectively, a few additional capabilities would be needed:
Vendor control in the manifest: The vendor should be able to indicate whether they want to allow automatic updates without enabling new optional scopes. This is not always cost-free, so having explicit control over this behaviour is important.
Administrator notification: Admins should be clearly informed that new permissions are available, but must explicitly decide to unlock new functionality for end users.
The most important point, however, is that this feature should come with proper developer tooling and DX support. We can’t just add a “permissions” object to the context and expect developers to insert yet another if statement every time. With more than 2-3 such optionally enabled scopes, complexity can increase exponentially, and code can quickly become unmaintainable.
Strong support would be essential — for example:
Linking specific features or UI components to their required scopes in the manifest.
Declarative mechanisms to map features to implementations depending on the active permissions.
Many modern frameworks already support battle-proven mechanisms, and Atlassian itself uses them internally. Bringing that kind of support to Forge would make optional scopes a practical and maintainable feature rather than a source of technical debt.
I hope that Atlassian can coordinate these efforts, as there seems so much complexity. E.g. what would happen to an optional scope in an older app edition which becomes required or vice versa? Especially RFC-106 has kind of optional scopes already.
I also commented in the RFC-106 and beside major updates we would use optional scopes to indicate that our App can be used without these scopes just fine but is required for some use cases.
Some examples:
Currently we just have a small getting started page without any user interaction. With optional admin scopes (that are not required after setting up the app) we could implement an app setup step that requires adding e.g. CustomFields or issue types
Our Apps main focus is to read information about this issues, but it’s also possible for the user to inline edit the jira issues. Our App would be able to work for most use cases, if there are companies that are not comfortable with having us permissions to edit / delete issues