Restrict Access By Environment

@mokshjawa thanks for the update. Do you have any ideas on roadmap timelines for this?

Hello @mokshjawa!

Any news on this feature? I really need to use it.

@victoria?

Hey @Doglas! Just seeing this.

No updates yet, unfortunately. The team in charge of this product area is currently focused on revamping our Source Control feature, but we'll hopefully revisit this feature request soon! :crossed_fingers:

Would be very interested in this feature as well :arrow_up:

Thanks, Ron! I don't have a timeline yet, but I added your +1 internally

1 Like

+1

Does this mean that with a Business subscription, users assigned a use permission for an app can switch between environments??

We're trying to find a solution for an app that connects with several Oauth resources and rather than creating an app for each client, environments seems a solution, but if clients can change them that would mean seeing other client's data resources :frowning:

Thanks

Hi @MiguelOrtiz,

That is correct. We don't currently have a way to restrict users to a certain environment.

For the time being, I'd recommend separate apps, or data restrictions that limit what each authenticated user is able to query. For example, on the Retool side, you could add limitations based on the current_user (like this example and this example)

Hi @Tess,

How unfortunate...

Thank you for the examples.

Question, if we use embed, will end users also be able to switch environments? Are we able to embed an app with a link for a specific environment (using URL or other solution) or will it always default to production?

Thanks
Miguel

Hi @Tess,

Just double checking on the above:

if we use embed, will end users also be able to switch environments? Are we able to embed an app with a link for a specific environment (using URL or other solution) or will it always default to production?

Thank you!

Hi @MiguelOrtiz,

I just checked on this internally. It looks like you should be able to set the environment when generating the url (using the optional environment param), but end users won't be able to switch environments - unless you build a feature to fetch a new url with the environment they want

1 Like

Thank you @Tess , that's helpful to know

Hello,

I noticed that there is the possibility of defining a profile's access to specific environments for each resource (I don't know from which version). However, the behavior of these definitions was not as we expected.

A serious mistake occurs for our purposes with this feature: when a user who has this profile creates a query with the elt-mssql resource (see image) within an application in a staging environment, he can, after creation, execute it in the production environment, simply switch to this environment and click the "preview" or "run" button. This means that queries in development can be executed in production, which is exactly what we don't want to happen.

My hope is that you will tell me that I am using this configuration wrong, but if I use it correctly, I will be able to restrict the environments that each group on the system will have access to. Is this the case?

@Tess, the simple functionality of being able to block access to the production environment from the development screen would be very useful. However, the ideal is that we could restrict the production environment to everyone with the "Dev" profile, regardless of whether the user is on the development screen or the tool use screen.

@victoria

Hi. dear.
I can't show this option now.
I can't drop down env check box container.
Plz let me know about the best solution.
Thanks.

Hi. @Tess
How are you ?

I can't drop down this option.
I need to tick specified env option on check box
Plz tell me about solution.
Thanks.

Hi @Jomarie_Janer Thanks for reaching out! Hm, that is strange. I haven't been able to reproduce this issue yet. What version of Retool # are you on? Are you unable to drop down any options, or is it only impacting specific resources?

Thanks for the detailed update! Looking into this issue!

Hi @Doglas,

Are you still seeing this issue? I get a 404 as soon as I switch to an environment that I shouldn't have access to:

Any chance that user had prod access in a different permission group?