Hello everybody! I’m new here and just trying some things around to test if Glide can fit my work needs and i’m pretty stuck here. I’m testing an app idea where i need columns to have different permissions depending on user roles (Column based visibility/column owner).
Basically i have 2 users: Designers and Sellers and a list of products, where each product has different data columns with their info.
The feature i need in my app is to have different permissions on each column, so for example, having a product that has the columns: Name, image, designer, price & style; i would need a designer to be able to see the product name, image and style, and the seller to be able to see the name, price and designer name (but not the style/image).
I know i can filter this fields on the front end, but i would like to filter them on the back end (for performance issues and privacy). One way i imagined to set this visibility permissions is to have a table where each row is a column in the products table, with the visibility permissions for each and then transpose them on the products table, but i don’t find a way to do it.
Another way could be to have a new table for each column, but that could lead to an excessive amounts of rows in the short/mid term.
Is there a way to achieve this in a performant and clean way? I think also that is something similar to ‘User specific columns’, but in this case it should be ‘role specific columns’. Here is a diagram for reference:
Thank you all in advance! Meanwhile i’ll keep looking for a solution!
This feels a little over complicated. I guess if I were to do it, I would utilize User Profiles to store the user Role. Then simply set component visibility based on the role, set for the signed in user in the user profile table. If it’s a Designer, then show certain components. If it’s a Seller, then show different components. That would be the simplest way to do it.
I mean, I’m sure it’s possible to make component visibility completely data driven on a column by column basis, but maybe I need to understand why it needs to be done first. Adding complexity isn’t going to improve performance, and I don’t see anything here that would require tight security of the data.
4 Likes
Hello jeff!
You mean setting the visibility on the frontend in the ‘visibility’ tab for the components i want to hide right right? Isn’t that something similar to setting ‘display: none’ on css?
No, it’s not exactly the same. When you set display: none in CSS, there is still a rendered element (component) that’s only hidden from view. When you use visibility settings, then the element (component) is not rendered at all, unless it matches the condition. When you view the page source, you would still see the component in the source if you only controlled it’s visibility with CSS. You would not see it in the page source if you use visibility conditions.
However, that doesn’t mean that the underlying database is not accessible if a user knows how to find it. To truly protect the data, that would require row owners and a more complicated setup. (Probably splitting the data into two tables with row owners.) It’s doable, but I’m trying to completely understand your use case, since it seems much more involved for the data you are trying to show. True Row Ownership with roles is only available for Private plans, but all plans can use visibility and filtering based on a psuedo “role” in the user profile table. If your app is not private and there could be and endless amount of users that can view the data, then using row owners can get really complicated, since you would have to assign each and every user as a row owner.
Maybe I’ve made it more confusing. That’s why it’s important to understand your use case and why you feel that simply using visibility conditions is not sufficient.
3 Likes