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…