I have a pro app where the access to it using user registration (sign-in).
But am wondering if users are coming just to see the data, they should have access without having to go through the onboarding process but if someone wants to contribute something to the data, then they can/should register, and only then they will be able to add data. Is this setup possible or any leads towards something already implemented by anyone?
In simple, read access to all visiting the app, but registration mandatory for anyone willing to write into the db.
How will that help? am not sure if i got how that will work.
Currently its on public with email - i can try but dont want to break anything so want to understand what workaround you are trying to suggest.
Realized i had seen that option in Action but never thought of figuring what its used for because i had initially decided to design the app to make everyone “register” before using it. But the more i think the more i realize it might not be a good user experience. Now time to go back to the drawing board and trying put this into place on the copy of the app to see if it goes all fine.
Keep in mind @Shiv that if you set your app to “public”, activate “public with email” temporarily to create the profiles sheet (which your app already has) and then switch back to “public”, whenever a user force closes the app, I believe the user-specific data of that session is not saved. I think @ThinhDinh or @Robert_Petitto might be able to confirm this or be more specific.
I believe there is also a recent topic around a calculator that may be an interesting use case for you.
User specific column data is saved to glide servers as long as you are signed in. If you are not signed in, the USC columns are cleared once you close the app, as I believe they are only stored locally.
This is kind of tricky for me. Because one of the simplest USD that I use is the “Favorites” which is specific to user as we know. Thats exactly why I told I might want to go back to drawing board to figure out what to do. Apparently as this “Favorite” option is not something I can enable/disable or control using conditions its a bit tricky to come to a conclusion on what I want to do with this controlled registration thingy.
But thanks for confirming that user-specific data will be something I have to keep in mind. Thanks to Jeff and Rob also for confirming that.
I believe a favorites component will automatically prompt for a user to sign in once it’s clicked. As an alternative, you could set a visibility condition on it to only show when the user profile email is the signed in user, or the user profile email is empty. This should hide the favorite component of the user isn’t signed in. However, I’m not sure you could hide it on a tile or card overlay if the user isn’t signed. In that case I think it would still prompt them to sign in if they clicked on it.
@Jeff_Hager that’s right - last hour or so I was playing around that itself in a sample setup to see what works and what doesn’t when I switch like this. Fav component can be hidden or enabled but not the one which comes in the details panel which is an overlay on top of the post. And yes I did notice that when opened in a window where a user is not logged in, then it prompts to log in. At this point, I felt wish this popup screen would have been customized which says " to mark something as a favorite you need to be logged in(registered)". But I know its not feasible.
Now my next question is, how do I control the visibility of the “button” which is linked to the Sign-in action? i don’t want to keep it in some evidently visible place that makes anyone and everyone do a registration even if they are not contributors to the app? Can someone suggest to me some idea.
So you want a sign in button, but you don’t want it to be painfully obvious to everybody?
A couple of thoughts that come to mind.
You could skip a sign in button altogether and redirect users to the sign in function in the side hamburger menu.
You could create a rich text component with some subtle text that mentions that a user can sign in, but it’s not as large or as obvious as a button. Then set the rich text component action to be sign-in.
Use the same rich text component, but instead do a Link to Screen → This Item to get a fresh detail screen, and then maybe place some descriptive text to explain the purpose of signing in, and then have a sign in button below that text.