I’m very new to Glide, but loving it so far. I do have a question for the community.
I have a sheet that I would like row owners to be on, but not for every row. Some rows I would like to be open to all users, and I’d rather not list EVERY user as an owner for those rows.
Option B: It is possible that I could split the sheet into two sheet, one with row owners on, and one off. This creates some reconfiguration work for me, and I like the way it is currently because it allows me to list items together, and add to the data directly from a details screen to the same source/sheet.
Option C: add ALLLLL the users to the row owners. I think in Google sheets that means having Owner 1 ->Owner n columns, and while I can do that with a transpose of the user’s sheet… it seems like that’s a ridiculous amount of excess data to tote around so I’d probably go for option B if option A isn’t available.
Thanks for your thoughts!
There’s no easy way to do this with row owners, you’re right here.
Which emails should be row owners though? I assume the creator and the admin(s)?
Option B is what’s recommended by Glide as well.
Bummer. I was hoping for some trick like entering “*” as the row owner. Dev team… could a good addition!
In my case it’s a social app and I have an activity sheet that holds both 1:1 messages, group messages, and posts to small groups as well as to an open wall. The 1:1 messages are easy. The groups get a little harder because I couldn’t figure out how to get FILTER to work inside ARRAYFORMULA, but I have limited groups and they’re created by me, not in app by users at this point… so it’s easy enough for me to drag my TRANSPOSE(INDEX(FILTER equation.
The main issue is for the posts in the wall visible to the entire app. I suppose I need to move those to be on a separate sheet from my Activity sheet, because they are visible to all.
Here’s a side question about privacy… if I have “Mark as protected” on for all email columns that are in sheets that have multiple row owners, and emails are not listed on any sheet that doesn’t have row owners on, is there any reason to still use the Virtual Addresses for login? Doing Virtual Addresses looses some additions to my email list. I can ask for email to be entered again… but that first email is verified on login, and for the users who don’t get past the first step of logging in, I could attempt to pull back if I have their address.
I’m not sure I understand the question, but the “Mark as protected” option causes glide to more or less completely ignore that column. I think it’s meant for cases where you have columns of data that might be in a google sheet, but you do not want that specific column to have any association with the app…thus completely securing that piece of data.
As for marking a row owner column as protected. Seems like that shouldn’t be possible. I did a quick test and marking a row owner column as protected, makes the entire row inaccessible in the app.
Row ownership columns can be marked protected, and the ownership functionality does work. I just checked that what I have set up does work. Here’s what I’m doing…
In my messages sheet, I have row owners set on an array column. The owners emails are added in Gsheets with a vlookup to the locked accounts sheet. I don’t need to (and can’t) read or write to this column in glide other than reading for row ownership sake.
I need this to be a protected column because otherwise, a row owner would be able to view the email address of the other row owner(s)… the person or people in the chat with them. Virtual addresses is a way to satisfy this concern, as we don’t care if people see the virtual address of people in the chat with them. But I’d like to use only real email addresses if it’s possible to do so without leaking them anywhere.
My question is… Is it possible for me to keep real email addresses completely secure (without using virtual emails) by following the two points below? And are there any other things I should consider before eliminating virtual email use in my app?
- Never include emails on a sheet that doesn’t have row ownership on.
- For sheets with rows with multiple owners, always have “Mark as protected” on the email/row ownership column(s).
Thanks for discussing!
mmm, yes. This is not what I would have expected, but I just tested with one of my apps and it does work as you described. My guess is that because row owners are applied before any data is sent to the client device, Glide can still read the contents of these columns in the back end and and apply ownership rules - even though they are protected.
I’m thinking yes, but I’d wait and see what Jeff has to say about it.
If you’ve already been using virtual addresses for a while, and you switch to “real” addresses, I’m not entirely sure how well Glide handles the transition for existing users. This would be something worth testing, I think. What you could do is make a copy of your app and switch it to real emails, then watch what happens when an existing user signs in. Ideally, you’d hope that Glide would attach them to the same row (that contained the virtual address) and update the email address. But I don’t know if that happens. It might be that you need to clear out all the rows from your User Profiles sheet that contain virtual emails, and allow them to be created again.
Hmm, interesting. I could only get a protected column to work as a row owner as long as it was set up as a google sheet array. If it was a single basic column, then it wouldn’t work for me. That feels like a loophole or bug to me, but I’m not sure if it’s something that would be “fixed” anytime soon. I would just be prepared if that were to ever change. From what glide has mentioned about google sheet arrays, is that they are a bit of hack in the first place and work a little differently from other arrays within glide.
I did some testing and studied the data that was downloaded. Ignoring Row Owners altogether, and just testing the option to mark a column as Protected on both a single basic column and an array generated from the google sheet, I found that the array was not protected at all even though it appeared in the data editor as if it was. The single column was protected, but the array generated from the google sheet still had all of it’s data exposed. For that reason alone, I think that’s why it happens to work for you because the array column isn’t really protected. If glide fixed that to actually protect the data in that column, then I believe your row owners would stop working.
Now, data under row ownership is a bit of a different animal and harder to track down what is accessible to the end user. Long story short though, I would not trust a google array that’s marked as protected and set as the row owner to reliably be completely inaccessible to the end user security-wise.
Hey Darren, as for the switch… I’ve switched back and forth a few times already as I’m learning through action.
Switching either way between real and virtual is mostly fine… it just doesn’t change how previous accounts created are… old accounts will stay virtual or real, even if you switch.
In my case after I switched first time from real to virtual, I added a “confirm email address” on the sign up form, to get their real address. For email notifications sake, I have another column computed to pull the real address and not virtual, if both are there.
What I could do if deciding to never go back to virtual (for this app), is overwrite their login virtual emails with the real ones they typed in to confirm account. Here’s what that would do…
If they typed in the same email under confirm as they did at login: they’d login with no trouble, nothing would change. They’d just see at the top part of the menu that their real email is now listed instead of the random one they were probably confused to see before anyway.
If they typed in a different email under confirm: they’d be able to login under their “confirmed” email, but not with the original email they logged in with.
The biggest issue with switching back and fourth seems that if you have any user who logged in with real addresses, and then you want to switch to virtual AND make sure those pre-virtual people are switched to virtual… that’s tough. If they try to login as usual with real address it accepts the login and doesn’t create a virtual one. If that’s an issue to have some old users with real addresses, they could create a new account with a new email. Or, if you associate a virtual email to their email address and replace in your login sheet, that would handle it. Could do that by copying all real addresses to a new column, and delete the login email… keeping the data but locking them out of account. Then when they login again, it creates a new account without them needing to use a different email. Then you have to instruct them to enter enough info for you to know which account data to pair to their new login. Like, ask for confirm email. Bunch of different ways you could do all this but it takes a little work. Could do it with a new app too, one that simply creates virtual addresses and then you pop that in to replace their real ones.
Jeff, wow sure enough! I just marked as protected my single column row owners on accounts sheet, and I see row owners loose ownership. That’s also a bit scary that the mark as protected fails to protect arrays… and makes me glad I’m asking this here lol.
Summarizing, it seems my method has a double risk:
- The emails aren’t actually protected because of Glide’s bug failing to “mark as protected” on google arrays.
- Row ownership would most likely break if Glide fixes the above bug.
Row owner columns alone though, aren’t as easily visible as regular columns… but still sort of are? Perhaps that question requires a longer and more complicated answer than I would understand… so maybe ignore that question unless it’s easy to comment on.
Alright well it sounds like I need to turn virtual emails back on, and take off “mark as protected” on my google array ownership columns.
I’m out of practice for tracking down the data, and some things have changed since I did it last time. Seems that a table that is under row ownership is handled differently from tables that are not. In my tests, it was easy to see data in tables that did not use row owners. However, I couldn’t find where or how data, under row ownership, is stored on the device. I’m sure it’s there somewhere, but I would have to spend some more time tracking it down. I just always assume that any and all data that is sent to a user’s device can be viewed by the user if they have enough knowledge of where to find it.
To answer the above question specifically, I would say this it is not entirely true. Yes, tables under row ownership are harder to see…for me…but that doesn’t mean that the next person knows exactly where to look. It’s not a matter whether a row owner “column” is visible or not. I believe that it will be visible if you can find the data. It’s more a matter of the entire row being visible or not due to row ownership taking place. Unowned rows are not sent to the end user in the first place.
I guess in most cases, if a user is a row owner, then it’s no problem if they can access the data, since it’s their data, and only the data that is owned by them is sent to the device in the first place.
I do understand your concerns in this case. I just don’t have a good answer. This is getting pretty deep into the inner workings of glide. At best, I can guess and make assumptions on how everything works based on past experiences. But, I just always assume that any and all data that is sent to a user’s device, and is used in one way or another in the app, is accessible to that user. The only way to ensure that a user can’t access the data, is to not send it to them in the first place. I always err on the side of caution, especially when it comes to security.
Got it. And yes I did mean columns there, as I understand only row owners download rows they own, but I was just wondering if it was possible for me to allow row owners to not see emails of the people they share row ownership with (besides using the virtual address guise.)
I don’t need to get deeper than what’s needed to understand the security implications, as I’d like to be respectful and safe with people’s info. And I think we’ve gotten to that point of understanding.