Hi there,
I find contradicting information in the Glide manuals. I want to share my user table across all users (so row owners is not possible) but some data is sensitive so I wanted to make these columns user-specific.
I find this here (User-specific Data | Glide Docs):
And then there’s this (User-specific columns | Glide Docs)
Thank you and have a nice evening!
User Specific columns are secure in the sense that each user has their own version of the values, and it’s literally impossible for any user to see the values of any other user. And the only way you as an App Builder could see the user specific data of your users would be “Viewing as” that user in the Data Editor.
They are not really meant for the use case you have in mind.
A better approach for your scenario is to have a separate “Public Profiles” table that is a mirror of your main User Profiles table (without row owners), but excludes any private information that shouldn’t be shared. And then apply Row Owners to your User Profiles table.
Bob Petitto has a good video tutorial on this. I’ll dig it out and add a link shortly.
Update: here you go…
That is certainly an interesting take on it! I don’t like adding extra rows (application load and the extra rows towards the limit) but I think it’s still one of the cleanest ways of doing this.
Still, if user specific columns only deliver their values to the specific user, it might be a secure way to protect a few columns and it might be the best way to achieve ‘column owners’ functionality even if “They are not really meant for the use case you have in mind.”?
One extra question. In the video, Robert petito uses the set column action on every update of the User Table to add these changes to the Public Profiles Table.
Why not just use a relation and lookup in the Public Profiles Table?
Wouldn’t it be safe (do relationships expose the whole related row(s))? Or is it to save calculations as the browser would have to calculate loads of lookup columns?
I guess it depends on how you are using the values in the App. If the values only ever need to be seen/used by the user, and never anybody else, then I guess it could make sense in some circumstances.
An example might be where you want to give your Users a personalised greeting on their birthday, but you don’t want this data leaking. The thing is, though, if you take the User Specific approach then you would never be able to answer a question like “How many of my users have birthdays in October?” - because you simply wouldn’t be able to access the data.
You can’t create a relation to something that doesn’t exist. Well, you can try - but it won’t work.
Remember - with row owners applied to the User Profiles table (ignoring roles), the Users table on each users device will contain precisely ONE row. Which is that of the signed in User.
Amazing answer, again!
To answer your question: I am building an AI engine (with lots of AI inputs) in the user table and that info never needs to be seen by other users, so that could be protected by user specific data!
However, other data in the user table such as email and phone number is still private so the public table might be the best option after all!
Very clear about the relation, stupid of me not to think about that haha 
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
