We're developing an important business system. We need a way to fully test apps using a staging DB. There isn't a good way to do this in Business edition, and Enterprise is way out of budget for our small non-profit.
We considered buying a second Retool Business instance. We would test apps on staging instance, export app, then import to production instance.
However, importing an app always creates a new app. We cannot overwrite an existing app. This makes for a messy deployment process. (And Github integration is not an option in Business.)
We considered setting up staging resources on our production instance, and then tying test users to staging resources. However, there is no ability in Business edition to restrict a user to a particular environment.
Our current solution is to build the restrictions on our API. We assign test users to a Permission Group "test user", retrieve the user's groups from current_user.metadata, and grant that user access to only our staging DB.
I feel that Business users need to be thrown an Enterprise bone here . There needs to be something that lets us test safely using non-production resources without having to roll our own code to do so. Any of these options would work:
Ability to restrict a permission group to an environment, e.g. staging
Github integration. (Requires we buy a second instance.)
"Overwrite" option for app importing. (Requires we buy a second instance.)
Hope you had a good weekend, thank you for the feed back and well written post.
I can definitely log your feedback to our internal teams to see what features we can look to expand to help our Business plan users to better develop and grow their apps/orgs.
Very impressed with the work around for checking current user metadata to control access at the API level. Quick question, are you using Retool DB for the staging resource or the production resource?
I was just going over our docs on permissions here and although Permission Groups cannot be used to control access to Retool Database, you can use permission groups and levels to restrict "Use" permissions for specific Resources, such as a self hosted Postgres DB.
Also, there is a way to import/export an app to directly clone them. You could set up your prod and staging apps in subfolders, iterate in staging then export/import to prod.
The only issue would be the resource/queries as you would need to manually switch them since the staging resources would override the prod sources on import.
However, I just did some testing and might have a solution for you. There is a feature flag called "Decoupled Query" which we could turn on for your org.
This would allow you to dynamically chose which resource a query uses. This way you could have the same query in two different apps (one for prod and one for staging) and change the resource being access (prod DB vs staging DB) based on permissions either from groups or from current_user metadata.
Let me know if you would like that feature and I can switch it on for you and walk you through how to use it!
Of course, I'd prefer to manage this in Permission Groups, not within application logic.
Again, we're just looking for a way to allow a user to test a Retool app in a safe staging environment without accidentally connecting to a production resource.
As a business plan user, you should be able to use Permission Groups to control which users only have access to staging resources.
From your account dashboard you should be able to create a new permission group, add users to it and then select the resources available to users in the group and what level of access they have.
The loom video below shows me walking through the steps of creating a new group and applying permission level controls to resources and apps. Let me know if this works for you!
Because you are self hosted, we need the email of the original admin that signed up for your self hosted retool org or their license key to turn on the feature.
@Jack_T Yes, we have access to Permission Groups and can apply permissions.
However, we want all users to use the same resource with different environments of that resource. Otherwise, we would have to add application-level logic to switch resources, which is easy for a developer to overlook in a multi-app setup.
I understand from your documentation that resource environment permissions are available on Enterprise Plan.
I'd like to lobby for this feature to be available on Business Plan — or any other feature that would allow Business Plan users to isolate users to a particular environment without requiring app-level logic.
You know what would be helpful? A documentation page with Best Practices on QAing/release-testing an app. It would either point out to me an approach we haven't though of, or point out to your product manager(s) that there isn't a best-practice approach for any customers except Enterprise customers.
In the absence of another approach, we're currently planning on adding a custom User Attribute environment, including that attribute in the header of resource calls to our API using current_user.metadata.environment, and isolating users to the appropriate environment on our API. The downside is we have to build the logic into our API, and we need to manage the user attribute manually, on a per-user basis.
Hey @Chris_McGrath apologies for the late response I have been out of office.
We appreciate the feedback and I just put in a feature request for environment level control over resources via user permission groups for business plan users!
As well as a request for added documentation on best practices for QAing/release testing apps.
Will keep you updated on anything I hear from our eng team. I would say from my experience best practices are to make a test app with the resources pointed to test data/tables. Then once the app is working as intended to switch the resources over to prod data.
But there are many ways to split which data a user is accessing. I have applied the decoupled queries feature flag for your org, which will allow for permission group level control of queries and having the queries pull data from different environment sources.
This might have been turned off as it seems your account recently changes from business plan to the free plan. Let me know if you are able to use it and if that feature combined with the importing/exporting of apps as I shared above is able to help!
. There needs to be something that lets us test safely using non-production resources without having to roll our own code to do so. Any of these options would work:
