Question about impact to user-specific columns when using Private sign-in (w/ pswd)

My app is currently set to Public w/ email. I’d like to convert it to Private - access by password, however:

  1. Per Glide this means not benefiting from user-specific columns and I have quite a few. I understand that’s a function of the app not knowing the user’s email but there really isn’t a logical place to force an arbitrary sign-in screen. And if I were to set this up, would this need to occur every time they use the app?

  2. I have not previewed a private with password sign-in flow before and seems I can’t without actually making the switch first. Can anyone share a link to an app with this configuration?

Thanks and happy Monday.

1 Like
  1. Yes, that’s right. If a user merely signs in with a password, we do not know who they are and cannot load user-specific data.

Once a user is signed in with email, they will stay signed in, and they will have access to their user-specific columns. You can trigger sign in with the Sign in action.

1 Like

Thanks for your input, @david !

The challenge is triggering that sign-in action in a way that makes sense. This is an Admin-type app where it’s difficult to randomly gate a tab or section to force that secondary sign-in. The “admin” rightfully assumes they’re “in” once they sign in via password.

Aside: Sounds like the app sign-in screen only has a password field? But agreement checkbox can still be enabled?

It also sounds like whatever user-specific info there is in the app at the moment would be lost during a transition from public to private, then populated from scratch once the admin signs in via that action.

Most of these user-specific columns drive UI components with the exception of a few that control a fairly complex scheduling tab.

1 Like

It sounds like Password login is not right for your app. Why are you using it instead of normal login?

1 Like

My understanding is role-based security can only be enabled w/ Private apps. Of the two options – pswd vs. whitelist – the first is better-suited. The inability to scale Row Owners dynamically as mentioned by others is a real pain point and until computed columns (at least split) can be converted into Row Owner, role might be a viable option. Admittedly, I have not yet explored if actions can help auto-add row owners to arrays but on my list.

I would like to test out a private sign as well, without disrupting my live app.

1 Like