User Permissions Portal Best Practice

Hey all :wave:

I'm testing out using Portals for managing external-users and was wondering if there are some best-practices or architecture-related guides for managing CRUD permissions and data display for different groups. My use-case is for manufacturing, where manufacturers can login, view data and have limited update abilities.

I'm using Postgres/Supabase as my back-end and have work orders assigned to different manufacturers. I've managed to get this working through using the current_user.groups method of matching up the group with a known manufacturer in the postgres table. So far so good.

However rather than building a separate app to control the information in the Portal, I'm wanting our team to be able to make changes in same Portal - kind of like a God-Mode, where they can do CRUD operations that the manufacturer/external-users wouldn't be able to make.

This seems to make permissions a bit more complicated as there are two levels of permissions:

  1. Is the user a internal or external user
  2. if they're external, which manufacturer do they belong to

Part of this is that a internal user should be able to see all the work-orders across manufacturers, while manufacturers should only be able to see the work they're assigned.

I've read these posts/resources but I'm not sure if they seems more to do with Retool permissions rather than how to manage the use of permissions in app:

https://docs.retool.com/self-hosted/concepts/hub-and-spoke#role-based-access-controls-in-retool

Q1. Am I over complicating the app by introducing God-Mode? My logic is I can reduce my work (and potentially maintenance) by building the portal to work for both group, while also making the tables and data consistent across each group. This is important to our internal team to ensure the changes they're making are visible/what they want the manufacturers (currently our internal team will make a change and then check that its how they wanted it to be updated on the manufacturers app).

Q2. If its not over complicating it, is there any suggestions, guides or examples for how to manage these permissions? So far I am using two variables that check if the current user is a internal or external user, and if they're external, get the group_id from the database that matches their current_user.group name. This is fine but I'm struggling to wrap my head around how to show/hide/disable components using these flags. For example I have a query that gets all the assigned work for a manufacturer -> if the user is an internal user the query should get all assigned works across all manufacturers. Should I have two queries / one for internal and one for external and switch them? How could I write the query so that I remove the 'WHERE' statement if they user is an internal user? This is potentially further complicated by the fact that I'm leaning towards using VIEW tables for manufacturers while internal users would want to edit the actual table records...

Any suggestions or advice would be muchly appreciated :grin:

1 Like

Hey @lukxf! I spoke with a few different team members to make sure I could get a well-rounded response for you. I might not have any specific answers to your questions, it seems like we generally recommend duplicating an app and customizing each of those apps, rather than trying to build one app to handle all the differing functionality.

As a quick note, I also want to callout that queries have their own granular access controls, in case that's helpful to you!

Let me know if you still have any questions I can help answer :slight_smile:

1 Like

Thanks Victoria!

Duplication apps make sense, but how could I roll out updates or keep the apps in sync? If I have a manufacturer portal where the I want to update the app so that it has a new download feature, for duplicated apps I would have to go through and replicate the feature across each app?

And with access controls, is it best practice to always set the access permissions on these? I think it is risky having to set the permissions on a per-query basis across apps (and unnecessary if our database can handle access permissions?)

Thanks for the reply!

Keeping apps in sync is definitely a good argument in support of a single app. At the end of the day, there is no better configuration than what works for you!

With access controls, Iā€™d definitely recommend setting them in your app settings. https://docs.retool.com/org-users/concepts/permission-groups