We’re excited to share that additional levels of Resource permissions are now available. These features make it easier to build apps with sensitive data in a secured way.
Resource “Use” permission
We created a new “Use” access level which grants permission to run queries on a given Resource. This means Admins can now control access to sensitive Resources explicitly rather than implicitly via App access.
Resource Environment permissions
Admins on Enterprise plans can now also grant Resource permissions at the environment level.
I'm using embed (retool 3.21.0) and this update caused all of our users to temporarily lose access their data. Our apps query multiple postgres database resources. This new feature defaulted to no resources being selected for every one of our permissions groups (which makes sense) but it unfortunately broke our workflow. I did not receive any warning of this new level of permissions and only figured it out upon seeing this post. Any heads up on new permissions levels to those affected would be useful.
hi @Iva_Milo - I am struggling to understand how to set up an end user of one of our apps without granting them too many permissions. I have started off setting them up only with "Use" permission to the app. When they tried accessing the app, we could then see that data couldn't be fetched for the app because the user didn't have the appropriate Resource permissions. Now we're unsure about what the "Resource" "Use" level of permission entails, as we don't want the user to freely write their own queries against e.g. our database - we essentially are looking for a level of permissions where the user can access the app and can view the data that the app fetches using the preconfigured queries + transformers.
Hi @Iva_Milo - thanks for your response. It's hard for us to verify whether this features is exactly what we like it to be so I can't confirm or deny, but thank you for confirming that it is what we think it is.
Hi @Iva_Milo! I have a similar question to @jangerrit and I think many other people on the forum.
Specifically, the language around Workflows and the Query Library are confusing and don't address the main concern (i.e. "can this user get data they need without the ability to edit or view the source?")
Hovering over the "Use" permission in Workflows, for example, says "Open the workflow in run-only mode with no editor access."
Does this mean the user can go to the direct workflow URL and run it but not edit it?
Does this need to be enabled if the user already has "Use" access to an app that queries the workflow?
Similarly with the Query library, the options are "No Access" | "Edit Queries" | "Use Queries in Apps"
If a user already has "Use" permissions to an app that uses a query from the query library, do they still need "Use Queries in Apps" access?
Docs on building a customer portal say to ensure "No Access" on Query Library. I assume this means "No Access" directly to the query library or the ability to use them in apps the user builds, correct? -- the language makes it very ambiguous.
Is there a particular thread or (maybe, hopefully ) a hidden doc that better breaks down what each permission setting does? Unfortunately, the language in the official permissions documentation is equally as ambiguous and doesn't answer the most important questions around access.
Does this need to be enabled if the user already has "Use" access to an app that queries the workflow?
No, 'Use' access to the app is sufficient for calling the workflow.
If a user already has "Use" permissions to an app that uses a query from the query library, do they still need "Use Queries in Apps" access?
Yes, "Use queries in apps" is required for queries in apps which pull from the Query Library to be run successfully.
Docs on building a customer portal say to ensure "No Access" on Query Library. I assume this means "No Access" directly to the query library or the ability to use them in apps the user builds, correct? -- the language makes it very ambiguous.
Correct, "No access" denies access to all aspects of the Query Library, which includes using the queries in apps.
Let me know if you have any follow up questions. Thanks!
Hey @joeBumbaca! Thanks for your detailed responses here and for clearing up the permissions.
All of what you said makes sense. Given the current documentation (which is sometimes contradictory) and the existing permissions interface, though, I would likely have to reference your post anytime I make changes.
Do you have any plans to update these surfaces with better context?
The trickiest thing in my mind is the Query Library permission. I'm not sure why this is a separate permission tucked away in the advanced settings, especially given that we use the Query Library throughout all of our apps.
I would expect that, by default, whatever permissions set on the App would be inherited by the necessary Resource and also by the calling query in the Query Library. I can't really think of a case where I enable users to Use an app but provide No Access to the Query Library queries it depends on?
TLDR;
I would expect that choosing "Use" on an app would make everything it needs to run... able to run, unless explicitly made inaccessible (which is where progressively disclosed granular resource and workflow permissions makes sense).
Right now it's a manual process of trial and error to enable just the right configuration of resources, workflows, and query library permissions for an app to work as intended without being too permissive. I can see how better folder management could simplify this, but ultimately I would love to select Use on an app and know that everything within that scope is accessible.
As I typed the above, I realized why you all did it the way you did (default to restrictive and granular over simplistic and potentially not secure). I just get this burning feeling that there may be a simpler way
) a hidden doc that better breaks down what each permission setting does? Unfortunately, the language in the 