User Profile with Users table – Access with a different table

Ask for Help
1

I was handed an app with the following:

  1. In > Settings > Access, access is set to private. Users in a table called “Team Members” can access the app.
  2. The User Profile screen uses the Users table as its data source.

Is there a scenario where such a setup would make sense? Shouldn’t the tables used for access and the user profile screen be the same? Shouldn’t this be an imposed constraint?

2

Yes.
Imagine an App that is used in a Business. Then imagine that an employee leaves the company. You may want to remove their access to the App, but retain all their data. This is exactly how you do that. You simply delete their row from the access table, whilst keeping their user profile intact. I’ve used this setup in several Apps.

3

Nice scenario. So in your scenario, you set up the app and in particular the Users table and the User Profile screen in what a would call a normal fashion, and then just for the sake of access you would have a separate table?

I’m no expert here at all, but I feel like the access table creates data redundancy. An “access” column in the Users table would be the “correct” way to approach this.

If I’m correct (I’m not saying I am), then in your scenario the access table 1. forces the builder to create a non-normalized database and 2. is what I would call a workaround hack to what should be an access column in Users table.

But I see now how this access table can be practical in your scenario: “separate users table and user profile from user access + remove user access while keeping user data”. The use case is great, the execution is meh (in my view).

4

Yes, correct.

mmm, yes and no.
Bear in mind that the access table only requires a single column - email address.
And it contains a subset of the emails in the users table. ie. only active users.

I don’t necessarily disagree with you that there may be better ways to implement this, but this feature has been around ever since the days of Classic Apps. And if it ain’t broke…

5

I see. If there were an Access column in the users table, writing to that column or writing an email to a new row in the Access table is the same effort (I assume).

It seems unnecessarily complex and confusing. To me.

Here’s the thing:

  1. Glide boasts itself as being a simple way to build robust applications. Whether that is rigorously true or not is anyone’s guess, but I would still argue that Glide is easy to use and powerful. That’s a rare combination. To me, sticking to the ethos “being easy to use” is way more important than “it’s always been that way” (I know, you have nothing to do with it).

  2. I was vaguely familiar with this access table, had forgotten about this “separate users table and user profile from user access + remove user access while keeping user data” feature (of course, how could I know forget) and just stumbled upon this setup with a client. They set this up, and so it got me thinking about the feature. My conclusion about confusing features in Glide is mostly the same: if I don’t get it, then 90% of Glide users don’t get it either (not sure if it’s 90 or 70%, but let’s say it’s a strong majority). So now I understand what the client had in mind: they precisely did not understand the nuances of the feature, saw an “Access” table in settings, and set it up.

Thanks for shedding light on this. I’ll probably ask again in a few months :sweat_smile: