I understand using Row Owners correctly means we can avoid downloading a lot of rows to a users browser - which inherently means it is very secure - but if I have a collection that has its source set to a relation from that table - can I assume that is equally secure?
Ie - if I had a Projects table with row owners applied - so I can control which projects are visible to which users - and a relation from that table to another table without row owners applied - and lots of rows pertaining to every single project - is it just as secure?
Relation or not, if row owners are applied to a table, only the owned rows will be downloaded. If row owner are not applied to a table, then assume all rows will be downloaded. The relation happens on the user’s device after data has been downloaded and will check against the data that’s available.
In this scenario, since row owners are not applied to the related table, all data in that table will be downloaded, regardless if it’s visible in the front end of the app not. So, no, the data in that related table is not secure as all of the data in that table is downloaded to every user’s device.
I’d like to have super admin, admin and user roles. Super admin (me) should see ALL users in the user table, group admins and users can only see users within their department. I can do the group admin and user roles, but can’t get the super user role working. Should a super user be managing users from within the glide builder? Or do I need to ditch row owners in this scenario? (I will then have a projects table with row owners applied to a “group ID” foreign key so that only the relevant projects are downloaded)
I assume it’s best practice to use the Row ID for departments. Any issue with this you know of? I’ve tested it and it seems ok. Only slight drawback is the group is displayed as a row Id in the builder as you’d expect.
Finally - and this is for my own sanity more than anything - if you’re not using Roles (which I am and I have access to roles on my plan), in the users table, row owners can only be applied to the email column. Is that right? Seems that email column gets some special treatment behind the scenes? Applying row owners to a non email column, without roles enabled, just removes all rows from view regardless.
Just seem to find this all a bit of a head scratcher
Have a look at my second example in the below reply. I think it covers basically the same use case as you are describing.
Any text value is fine, as long as it is unique per department.
Row Owners can be applied to any email or non-computed text column in any table.
Row Owners applied to email columns will always work.
Row Owners applied to text columns will only work if you’re using Roles and at least one user has a Role that corresponds to the text value. For example, if you’re not using Roles and you create a text column, fill it with the word “Admin” and then apply Row Owners to it - then no user will see any rows in that table - unless you also have an email row owner column in the same table.
Thanks so much Darren and Jeff (and Bob’s videos!)
I’m sorted now. A bit of flaky holiday wifi didn’t help.
I find it a little counter intuitive, but I’ve basically got a role with the group ID they belong to for each user. Then another column also in the users table, with row owners applied, with the same group ID. I want people in the same group to be able to see each others email etc so that works for me.
Screenshots attached which works explain better.
Need to test it a little more but think I’m good. Thanks again.
Yep, what you have there is correct.
Personally, I’d probably use the Group names as Roles, but using the Group RowID is also fine. It does have the advantage that you can rename groups in the future without breaking anything. If you need the names for display purposes you can always use a relation + lookup to the groups table.
