Any data they add on other sheets is controlled too.
Do you control that data via their email address or their RowID
So far I have always used email, but what happens if a user wants to change their email for any reason. Could they change their email in the app, log out and log in with new address and connect to the correct account. If they do, they would lose all connection to their data via email ownership, but if RowID was used they would be OK. Are there disadvantages to RowID, is that in fact best practice?
I ventured down this rabbit hole a few months ago. I got to the point where I had a semi-working solution, but it was very fragile. So in the end I abandoned the idea. If a user asks for their email address to be changed, I just do a global search and replace in the Google Sheet. Simple. Done. Maybe they lose the state of some user-specific columns. Shrug, I can live with that.
On email vs RowID, I try to use RowID to identify a user wherever I can. I think it’s a better practice.
I use both, depending on the situation. If Row Owners are needed, I would definitely use email, or at least include it in the data. Otherwise I use Unique ID’s or Row ID’s to link sheets together.
If anything, include keys as well as emails in your data until you figure out which works best for your case. Easier to remove a column later, than try to add a key or email after the fact. I’ve been down that road.
Currently the only restriction with RowID is not being able to delete the column via set column.
Changing the logged-in-users’ email address is only possible if you create an input to edit. I recommend you don’t, because user-specific columns might get messed up.
@Darren_Murphy I will have a look at that rabbit hole shortly. Although it sounds as though I shouldn’t.
@Jeff_Hager@Robert_Petitto On that basis if I am sending data to a new sheet, forward RowID from user profile sheet, and then use lookup to bring over email, as I am typing this I am thinking you can’t use a lookup as a rowowner?
In which case, send over RowID and also email as fixed data points, and use email as the Row Owner.
Nice concise thread. It is something I always wonder about, thought it would be a good one to have in the database for people to search.
Good work everyone. Pretty much what I was doing, just nice to have the dream team confirm as such. Hopefully this thread will prove useful for others.
Bumping into this tricky issue now (I am very new to Glide)
It does look like the current design of row owner makes it impossible for users to change their email.
And on top of this - for some use cases - it also forces the app to pass though the email PII publicly. For instance if a user A wants to create a protected private conversation with user B using row owner, the user B email will be needed. While enabling row owner on users row would allow to better secure personal data.
Is there any chance that row owner will work on users row IDs one day ?
I think the only way that would work would be to utilize the Role setting in user profiles and point it to the Row ID column. Then whenever you create a new row in your tables, you would write the Row ID instead of the email and apply row owners to that column.
The scenario you described with private chat would probably require the user profile table to not have row owners applied, so that way you could then have a way to aquire the ID of the user you are trying to have a conversation with. With that said, you would still have a PII issue because data not protected by row owners is still accessible if you snoop the data that was downloaded to the device…which would include the entire user profile table.
Assuming there will not be scalability issues from using row ID as roles, it seems to be doing the trick.
I already had to create a public_profile table where the user rowID is available and all the PII remains in the User table. So the issue you are pointing at should be avoided. I couldn’t find a way to share some user data without this additional table which makes the user profile edition a bit tricky.