The app block happens when an org admin blocks app access to one or more selected projects within a data security policy. If he changes his mind or a project’s data is not deemed to be sensitive anymore the org admin could decide to take the project out of the policy coverage or even de-activate the entire policy. Previously restricted apps will become unblocked
This comes back to the above mentioned data retention period. Atlassian can’t tell partners when to clean up blocked app’s data as the agreement is between the partner and the customer. What I can tell you is that what we heard so far from customers is that they wouldn’t expect for data to be retained forever, but neither for it to disappear the minute an app gets blocked. Aligning with the 30 days after uninstallation may be an option to consider. On our end we are evaluating an org admin notification during policy setting process that informs him about data loss when activating the policy
1 Like
Apologies, I forgot to answer this one: atm we would just drop the event and not send to webhook.
Hi @JuliaDaehne ,
I have a question about the app access rules and guest users. If I understand correctly, app access rules can prevent an app from accessing some objects. The same can happen if the app is used by a guest user.
How can we differentiate between blocked by access rules vs blocked by guest user access? Depending on the implementation, this could lead to unexpected results. For example see Introducing single-space guests beta in Confluence Cloud! - #2 by marc
Hi @JuliaDaehne, thank you for the RFC.
Do you have any concerns about an app block’s impact on other UI modules?
Could we get some assurances this change would gracefully handle the publish conditions module?
Currently in one of our apps we trigger a modal dialog in the page editor with the publish conditions module. From the modal, a user can set a content property which satisfies the condition for publish. From the RFC it’s clear UI modules won’t be displayed in blocked spaces, am I right in assuming the publish conditions module’s conditions won’t be evaluated in these contexts as well?
This concerns me as we cache the number of issuelinks that issues have and the type of those issue links, based on webhooks, in order to provide advanced searching capabilities.
If access to project X is revoked, it would be a very poor user experience for app functionality within project Y to also be affected.
Issue links between two issues in project X I can understand why they’ll not be sent. But issue links that cross project boundaries I’d expect app to still receive, even if some of the data in them is redacted or missing.
@jbevan just to be clear: webhooks are not sent for blocked project x but unrestricted project y would still receive webhooks. The app access rule is only enforced for containers (ie projects or spaces) blocked by the admin
Hi @JeromeParramore yes that’s correct. The publish condition will not be applied in a blocked space
Hi , I have list some questions and concern related to confluence macro, custom content mostly because we do store our user apps data using custom content.
- As we already know we already have apps user permission access in each space, does the app access rules will override app permission. Which permission will become the highest permission is the app permission in the space or the app access rule. What is the different between app permission and app access rules. Does we also display a list of block apps in the permission space setting?
- We do use AP.request to create custom content which is using user session how this will impact do we will get clear error in the response?
- Does user still able to use macro in the space if App access rule is enable to the space? Example like adding or edit macro in the space? Is there any warning/error message to user will be handle by confluence?
- If we exclude space/content Information from the api call when app access rule enable this will have impact to user, user can’t see their information that have been there before the rules is enable by admin and they will come to us asking why their data is missing and we need to ask admin is the apps is block for that space. FYI we have our own homepage in the apps menu where we display the list of users data (Forms Configurations), the data store using confluence custom content and we get the list of user data from the custom content.
- Can we know which apps is block when we use user session to fetch get space list api?
- Is there any plan to create api to provide with the list of block space or add the list of block space in any specific api call?
- What is the target time line for this App access rule future? Can we test the changes before it go live?
Thanks You.
Julia I am wondering if with ~1 week remaining in the RFC process, we can get a summary of any changes to the original RFC description that Atlassian has taken on board based on the discussion that has happened?
This feels like one of the more productive RFC discussions but also one of the most “edge casey” ones we have worked on so far. Ensuring there is a clear summary of whats happening may help ensure an optimal outcome for all.
3 Likes
Hi @boris yes I will post a summary before closing the RFC. I am also hoping we can continue the discussion. Only because the RFC is closed doesn’t mean partner feedback is not needed or considered anymore
3 Likes
Hi @ShahrimanMohammad thanks for adding your questions. There seem to be 2 areas of concern: end user and partner experience.
End user experience
To answer your first point, the app access rule will block an app’s access to a space in its entirety. The Confluence permission restriction will only affect the ‘as user’ but not the ‘as app’ access.
We are aiming to make the user experience for app blocking as clear as possible. As we learn more about admin and end user requirements through our research, we are adding signals and notifications in different touch points over time. To start with, we will show warning messages for blocked macros explaining why the app is not working. We are also evaluating signals in the manage apps section for admins and other notification channels such as in product notifications.
Partner experience
As mentioned further up in the RFC we are working on webhooks and APIs to inform partners about an app access block. As with the end user experience this will most likely be an incremental delivery, ie we are evaluating to start with an API the partner can actively call to receive a list of blocked spaces for his apps. If required, we could further assess app block specific responses when a product API for a blocked space is called.
A closed EAP for 5-10 selected customers is planned for in July. Based on customer and involved partner feedback we will be able to confirm following milestone dates.
1 Like
Thank You @JuliaDaehne for the fast response. I also would like to highlight there is a plan to stop some of api v1 on next January 2024, it will be nice if we can align with this changes and I think it can save a lot of marketplace partner effort when we update our existing api v1 to v2 together with this changes.
Hi @marc, could you elaborate what you mean by “this could lead to unexpected results”? We have decided to allow guests to use apps so the “blocked by guest user access” scenario should no longer be an issue. RFC-9: Blocking Guest Access to Apps - #49 by MorganWang
Hi @LauraMehrkens ,
Guest users have access to a single space, and an app has access to multiple spaces.
When a guest user uses our app, some information may be blocked due to the user being a guest user, and the same or other information may be blocked due to app access rules.
If we (or our users) don’t know which blocks are in effect for which user, it can be quite confusing to debug data access issues.
Dear Partner Community,
Thank you so much for your engagement with this RFC. It has given us a lot of great input into our current thinking on the app access rule.
These are the main concerns and questions we heard from you:
- Webhook and APIs communicating app blocks to apps: this appears to be a ‘must have’ for partners before the app access rule can go live
- End user experience of the app access rule: clear messages should be given to end users about an app block - be it through UI msg or other notification methods - to avoid partner support requests
- Guidelines on data retention for blocked apps: guidelines should be given to avoid frustration on customer side for deleted app content after an app access rule has been activated
What will we change?
- Apps should make use of a new API we will provide to determine whether the space they are operating in is subject to policy constraints. Apps are encouraged to briefly cache the results of calling this new API to alleviate scaling and performance concerns. We will continue to evaluate the need for product API alterations
- We will continue to improve on the end user experience. This is an iterative process and will start with app access rule specific messaging for blocked Confluence macros
- We are leaning towards a customer defined retention period that we would communicate back to partners. This is pending further evaluation on whether such passing of information from customer to partner will make Atlassian become a ‘joint controller’
What is coming next?
We are currently running penetration testing and dog fooding on our end. This will be followed by a small and controlled EAP with 5-10 customers for Forge and 3LO apps in August. Any partners affected by this EAP will be contacted in advance.
Finally, I would like to assure you that we will not rush into a GA state for the app access rule without giving partners the tools to handle this new feature at their end.
We will keep you informed about any future milestones such as additional features for Atlassian Access customers, adding Jira and extension of our EAP to more customers before we release these.
If you are happy to be contacted for furhter partner input on the app access rule please fill in this form
Many thanks again
Julia
3 Likes
Hi @JuliaDaehne ,
Thank you for summarizing and describing the steps Atlassian takes.
A short but important question: Your post talks about Forge and OAuth apps. Does your announcement also apply to Connect apps?
Yes, the RFC applies to Connect apps (see 2nd paragraph of the solution). The next step with a handful of customers is not focused on Connect yet. If you have further feedback please keep in touch with Julia via the form she posted.
1 Like