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?
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.
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.