Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Validation email error with an old account with bug before email confirmation work #2841
We have one user in France who created her account when there was a bug with private shopfronts. We discovered the bug with her actually. Today her account still have the following issue:
We are stuck, we can give no support, she doesn't have another email she can use, and anyway I tried that workaround but it's failing also (see #2840)
She has validated her email so she shouldn't be a guest anymore and not treated as such. She can get subscriptions.
Steps to Reproduce
The user is trying to get subscription working... but it doesn't work for that particular customer.
There is no workaround, but it concerns only one user, so I would say S3
Ok, this user is stuck. I know it concerns only one user, but there is no workaround, we have trying everything we could imagine with Rachel, and the inconsistency guest/account seems like there is a tech bug. Does it qualify as a S2? We have really no workaround... we need someone to look into DB to try to understand the problem. I try it, if you disagree retrograde, I will just have to try to make her wait and not use subs for herself...
UK are also experiencing this issue with one shopfront.
@myriamboure with this affecting a user in UK and France can we up to s2?
I haven't looked at the data yet, but I have an idea of what could be going on. Let's get the terminology first:
A subscription is associated to a customer,
I looked at the French data and can confirm that the subscription is associated to a guest customer. There are many different ways how we can fix it. Here are some thoughts.
Create a new customer record with the registered user
The admin interface doesn't let you create two customer records with the same email address. Since we have a guest customer already, we can't create another customer record ourselves. But the user should be able to log in and order from the shop. That should create a second customer record.
I tried that locally, but ran into other problems. That user already ordered yesterday and if I now try to visit the shop, it crashes. The order from yesterday can't be displayed, because the code can't fine the prices any more. Very bad and very distracting. Another S2?
But that order proves that creating another order as user doesn't create a new customer record. It seems to think that the guest record is enough.
Allow to create multiple customers with the same email address
We could change the code to allow the creation of a registered user customer with the same email address of another customer. This could be very confusing, but it would allow to resolve this issue. It would also be correct, because email addresses can change owners. If an email address is given to another person (like a phone number), we should create a new record. This would only be possible if we can deactivate the old account first.
I need to look into the last pull requests working on this field to understand what the latest agreement was. What should happen when an existing guest customer decides to sign up?
Make the guest customer a registered customer
A developer can change the association in the database:
c = Customer.find(887) # Perrine's guest customer account associated to the subscription u = Spree::User.find(828) # Perrine's registered user account c.user = u c.save
This could be the easiest and quickest fix. But I'm still thinking about data integrity. It means that we have a registered customer record that is associated with guest orders. That's probably okay, but who knows, we have a lot of unanticipated data integrity problems at the moment.
I think I understand now what's happening.
We need a subscription that is associated to a registered user customer. Our own data validation rules restrict us to only one customer record per email address for each shop. In order to work within these constrains, we can only update the customer record to associate it to the registered user (code above). But this is not a permanent solution. This will happen again.
I would like to propose to allow two customer records per email address. One for a guest and one for a registered user. In this case the solution here would be to create a new customer record and a new subscription for the new registered customer. The subscription for the guest customer can be stopped.
What to do for now
We should run the code above to update the current customer record. I don't think it will be a problem, especially since we know that it's the same person. It is easy to revert as well. I'm not sure what will happen to the subscription though. I don't know if it will try to create the order again and if that is desired. Since the customer ordered yesterday, we probably don't want two orders. That's why I think this should be done after talking to the shop manager and possibly to the consumer. Everybody has to check that they get what they want.
Here is the code again to associate the user to the customer record:
c = Customer.find(887) # Perrine's guest customer account associated to the subscription u = Spree::User.find(828) # Perrine's registered user account c.user = u c.save
And in case you want to revert it:
c = Customer.find(887) c.user = nil c.save
Thank you @mkllnk for the investigation, I think the porblem might be related to #2338. We were supposed in this solution to be able to have two records with the same email in a given shop, but apparently it has not been implemented as expected.
If I have a subscription running with the guest account and a second record is created for the registered account, the subscription will keep on with the guest account, no? If I want to switch it to the customer account I have to stop the subscription and create a new one with the registered account so does it mean I will see twice the name of the customer when I first choose the customer in setting up the subscription? I will see twice the name so I need at least to know which one is the guest and which one is the registered customer...
All in all I find all that very confusing... with the level of complexity we have in our processes I'm wondering if we shouldn't just remove the guest checkout possibility. Or accept to just change it from guest to registered and associate previous guest orders to it.
@mkllnk about your argument on email address that can be realocated, I'm still pretty dubious, how does other systems manage that? If I buy on Amazon, I die and my email then is used some time later by another person, when this person tries to access Amazon the site will say the address already exists, will ask "new password" and then the person will be able to access my previous orders, etc.
Can an email address really be reallocated to someone else??? I think it is important to answer that question first... and I would like to know how other system do. There is no way IMO to protect from that... unless the system is notified that the email address has changed owner by some central authority... The email is used by so many system as unique identifier, so why is it if the email is not a satisyfing UNIQUE identifier?
For quick fix I'm happy that we just associate the user to the customer record so the user. Can you do it @mkllnk ? Or should I ask someone else? Let's do it, I'll pause right now her subscription so she won't be affected straight away.
But we will hit the problem again so we need to find a more durable solution in parallel...
Ok the impact of this bug is worse that I thought:
THIS IS A MESS !
I told the user to hold on, we need to find a durable solution from now it seems or the subs feature is unusable. @mkllnk @Matt-Yorkley you both have worked on it so might be more familiar with potential solutions... would like to hear also @luisramos0 inputs about how such problems are handled in other systems maybe?
Trying to list options to solve that annoying bug:
I know guest checkout is something people like, but it's causing so many issues, I would vote to go for option 3 personally. Do you see other options?
The pull request solving #2338 only added the label to guest customer records. It didn't change any logic. The description says that there were duplicate customer entries, but I don't know how that could happen. The uniqueness constraint was added in 2015 ed941e2.
Yes, that is how I imagined it would work.
On email address re-use
Most systems don't deal with re-allocated email addresses. I'm not sure about Amazon, but in most online shops somebody could take over your account after they inherited your email address.
Email addresses are recycled by most email providers. It made the news when people realised that it is very common practice. One exception is Google's Gmail. They explicitly say that they are not recycling any addresses.
I have updated the customer record. It's now associated to the registered user.
Inviting users to OFN
We definitely have a broken process here. And we talked about this a lot before we released subscriptions. We must have forgotten along the way that this is still not solved.
If a shop requires logged in users, they can't invite guest users. It's bad that our UI allows that. We talked about enforcing users to log in for subscriptions, but that is a problem as well. Some shops want to be able to create subscriptions without the customer needing to do anything. They are talking to a customer without computer on the phone. That's why we allowed shop-managed guest subscriptions.
I totally agree that we miss the feature to create registered user accounts for customers. As you said, they need a different welcome email explaining who invited them to what.
Transition from guest to registered user
I find this one really difficult. On one hand it would be really convenient to just associate a new user account with all the old data associated to that email address. On the other hand it can violate people's privacy. Even though it's a rare case, you can't say: "I'm innocent to 95%".
What do others do? You mentioned Amazon not allowing guest orders at all. Shopify does allow guest orders and keeps the guest history separate from a new account's history. We could probably find more examples for either practice.
Is a subscription so complicated to re-create? Should we give a shop manager the power to re-assign a subscription from one customer to the other?
I dont think so, sounds complicated.
Any other implications @sstead?
Change guest account to registered account
Can't we just do that? Associate the new user to the guest user, BUT not associate the guest orders with it, like move the association of guest orders to some form of general guest user, like a trash user ;-) I say that because I guess an order needs to be associated to a user.
As a hub I could invite customers, and create subs even on guest customers, when they finally register they are recognized and their account becomes registered, so from now on they can see their orders, etc. The UX would be ok, even though the first subs I will have won't be saved in my customer account...
The problem of recycled emails is not fully solved, but not more than it is today, if my email is recycled, the person who inherits it can ask "forgot password" anyway, so I don't really see what it changes from what we do know... if we want to address that problem we need to change the way we work today.
Removing the possibility to checkout as guest
You can already create subscriptions for guest users, the problem is that when those users register, it makes the subs crash (as it did for Perrine here) as it is associated with the guest account but there seems to be a conflict that @mkllnk mentioned above "But ordering as guest is not allowed if there is a registered user with the same email address. The order fails and remains in the cart state."
I know if might discourage some users to have to create an account to be able to buy, but it's always a design question. If customer can shop, put product in the cart, and you are only asked to login when you checkout, you have already "catched" somehow your customer, it's not as bad as asking to register to see the content of a shop. I don't think it would be too problematic...
If we move toward that direction, it means when you invite a customer in your shop, if should be an invitation that the customer has to accept buy confirming the link and setting up the password, so it's just another confirmation email, and like managers are invited, customers will be "pending" until they accept.
So technically, as a hub I wouldn't be able to create a subscription until a user has accepted to join my hub. Which doesn't sound like illogical to me. It will be marked as pending and the hub manager should be able to resend the invitation in case the customer deleted it, or didn't pay attention.
So those are the two options I see then... what do you think ?
To sum up:
Option 1b sounds good to me. I'm not sure yet what exactly that means on the data level. We may copy the customer record or disconnect the old orders. It may even be good to never associate anonymous guest orders to a customer record. If the shop wants to see all orders of one email address, they can use the filter. Do they need a customer record?
@mkllnk you probably need other devs answer on this, but my 2 cts is that it is fine if guest orders don't have a customer record, like are linked to no customer. @Matt-Yorkley @sauloperez @luisramos0 do you agree ? It would be good to move forward then as I see UK linked another case, and we have users just waiting for this to be solved to use again subscription, they are just blocked.
I like this option too. Subscriptions and orders created by the hub before a user registers will not be exposed to the user by default, unless the subscriptions and orders are explicitly assigned to the registered user (if implemented).
We could then think of the data of the guest customer record as the hub's own data, which the hub alone manages, not the person behind the customer record.
And then this restriction can be removed too?
I prefer this option too, even without considering that it seems to be the fastest solution. Then as mentioned, we'll probably need some indicator in admin views for whether a customer email is for a guest or for a registered user.
I see contradictions in what you say @kristinalim but maybe I don't fully understand. For me if we allow two accounts per email then it's not possible to move a guest account (attached to one email) to a validated account. What we suggest in 1b is that, the user account becomes validated, it's not a second account attached to the same email. There can only be one account with one email (if I understand) but the status changes. Also it's logical then that if you are not guest anymore, you cannot buy as a guest with the registered email.
From the discussions above it seems people prefer to keep guest accounts and not get rid of them. I have no objections but if guests accounts cause so much trouble I think we should consider also simplify and get rid of it. People do have to create an account to buy on Amazon and it doesn't prevent them from buying. If we keep the possibility to put items in cart and only login at checkout, I would consider that possibility. @lin-d-hop @sauloperez @kirstenalarsen @luisramos0 what do you think about the option 2, ged rid of guest accounts? Hard to get data on that, probably there is a significant number of customers who checkout as guests today, but would they stop buying if they had to register?
@myriamboure Guess what I just found? Our preferred solution 1b is implemented already. This really affects only old user accounts that have not been associated with their customer records yet. We need to run a database migration to fix it. Here are some stats for French production:
select count(customers.*) from customers join spree_users on customers.email = spree_users.email where customers.user_id is null; -- 319 guest customer records that should be associated to a user select count(distinct customers.email) from customers join spree_users on customers.email = spree_users.email where customers.user_id is null; -- 305 people affected select count(id) from subscriptions where customer_id in (select customers.id from customers join spree_users on customers.email = spree_users.email where customers.user_id is null); -- 0 subscriptions affected (subs total: 22)
referenced this issue
Nov 23, 2018
Great @mkllnk that's a good news ! Does it mean that the user can safely create new customers and subscription for them, and when those customers decide to create an account, their subscription will be automatically attached to the new registered account? So yes we have to fix that (I know there are similar problems in UK so that migration is needed everywhere I guess) but good news is that we can tell subs user they can freely go already and setup subs, right?