Challenges applying Row Owner freely, without formulas - thoughts?

[Rasha]

I’m a data-privacy aficionado prone to obsessing over security measures. So naturally proper application of row ownership and roles is of great interest. I applaud the effort the Glide team has made to protect users, their users, and shield themselves from liability.

My focus in this post is on Row Owners. There are a few areas where I’d like to get a better handle on the why(s) and suss out possible substitutes. I can’t squeeze them into one post so this will act as a Part 1.

1. “Make Row Owner” shows up as an option in the drop-down for non-email column types - why? Making a phone number, name, or Row ID (in Profile sheet and others) doesn’t have the same effect. May be best to disable that option if it really isn’t one.
   
   

   
   
   
   

2. There’s a case for making it possible to enable row owners for ROW or UIDs. Relations, built safely/correctly, should not be based on user emails but instead, on some other value, preferably a ROW ID. The most common method to retrieve an email when a relation is built that way is through a lookup column, which can’t have Row Owner enabled.
   
   And since it can’t be enabled, the alternative is adding users’ email addresses to the sheet manually or using VLOOKUP formulas. Both of those options are problematic. In the first instance, if a user profile is built out enabling a user to update their email address at any point, relations could be negatively impacted (brakeage). In the second instance, there’s the risk of inadvertently wiping out that formula. And so long using a Glide table!

3. In some cases, we rely on a split formula to separate a group of emails sent to a sheet, to form an array column that can then be used as a Row Owner column. A roundabout way where the flow is: Joined List column > send to sheet > split > Array > enable Row Owner. Because, again, you can’t enable Row Owner on a Joined List column.
   
   Could we instead make it possible to enable Row Owners on delimited data in a sheet, somehow? Or certain types of Split columns?
   
   

   
   
   
   
   
   
   
   

Jump in if you have some thoughts on this, or that, or want to point out something I’ve missed (always the best).

[Jeff_Hager]

1. This is partially because Roles can be row owners. A Role isn’t an email address, but it can be any form of text. Also, I suppose it’s because some people won’t necessarily designate a column type as email, so it they leave it as text, then it would still be valid to use it for Row Owners if it contains an email

2. I completely agree with this. I think it is better to completely rely on UID’s and I would also like to see that function to set row owners on some sort of unique id that’s assigned to each individual user. For now, yes, the only option is to save an email into each sheet.

3. I’m sure you understand the reasoning, but column like Split Text are computed on the device and defeats the reasoning for row owners in the first place. Yes, it would require some sort of special column that’s computed on the glide servers instead.

Mostly just stating the obvious here, but chiming in with my thoughts.

[Rasha]

@Jeff_Hager

This is partially because Roles can be row owners. A Role isn’t an email address, but it can be any form of text. Also, I suppose it’s because some people won’t necessarily designate a column type as email, so it they leave it as text, then it would still be valid to use it for Row Owners if it contains an email

Ah… I was under the impression that Roles could only be Row Owners if they are part of an array formed in a sheet (Glide Sec Ctr). But I see now it’s the visual that confused me. Weird. So in that case a UID, for instance, can be a Row Owner column IF it’s used as a role in the Profile.

@Jeff_Hager

I’m sure you understand the reasoning, but column like Split Text are computed on the device and defeats the reasoning for row owners in the first place. Yes, it would require some sort of special column that’s computed on the glide servers instead.

Yup, your explanations as to why have been helpful.

[Robert_Petitto]

Completely concur on #2 and the desire to have a delimited data be row owners (or at least automatically seen as an array column without the need for a split column—perhaps as it’s own special Basic Column type).

[Jeff_Hager]

@Rasha

So then a UID, for instance, can be a Row Owner column IF it’s used as a role in the Profile

Correct.

[Rasha]

@Robert_Petitto

perhaps as it’s own special Basic Column type).

also a good thought. regressing to using more formulas is counter to the encouraged direction of Sheets → Glide Tables.

[Robert_Petitto]

I’m meeting with Mark and David about this very topic tomorrow in fact—hopefully we can make some headway

[Wiz.Wazeer]

@Rasha

There’s a case for making it possible to enable row owners for ROW or UIDs . Relations, built safely/correctly, should not be based on user emails but instead, on some other value, preferably a ROW ID. The most common method to retrieve an email when a relation is built that way is through a lookup column, which can’t have Row Owner enabled.

User emails should always be an option. It’s a delicate area.

[Jeff_Hager]

Of course. Maybe the word “completely” was the wrong word. The point I was trying to make is that a UID makes it easier to allow for a user to change their email in the future. It’s better to use unique keys to link data together rather than rely on personal details about a person that could change.

[Robert_Petitto]

Preach!

[Rasha]

@Jeff_Hager

This is partially because Roles can be row owners. A Role isn’t an email address, but it can be any form of text. Also, I suppose it’s because some people won’t necessarily designate a column type as email, so it they leave it as text, then it would still be valid to use it for Row Owners if it contains an email

Couple more thoughts on this:

Make Row Owner’s availability for other columns that may be designated as ROLES and subsequently Row Owners makes sense. I see that the ROLE field only picks up columns in the Profile sheet, yet in an app, the option to make a column a Row Owner is not restricted to columns in that Profile sheet. Unless ROW is meant to include non-Profile sheet basic columns (I wish it did. Makes it more accessible and scalable across multiple sheets), then it ought to be disabled for all non-Profile sheets.

In Personal apps, it should be disabled for all non-email columns in the Profile sheets and elsewhere. A user has no way of knowing why they’re presented with that option on a non-email column. Unless they find themselves in Profile Details where there’s a slim chance they’ll make the connection between Row Owner and Roles — a feature they’ll need to upgrade to PRO for. I imagine something like this could bridge that gap.