Configuring the Privacy Settings for your Glide App can sometimes be a little confusing, especially when it comes to understanding how each of the settings affect whether your Signed In Users are considered Public or Private.
The below flow chart aims to demystify that somewhat.
A couple of key points to understand and be aware of:
If you choose Private Access, then all users will be Private.
If you choose Public Access, then that doesn’t necessarily mean that all your Users will be Public. It depends what you subsequently select for Sign In and User options.
If you configure Roles in your App, then any User that you assign a Role to will always be a Private User, no matter what the rest of the settings are.
Yes, with the Privacy settings that you’ve shown, all signed in users will be Public Users.
And that makes me realise that I haven’t covered that scenario in the Flow Chart. I’ll see if I can update it.
User counts are across all projects in your team.
Do you have any other published projects?
Also, have you changed the privacy settings?
Those 3 private users could be from another project, or they could be as a result of a previous configuration.
Your user counts will reset at the end of each billing peruod.
Thank you, @Darren_Murphy , for putting this together. It’s incredibly helpful.
I have a question regarding accessing data configured with row owners.
Let’s consider I have 3 sheets in my app:
Each project has a unique set value, the ‘Job ID #’, which is the row owner in the Projects sheet.
Each line item also carries a Job ID for linking to a specific project - this Job ID also acts as the row owner in the Line Items sheet.
Each user has a role, which is set to the value of ‘Job ID’ in the Users sheet.
This setup functions smoothly until a user has more than one project. My assumption was that if I add another row to the Users sheet, keep the same email address, but assign a new role (using a ‘Job ID # value’ from the new project), the user would then gain access to both projects. Could you confirm if my understanding is correct or otherwise?
Your question is a little off topic for this thread, but anyway…
No, as has been pointed out - that won’t work. Each user should have only one row in the Users table. Additional rows with the same email address will just be ignored, and could cause problems when it comes to creating relations. So I definitely wouldn’t recommend that.
Do users share projects?
From your description, it sounds like they don’t?
If that’s the case, I think you’ve made this a bit more complicated that it needs to be. In fact, you probably don’t even need to use Roles. You could just add an email address column to each of the Projects and Line Items tables, apply Row Owners to that column, and fill it with the assigned users’ email address.
I’d also ask the question - why exactly are you using Row Owners? Do you have a clear picture of why it’s necessary, and what the implications are?
The reason I’m using row owners is due to the high volume of rows (line items), which total well over 25k. However, each user only needs access to 500 rows or less.
I’ve opted not to use emails as row owners primarily because numerous users have requested to change their email addresses in the past. When this happens, it would be necessary to update the email in all related rows.
Unless you are using Google Sheets, then you really have no other option but to use email addresses. With Google Sheets, you could use a non-computed array column for your User Profile Role, and assign up to 9 roles (Projects) per user. But that’s not an option with native Glide tables, because it’s impossible to create a non-computed array column.**
It would be possible to automate changing a users email address using webhook->Make->Glide API. In fact, this is something I’ll be needing to do myself very soon, so maybe I’ll create a topic on it.
**The recent introduction of non-computed array columns for files and images makes me hopeful that we might soon see the same thing for text columns, which would allow for multiple roles per user in native tables.