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.