Hi @remie ,
I believe a successful AP.request REST API call is already dependent on both user and app privileges - the user needs to have the relevant permissions and the app needs to have the relevant API scopes. This proposal would add additional app access checks.
Regards,
Dugald
I believe a successful
AP.requestREST API call is already dependent on both user and app privileges
I have seen in practice that this is not always the case, as you can extract more information as a Jira Admin via AP.request than you can via your own app call. It might be different for the actAsUser calls via backend
This is indeed true @dmorrow, but that is something app developers control themselves. I doubt there are many app developers that go live without the required scopes. And if they change scopes, they have the ability to control that and provide a proper UX.
With this proposal, AP.request can suddenly stop working without any clear indication why.
Regarding 404 / 403:
I think it should be considered who you want to hide these information from. I can totally understand the use case to hide the existance of content from someone that is not allowed to see the content.
What causes the UI Issue here is that a user is using the plugin that is allowed to see the content. In case of at least Client Side AP.request I would very much prefer a 403 to be able to give the user that hint that we as plugin can not access the requested content.
If that is not possible, at least give us the ability to check if there are any restrictions in place, which would make it possible to show a notice / flag only on instances that have such restrictions
Thank you for this comprehensive RFC @JuliaDaehne!
One scenario that seems not covered yet are strictly API based UIs provided by Atlassian, e.g. the various Jira Open DevOps experiences:
That means that a user might move from a project with app access to one without, continue to use the established patterns outside of Jira (like adding an issue key to a commit on GitHub), and obviously expect that apps just work, with no option for the partner to assist (even though we might be able to deduce the cause in our backend error handling, we have no in-product surface to communicate this).
I haven’t thought this through yet, just wanted to state the problem for starters - one option might be to leverage your in-product app onboarding features to instead indicate blocked apps on the UI extension points where users expects the results of their actions?
In case of at least Client Side AP.request I would very much prefer a 403 to be able to give the user that hint that we as plugin can not access the requested content.
Yes agree, the error message needs to be clear enough for you to act upon, ie show an appropriate ‘app block’ message to the user
Sorry for the delay @boris, I wanted to double-check with the team before responding.
No — this change is focused on data privacy, and has no planned impact on licensing.
I can see where you’re coming from. These changes would theoretically pave the way for turning apps on and off by container for other reasons, such as licensing. However we have no plans to use this functionality for anything outside of the intent described above.
Even if per-container licensing were desirable, there is rather a lot more that would need to change about our platform and commerce systems before we could vary our licensing model.
Let me emphasize the importance of display conditions here.
(Display conditions are “not always” following the latest innovations, like this one, but they are necessary and irreplaceable for a native experience users would expect. They don’t care if the UI/UX is provided by Confluence or by an app, and display conditions are an important tool to implement that.)
Basically: display conditions should support checking the app access rule.
For example, if I have an app that adds its UI elements to Space Settings, to the Space left-bar, to wherever in a space context, I want to be able to hide my UI in app-not-allowed spaces. It is a must.
When an app or apps have been blocked in a particular space or a project, will there be a way for general users to easily tell that blocking is in place?
I agree - users won’t (and shouldn’t need to) understand these mechanics. We need to be able address this directly in the UX.
Hi @james.dellow we are working on app block specific messaging for end users and site admins to make them understand why an app is not working or showing. Example for a blocked Macro this could be something like “an administrator has blocked this app in this space. Please contact your org administrator for more information”
Regarding the 404/403, what happens when those numbers are already used. For instance if I try to get an issue property that doesn’t exist Jira now returns a 404. How do I know that the 404 is a “property doesn’t exists” rather than “customer has remove access” error?
It would also be good to have a screen for each installed app that says these are the permissions that the app wants and these are the permissions that the app currently has. That way problems be easily be checked and when they break the app they can look up what the need to do to fix it.
Not Atlassian - but in that case a user wouldn’t have access to the project - yet alone the issue (the issue either returns 404 or 401).
I’m thinking that we (the app) might need to add in a check of “did you really have access to this issue?” into our apps. (which yes - it’s a change - but looking retroactively we probably should be doing it).
My bad, I was thinking this was to allow the user to block access to particular permissions but after a re-read I now understand it is just at the project level
Hi @SvenSchatter , yes with the Confluence permission restriction an admin can stop the app user from getting access asApp. However, even if the app has no space permissions, as long as the impersonated user has permissions, the app will be able to access wherever the impersonated user has access to. The app access rule is a mechanism to prevent apps accessing containers without checking asApp and asUser permissions.
I agree that having two features that address an app’s access to content can be confusing for customers so thanks for bringing this up here. The Confluence team is aware of this issue and is looking into this.
Hi Julia, thanks for this RFC.
I think that this changes will have a big impact on the existing Marketplace apps that are using webhooks, macros, project and space / page information… so a lot of them! It will be helpful for us to be able to know when the result is omitted from the api response because of this new access limitation. Otherwise we will spend a LOT of time debugging and figuring out why our apps are not working anymore for our clients.
Having in mind the big impact on our apps - I really hope that we will have enough time to prepare for this.
Hi @JuliaDaehne thanks for the write up.
I’ll try and only provide new/different feedback - I agree with a lot of the other comments, particularly around communicating to end-users (vs admins) why an app isn’t working.
Are these new APIs sufficient for your apps to be compatible with this app blocking feature? Are they necessary, or could your app operate without them? If either prove to be unnecessary we may deprioritise them.
I think so… Thanks for providing APIs/webhooks to let us know that we have had access revoked.
Will you need to make changes to your apps to adapt to the new API behaviours?
Do you foresee your app’s feature set or user experience be negatively impacted by the above changes?
Are there any specific REST APIs you are particularly concerned about the impact to?
How sensitive is your app to API latency?
Yes I think we’ll need to make changes to ScriptRunner. Customers can chose which projects their scripts are related to. We store a mixture of space/project keys and space/project IDs depending on the feature. We’ll need to update our business logic to be more graceful in handling the situation where a script says it should run for space/project X and we no longer have access to that space/project. Also displaying a list of spaces/projects in the user interface that a script is configured for will need to be updated to exclude that inaccessible space/project somehow or indicate that its now an inaccessible space/project.
Edit: I suppose this should “just work” the same way as when projects/spaces are deleted.
I’m concerned about the impact of additional permission checks and the extra latency those checks add to REST API calls. ScriptRunner makes a lot of requests to Jira in particular and an increase in request durations has the potential to break some functionality, particularly around issue searches. I’m happy to provide more details directly if you want them.
Similar to our questions about REST, will you need to make changes to your apps to adapt to the new API behaviours? Are there any specific GraphQL APIs you are particularly concerned about the impact to?
Nope
Do you have any concerns about a blocked app’s impact to content properties?
Some app functionality may just disappear from the Jira/Confluence UI as an knock-on of this but that’s by design. I would echo other’s concerns about making sure that end-users can somehow be redirected to the Jira/Confluence admin who’ve applied these restrictions rather than vendors’ app support teams.
Edit: I think we do actually store some data in project properties so we can reference them in conditions within the descriptor. We’ll need to be mindful of that if/when we make any schema changes to that data because we won’t be able to update the data stored against inaccessible projects. Our business logic/descriptor conditions will need to be backwards compatible.
Will you need to make changes to your apps to adapt to the new app event behaviours? Do you foresee your app’s feature set or user experience be negatively impacted by the above changes?
I think we will need to make some significant changes to cater for Jira projects having access revoked and subsequently reinstated. ScriptRunner does some on-the-fly caching/indexing of issue data based on webhooks that we obviously won’t be able to do while we don’t receive those events, so we might need to bulk process a project if access is reinstated after being revoked or after the app has been installed for the first time (so the app had no idea the project existed in the first place).
Until we build this, then some functionality will not work as end-users expect it to, and they may be ignorant of that, unless we build something to store the projects that we have recently been granted access to and haven’t processed yet and figure out some way to make that information visible to end-users.
Do you have any concerns about an app block’s impact on macros?
As long as the messaging directs end-users to their admins, I don’t think so…
Do you have any concerns about an app block’s impact on other UI modules?
I think only if we get additional support tickets and have to redirect users back to their admins.
FAQs
I’m not entirely convinced we should treat “project/space access revoked” the same way that we do for an app uninstall, especially if there isn’t a mechanism for notifying admins that this is what will happen when they block access of an app. A message from Atlassian saying “the app may delete your data” isn’t enough in my opinion, I’d want to be able to communicate to an admin specifically which configurations/data would be removed as part of applying an app block.
Like with many changes announced by Atlassian, I’m a bit concerned about the impact of modifying our apps accordingly within the timeframes Atlassian are working to. We have our own roadmaps and feature lists and technical improvements we want or need to make, and often we are in a position of deprioritising those to “keep up” with Atlassian’s changes. The knock on impact of this is that our combined customer base is not getting the value they expect from us. Maybe we “just” need to hire more people… if you’re interested, let me know.
Hi @jbevan thanks for taking the time to provide this detailed feedback. I had. afew follow up questions on the points you raised if you don’t mind:
ScriptRunner makes a lot of requests to Jira in particular and an increase in request durations has the potential to break some functionality, particularly around issue searches.
Is there an acceptable max increase of request duration you could accept? Such feedback will help us greatly with our acceptance criteria definition/ adjustment as we move into test phase.
I’d want to be able to communicate to an admin specifically which configurations/data would be removed as part of applying an app block
Currently we are evaluating whether we can capture the customer’s data retention expectation at the time of setting up an app access rule. Their preference could be sent back to the app. This would ensure the customer is informed or even directly managing for how long stored app data is retained. Do you have any thoughts on this?
bulk process a project if access is reinstated after being revoked
Are you saying you would expect that over and above the app block webhook you would also expect to be notified when the block is lifted?
We’ll need to update our business logic to be more graceful in handling the situation where a script says it should run for space/project X and we no longer have access to that space/project
Can you give me an idea on how complex such business logic review is for an app such as Scriptrunner? Does the linked Scriptrunner Behaviours app present an additional challenge here?
Hi @dusan.spaic I hear you! This is not an easy lift and we will ensure we share updates and confirmed dates with our partners when they become available
Thanks for your quick response 
Is there an acceptable max increase of request duration you could accept? Such feedback will help us greatly with our acceptance criteria definition/ adjustment as we move into test phase.
Let me try and dig out some numbers and share them with you directly.
Currently we are evaluating whether we can capture the customer’s data retention expectation at the time of setting up an app access rule. Their preference could be sent back to the app. This would ensure the customer is informed or even directly managing for how long stored app data is retained. Do you have any thoughts on this?
That would be very helpful, although we’d then need to build out functionality to delete only the relevant parts of our customers’ saved configurations.
Are you saying you would expect that over and above the app block webhook you would also expect to be notified when the block is lifted?
I think I misread your original post and concluded that an “access reinstated” webhook would be sent. If that is not sent, then we either need to poll for newly visible projects, or have some UI to allow customers to perform any relevant actions on projects that they know are newly visible as well as educating them somehow that this is something they’d need to do.
Can Atlassian share whether they know of use cases to reinstate project/space access (other than for testing/feature evaluation purposes)? My uninformed assumption is that once revoked, access is unlikely to be reinstated.
Can you give me an idea on how complex such business logic review is for an app such as Scriptrunner? Does the linked Scriptrunner Behaviours app present an additional challenge here?
I’ve just done some testing and apart from some UI changes, I think mostly this has already been taken care of by considering that a project/space can be deleted.
I have some follow up questions/comments: