I have an employee directory in app. Employer admin should be able to consult limited public data about each employee.
I don’t want a workaround like to manage 2 independent tables (private user;public user) like i tried before (“make your profile public” button and it was recopied in another table, but never updated then…)
I found the solution, but its for google sheet, i cant manage to reproduce with Glide table ! (I want only Glide tables in my app, it’s faster and Glide team keep encouraging using it, so…)
To get example 2 from the docs using only Glide tables, probably the easiest way would be to use an onboarding process for each new user. At the end of the onboarding process, have them tap a button and use an action with that button to set a secondary owner column in their User Profile row to an appropriate value. This could be the email address of your Admin user, or it could be a Role that is assigned to multiple Admins.
My mistake, i wish to create the same result as end of EXAMPLE 1, : “Instead, we can mirror the non-private columns from the User Profiles sheet and display them in a second sheet. Then we can show the data in the non-private sheet without Row Owners. …”
(Your workaround to example 2 is still interesting for something else… thks anyway )
There is no way to do it with computed columns, because with Row Owners on the main Users table, most rows won’t even exist on user devices. So computed columns will have no effect.
This is just off the top of my head, so it might not be the best approach. But here is one way that could work:
You would need to modify every action that updates your User Profiles table, so that it updates the corresponding row in your Public Users table at the same time. That’s probably not as bad as it sounds. All you would need is a single relation from your User Profiles table to your Public Users table, and you can do a Set Column values via that relation every time you have an action that modifies a User Profile column. You’d probably still need an onboarding step to create the Public User row for each new user.
No, that’s not possible unless you use something external to Glide such as Make. But it would require a Business or Enterprise subscription so that you have access to the Get All Rows API call.
With that, you could periodically fetch all rows from your User Profiles table via the API, and then write them back through the API into a Public Users table.
The example from the docs that you want is referring to mirroring your users table in a Google Spreadsheet using an arrayformula.
But you stated that you want to use Glide Tables only, so that option is not available. As to why there is no equivalent function in Glide Tables, I already gave you the answer to that:
Here’s what I do. I still create two different tables (even though I wish we didn’t have to).
a users table with sensitive information protected by row owners
a public profile table without sensitive info.
What I typically do is have an onboarding screen that ultimately generates a new row in the “profiles” table with the public info. I record the Row ID of the user in this table.
I then create a relation from the user table to the profile table. In my app, I allow my users to edit their “user” table info and “on submit”, update the public profile info through the relation.
@Darren_Murphy thank you !
I used to do this technic before you told me how to… but i was going crazy with everything double ^^ user had to tap something like “make my profile public” before being able to chat between each other.
And …. when they had to edit the public profile separately - i was not using the row id relation…
Glide team should add an hint on the doc:
« Only possible on google sheets for now. »
Especially as the future seems to be glide table only…
It’s such a common function… at least any good/secure directory needs it.
Guessing its not possible for Glide to only protect certain columns, such as emails and other personal data and allow the rest to be accessed publicly. Thus, our lookups can still find unprotected data. Having a separate public profile table doubles the row consumptions.
I guess if email is the only thing to protect and you dont need to send emails to users, I can use the anonymous email instead of collecting real ones
)
