Steps to reproduce:
1. Enable anonymous checkout
2. On the checkout form, enter a username that already exists and submit the form
3. Validation fails due to the existing username, but the username is stored with the order and committed to the database anyway
4. Clear the username field and submit the form
5. Continue with checkout to completion.
6. New user account creation fails because it was trying to use the stored username
Expected results:
Clearing the username field should clear the username stored with the order.
Other notes:
The same behavior occurs with the password field.
Proposed solution:
This is a little tricky, because the order is saved during validation and seems to only add/update data. So the attached patch always stores the entered username and password even if they're blank. This required a small change later on in the process to make sure these blank values are ignored.
Comment | File | Size | Author |
---|---|---|---|
#8 | 1985404-new-username-error-reset-7.x.patch | 3.07 KB | longwave |
#6 | 1985404-new-username-error-reset.patch | 3.05 KB | longwave |
#4 | 1985404-new-username-error-reset.patch | 1.81 KB | longwave |
#2 | 1985404-new-username-error-reset-TEST-ONLY.patch | 1.81 KB | longwave |
new-user.patch | 3.67 KB | balloon | |
Comments
Comment #1
longwaveComment #2
longwaveThis is quite a subtle bug, thanks for tracking this down! The attached patch implements your steps to reproduce as a test case for now. I think there might be a cleaner way of resetting the username but having the test will prove that any change here works correctly.
Comment #4
longwaveThis is much simpler than the patch proposed in #0 but still seems to work.
Comment #6
longwaveIt helps if I upload the right patch.
Comment #7
longwaveAs the test now passes, committed #6. Needs porting to 7.x-3.x.
Comment #8
longwaveComment #9
longwaveCommitted to 7.x-3.x.