Forum Academy Marketplace Showcase Pricing Features

Working on data prior to log in

Question
#1

Hello everyone,

I’m trying to allow users to fill a shopping cart prior to logging in or signing up.
Currently I have a Page of type Shopping Cart and crate a new object and link it.
Once a user logs in/checks out, I link the Shopping cart to the logged in user.

But if the user doesn’t log in (abandons the cart), the data lives on orphaned in the DB. So I wanted to create a “session” that would expire and I could create a workflow to delete orphaned carts. Deleting orphaned carts arbitrarily could affect people still using the app but not logged in.

Anyone have any ideas or doing something to achieve this?
Is it safe just to look at “modified” timestamp?

After some reading, I have found that a user thing is created prior to log in. Are these deleted every so often? Can I link to those users and delete the linked things with them?

Thanks

#2

The pre-login user is stored in the Bubble cookie.

So lasts as long as that cookie does. It will be converted when someone signups up.

#3

Thanks @NigelG.
Does the user instantiate all things included on load?
Would a “shopping cart” thing be created (in the cookie) and ready to use (if that is in the User fields)?

My concern is if not, I would have to create “shopping carts” and add to the “user”… still leading to orphaned shopping carts. Unless I am over complicating.

Andrew

#4

Bubble creates a temporary user whenever a browser session is started that doesn’t have a logged in user. These temporary users are stored for 3 days:

The User Type - Bubble Manual

You can modify temporary users the same way you can signed up users, so adding a shopping cart to the current user (even if they haven’t signed up) works just fine, and if they sign up within 3 days they will be converted to a signed up user and and data stored on their record (such as an associated chopping cart) will be maintained.

After 3 days, if they don’t sign up, the temp user will no longer exist so the shopping cart you created won’t have an associated user. So you can just delete it with a scheduled backend workflow, 3 days after creation if the cart’s associated user didn’t sign up.

If you want to associate the cart with a user for a longer period than the 3 days Bubble stores temp users then you can just set your own cookie on the user’s browser (there are a few plugins for this) to store the ID of the shopping cart for as long as you want, then apply it to the user once they sign up.

2 Likes
#5

Thanks @adamhholmes.
The problem I’m having is that I have a Data Type of “Shopping Cart”. Unless I create a new thing and point the user->shopping cart to it, I can’t seem to populate it. But that leaves me with rows of data that I don’t believe will get removed with the temporary user.

Or did I misunderstand?
Thanks for clarifying.

Andrew

#6

Only the temp user will get deleted automatically.

So any associated ‘things’ like shopping carts etc. that you don’t want to keep will have to be deleted in a scheduled backend workflow.

I’m not clear on what you mean in your first point… ‘I can’t seem to populate it’?

Populate the user? or the shopping cart? Or are you creating a separate ‘user_shopping cart’ thing?

1 Like
#7

Thanks Adam.
I took some time to play with it.
It looks like the user field is blank even when there is a temp version in.
Once it’s deleted it says [deleted item] in the field but I haven’t found a way to search on that.
But thanks for your help. I really appreciate it!

Andrew

#8

Hi Andrew, yes that’s right - although the temporary user is stored, you aren’t able to view it in the database or access it, and any user-field on a datatype that has a temporary user in it will appear blank, but should that user sign up within 3 days then they will appear in the field.

So you can delete your shopping-carts with a conditional workflow (e.g. only when this shopping-cart’s User’s email is empty).

We use this same approach for deleting shopping carts, user offers, referral links, and various other things that we don’t want to keep permanently in our database once the associated (non-signed up) user has been removed (we usually store them for 4-5 days just in case we need to access them, then delete them).

#9

Adam,
Just for clarification… the User “is empty” does not pick elements where the User is in the cookie and is safe to use and not delete active shopping carts with temp users?
In my DB view the “empty” and “temp” look the same… only difference is that in 3 days I see a [deleted] in some of them. I should have tested for that.