It goes like this: Given

  • Your default profile/address (which is preselected) has been used in a completed order;
  • You spot an error (e.g. your phone number needs an update) and fix it right there by typing in the text boxes on the checkout page;
  • ..and click the "continue" button

Your profile gets duplicated (Commerce Order does that, to preserve data on existing orders). But unlike the edit screens in the 'address book', the outdated profile does not get disabled. So now you have two very similar choices in your address book.

Patch fixes that by disabling the outdated profile.

-----

I just realized there is a small UX issue here, for people who don't pay much attention to the "Addresses on File" select element and don't know that there is a concept of an address book. (In other words: they don't see the difference between 'adding a new address' and 'editing the current address', on this checkout page.)

If they just start typing in a completely new address to send a new order to, may not realize that they are essentially removing the existing address from their address book.

But it's either that, or (as it is now): every time they order something and see an outdated phone number in the default selected address, they correct it again... and the address book starts growing with one duplicate address, two, three, four...

(The patch is on the current version; the text file is the same patch re-rolled on top of #2070643-5: Default address not always used in checkout pane).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

roderik’s picture

By the way, if you upgraded to Address Field 7.x-beta5 but you have saved customer profiles from pre-beta5, you need to apply #2169863: Fix duplicate saving of customer profiles. Otherwise "disabling a profile" will clone a profile, instead.

joelpittet’s picture

This looks great!

Maybe also the same thing for editing in the backend as well?

commerce_order_commerce_customer_profile_presave() to apply the disable logic a bit more generically.

mglaman’s picture

Category: Task » Feature request
Related issues: +#2541004: Add testing!

Looks like a great feature, and test worthy

mglaman’s picture

Marking for 2.0 release plan

torgosPizza’s picture

I can verify that the presave() solution works super well.

In my case, updating a Card on File card that was used on an order, not updating the card but updating the address results in duplicate addresses which ends up looking very messy.

I think in 99% of use cases, a customer changes their street/city/zip (for instance if they move) and so they need to update their card. Obviously orders made to that address should not have their information changed; but there is no reason for the old, outdated address to continue showing up, since in her mind she is "updating" her existing address that is attached to that card.

I tested with this tiny patch (attached) to disable the $original_profile during the Edit submit phase and it works as expected.

torgosPizza’s picture

FileSize
567 bytes

Sorry, bad copypasta. Use this patch instead.

(Note that I did not roll these two patches together since they are for somewhat disparate areas.)

Neo13’s picture

When I applied the original patch from roderik the ajax replace command stopped working. I didn't dig any deeper into what exactly is the issue.