Question about granular permission

Hi Retool community,

I would like to create restricted user account who can only access to an app in end-user mode only staging environment, not production mode.

With granular permissions, can I set such permissions to users?

2 Likes

Hi @nakamura! I don’t think this is possible unfortunately, the current setup is something of an inverse of this: only users with edit permission on an app are able to open it in staging mode through the toggle.

A somewhat hacky approach could be inverting these credentials, so that your “staging” pointed to production and vise versa

There is also a url query parameter that you can add to an app url of _environment=staging to open the app in staging mode, and another of _embed=true that you could add to hide the navigation UI but still prompt login. If those two were combined (?_embed=true&_environment=staging) and the app was embedded on a page, you could share that link with users for testing while still prompting them to log in with their account!

Long term, I agree we should support adding staging vs production level permissions as part of granular permissions as well

2 Likes

Any updates here? Just encountered this need as well. There is a certain part of the dev team that needs access just to staging, while the ops team needs access to staging and prod.

I also have a request for this, where the editor of retool should only be able to access staging, so that they can make changes to our system, without access to production data.

Cheers

In addition to using the URL parameters mentioned above, we added an extra layer of security by using the "disable when" property on queries and "hide when true" on components by using a condition like:

{{retoolContext.environment == 'production' && current_user.groups.filter(g => g.name == 'SomeRestrictedGroup').length > 0}}

If someone is in SomeRestrictedGroup then they won't be able to run production queries or see the components even if they manage to switch to that environment (i.e. by changing the URL etc). Hope that helps.

We would love this for our QA team. We've built a bunch of administrative and debugging tooling that's useful for testers, but we don't want to give them access to those tools for production data.

1 Like

@maus Fix is the best way to go right now, but I just want to bump this, since there are now more options for environments, this would be really useful.