Hi folks !
Imagined flow :
Case of use, jobs board, object selling, ā¦
Is it already possible ? Some tricks to do that without external form ? Thanks.
Since you can pass an SKU to the Buy Button and that SKU along with the logged in users email is saved to a sheet as part of the Buy Button / Stripe process, you could write a script to scan through that sheet, see the payment for said SKU and then create a row in another sheet, with the users email and what product they purchased. You could then have a linked list attached to the users details that is set to āFilter rows by signed-in userā.
So yes it can be done now with some scripting.
Thank you very much George for this solution! Unfortunately this is not appropriate in my case because, by default, my app is in āpublicā mode, so I can not filter by user. I want there to be as little friction as possible.
I hope that the team can develop this function that can be very interesting for all non-physical purchases.
I am waiting with a lot of hope!
If the user doesnāt authenticate, how would you expect their purchase to restore in case they delete the app and come back, or browser data is lost, or they switch phones? Would only paying users have to authenticate?
I think I understand you @Mark, but by authenticate do you mean log in to the app using one of the email/pin methods?
Iām asking which method @JulienPIAO would prefer, whether itās currently implemented in Glide or not.
This cannot be done and is not a glide issue.
The logic is contradictory.
Itās either you have an app that allows everyone to see everything (public), thatās the easy one
Or you have an app that allows some people to see some things (public with email or whitelist)
You canāt have both at the same time.
Once you settle on using email filtering your solution will emerge.
currently, my app is in public mode so anyone can use it without friction. But on the other hand, if users want to use chat, comment or fav (or even buy?) on my app they need to identify themselves. And i like this type of flow.
If i want to use, āuser filtering featureā needs me to switch to email mode whitelist or email connection, and so, request user email before use the app.
My lovely flow 
I think it could be a great feature.
Hope you understand me and iām so sorry for my poor english.
I think the way you are setting this up could make it more work for your self and your end user.
if iās simplicity you want, use a webpage like square.com to sell your app and then once they purchase pull their email into the app as a user.
this way you can just build a pro app with filtering and separate the two things. Unpaid public or paid with filter.
final option is to build 2 separate glide app. one public and one filtered. But again you canāt have the same app be both private and public at the same time.
the final need feature is
Pay to add an item to an item list
Ex: Restaurant could pay to add his restaurant to city guide restaurantās list.
I think I get it now.
On a public app, two things require a sort of login via email. One is posting a comment, the other is when a user buys something via a Buy Button. At that point there is a cookie written that identifies the specific user, even though the app is Public. However because the app is public the option to filter by user is not enabled because Glide sees that it is a Public app.
@Mark If there was a Sign-In type of āPublic with optional email/pinā under app settings, that would solve this problem and maybe others could use it. If the user was not signed in, they would be assigned an invalid email by the Glide engine. Something like ā@@@@ā. Then all the places in Glide that have the āFilter rows by signed-in userā would be turned on for this new hybrid sign-in type. You would have to add a Button action that triggered this kind of optional sign-in.
Iām sure this is easier said than done but that is my thought.
My analogy
A website is like a picture of a car
An app is the actual car
a personās email is the key to drive the car.
If you build a public app is like give individuals a picture of a car and telling them to drive it, without a key.
When I just started app building, I deliberated with this choice hoping to get the best of both worlds. But then I realized that there is no such thing as a public app.
IF an app is a so-called Public app, then it would just simply be a website.
And the same if a website asked you to log in and filters your info based on your identity it would no longer just be a website but now become a web app.
Google.com search engine is a public website, but if you want Chrome to remember your password and gain access to gmail you have to use google web apps. You canāt have access to any web-app anywhere on the internet without signing in, because thatās what an app is.
An app by definition gives unique content to users. So what you are trying to do is use an app builder to build a website.
A suggestion is to use google sites, google form, square.com or some other free and ease landing page to sell whatever you are selling, capture the individualās email, and then at that point, you can give them access to the pro version of your app.
or you can build a public version of your app call it demo, and when they complete a purchase (you can capture their email and shoot them a link to the full filtered version of your other app.)
This is the same way the Play store works. Most demo apps are different from the full apps and you would have to download the full app after purchase.
You have a few apps that you can unlock full version but even those app require email login to know who you are in order to give you unique access.
Iāll argue these points a little bit. I think the Amazon Shopping app is a fantastic example. You can use the app all you want without logging in, add things to your cart and so on. It gets customers involved in the app, and letās them view the products. If they like what they see, then they can commit to creating an account and handing over their credit card info. In effect, the Amazon app is still tracking my device with cookies, which allows me to use a kind of filtered listā¦(the shopping cart). I donāt see a cart filled with all unregistered users items. I only see my items even though I havenāt logged in yet. Also, Amazon does not make me download a second app to complete my purchase which may cause many people to give up and leave. The Amazon example is a bit extreme, but I think itās fair to want to allow access to public parts of an app for unregistered users. Iām not saying we should necessarily allow unregistered users to add items to a per user filtered list, or any edit capability for that matter. Maybe any add/edit screen that uses the Email Special Value, would then require login before use, much like how chat works. When using a filtered per user list, I think itās reasonable to not force the developer to have to show all other userās private list items as the only way to make the app publicly accessible.
Why not turn on per user filtering in glide? If you havenāt logged in yet with an email that matches the filtered list, you just wonāt see anything, but at least the unregistered user is engaged in the app and can still see other areas of the app that arenāt filtered per user. I can see where some may have a need for this. Many people will not pay to use an app without first knowing what they are paying for and playing with it first.
Almost everything that is needed to do this is already baked into Glide. Like @George_B said, maybe a dummy email or some unique ID is assigned to unregistered devices that would cause the filtered lists to not show anything, but any other non-filtered components are freely available.
This would allow for a paywall. The user can explore the app and see the parts that donāt require per user data. If they like it, they purchase access to the rest of the features. This adds their email to a whitelist where they can then log in and see a filtered per user list. So really, I envision a Public with Whitelist option.
Ok I like the fact that youāre standing up for what you believe in and for that Iām going to help you with a workaround itās not perfect but it will get the job done
Workaround Solution
First share your spreadsheet with another Gmail that you have and give editing privileges to your second Gmail
Give your second Gmail ownership rights so that the Glide spreadsheet is only an editor and no longer an owner
In your email whitelist sheet create a user called demo user and leave the email section blank.(or you might have to put a fakeemail@sillyplace.co)
Try both ways.
Switch over to your other Gmail that now owns the sheet and lock the unregistered user item line that. This will prevent anyone from editing it
Now you can add a tab in Glide called profile and set the layout to details. what will happen every unregistered user who logs into your app will be faced with this unregistered user details view but because the app is is locked from the master no one including glide can edit it. This way you can leave the edit component on for when they become registered.
Add a form button inside the profile layout for them to create a user profile. once they create a user profile, the fakeuseremail will disappear and their logged in email will Trump the data in detailed view.
You will be able to edit it then you can use relationships to give special access to the registered users for the areas that you want them to see I will send a link to show you how to do that that is the only way to do that what youāre asking to do but it has some drawbacks but at least itāll work until you get to the real way
Easy peasyā¦
Thanks for the workaround! I think this would solve the problem I have too, but seems difficult to implement.
High-level: Also looking to allow users to scroll through app without creating account until they want to add or edit.
If Iām understanding the workaround - essentially, every user is considered signed-in as a fake user until they actually register.
Thx. Glide has added the hide feature that makes this a lot easier now.
Now all you need is a user page with all the users of your app and set that page to filter by user login.
Then create a additional column references to all other sheets.
In the component view you can now make an entire component invisible based on content of any column.
So once you set a user to be admin, the admin reference component column could become visible based on that condition.
In other words, Every user has access to everywhere but is blinded by the visibility feature which check any column you choose for the trigger. Which could be a column called user level.
In glide ācomponentā is visible if user access is admin
Glide does not provide a native way to allow a user to preview the app without logging in, then later allow the user to login to view more features or have more editing rights. @Lighted_Candleās example would still require a login to get into the app. What he is suggesting is to use Visibility control to hide or show components based on if a user has completed a profile or been given certain rights in a user profile. A good example of this is the Finstagram template https://go.glideapps.com/app/finstagram-template. You could probably use a form button to allow the adding of data along with some sort of visibility control, but without a login, you cannot use per user data to control what a user can see. A user would have to be shown a record unique to them to be able to reference that record to other sheets. If you have a public app and have the hamburger menu visible, I think you can allow the user to login, but you may still run into some issues with controlling what the user can and cannot see. This all depends on what you are trying to accomplish with your app.
I do believe itās a feature they could make available in the future, since chat and favorites kind of work this way, but currently I donāt believe there is not a good option. At least not an easy way that I can think of. If we were provided with a global logged in user value that we could use in filters, then this would take care of some of the issues, but probably not all of them.
Thanks so much, thatās very helpful and insightful! The Finstagram example seems to be the best option for now.