Updating email in user account, doesn't update email in order (cart) mail property

Cross posting my thought from #2873685: Order E-Mail is not set when logging in or registering on Login pane.

A feature would be for commerce_order to check if a user has changed their email address. In the event this happens, we load all draft orders which belong to the user and update/sync their email field.

Checked 1.x, and it kept only the cart orders up to date:

/**
 * Implements hook_user_update().
 *
 * When a user account e-mail address is updated, update any shopping cart
 * orders owned by the user account to use the new e-mail address.
 */
function commerce_cart_user_update(&$edit, $account, $category) {
  // If the e-mail address was changed...
  if (!empty($edit['original']->mail) && $account->mail != $edit['original']->mail) {
    // Load the user's shopping cart orders.
    $query = new EntityFieldQuery();

    $query
      ->entityCondition('entity_type', 'commerce_order', '=')
      ->propertyCondition('uid', $account->uid, '=')
      ->propertyCondition('status', array_keys(commerce_order_statuses(array('cart' => TRUE))), 'IN');

    $result = $query->execute();

    if (!empty($result['commerce_order'])) {
      foreach (commerce_order_load_multiple(array_keys($result['commerce_order'])) as $order) {
        if ($order->mail != $account->mail) {
          $order->mail = $account->mail;
          commerce_order_save($order);
        }
      }
    }
  }
}

So some kind of order refresh, Order::preSave() logic would be consistent with that.

Then aside from carts, @bojanz would the recommendation for this situation be to "reassign" the order to the updated customer (user)? (If you don't know about it already, see the "Reassign" operation, available on the Orders page.)

Disregard my last comment, I see the OP is only concerned with carts, not placed orders.

This is a corner case, granted, but it's surely a bug:

1. user creates a cart
2. user changes their email in their account
3. user completes checkout, and doesn't receive a receipt.

Furthermore, this is going to have an effect on recurring orders from Commerce Recurring, where it's definitely NOT a corner case, since an order stays in draft for the whole billing period, which could be something like a year.

Here is patch for this

Following Bojan's suggestions: Update emails for all not placed orders of the user.

Also removed !$this->getEmail() for updating order

    if (!$this->getEmail() && $customer = $this->getCustomer()) {
      $this->setEmail($customer->getEmail());
    }

And update the Kernel Entity Order test for these changes.

p.s. Not sure about Commerce Recurring cases.

> p.s. Not sure about Commerce Recurring cases.

Commerce Recurring keeps recurring order in the 'draft' state and with placed = NULL until they are charged to the customer, so the approach in #9 looks ok to me for that case.

It seems the tests fails because of "!$this->getEmail()" removal update.
So we need other approach:
For example extra check for customer mail

    if ($customer = $this->getCustomer()) {
      if ($customer->getEmail()) {
        $this->setEmail($customer->getEmail());
      }
    }

seems to work for CheckoutOrderTest::testGuestOrderCheckout
Could it be this what's needed here?

Here is a new patch that should fix the broken test - check directly about the customer email when updating an order.

Here is a new updated patch the should fix the tests.

Broken CouponRedemptionPaneTest it should be solved by another patch from other issue.
See #2884210-8: Hide the coupon redemption form behind a link

The test fail is not related with an issue.
So i think we're in "Needs review" for now.

+++ b/modules/order/commerce_order.module
@@ -57,6 +57,28 @@ function commerce_order_local_tasks_alter(&$definitions) {
+    $order->setEmail($user->getEmail());

Minor optimization: set the user email in a variable rather than keep getting it.

@joachim thanks for suggestions.
Here is a new update for the patch : use variable for (customer) user mail value

The test fail is not related with an issue.
So i think we're in "Needs review" for now.

Updated the patch, please review.

I accidentally stumbled upon this issue, but I wanted to shine another light on this issue.

Doesn't commerce fill this data too early? Wouldn't it make sense to copy the customer mail only just before completing the checkout (I understand that potentially interfere with some events).
I also noticed that IP addresses do not update. The IP used during order creation is logged (could even be the admin's), but if I then login to another computer the initial IP address remains in place.

Isn't the data during order checkout more relevant than the data during creation?

It might also be an option to include the email in the profile, that would keep all customer data in one place and visible and easy editable during checkout?

I tested the patch at #24 on an install using Commerce recurring. The draft order was successfully updated with the new email. But the original order's email was not.

I have tested #24 and found its throwing error in the hook_ENTITY_TYPE_update for the argument passed, so i have updated the patch slightly to specify exact type of argument and now its working fine for me.

See child issue here to update all orders upon customer email change: #3200326: Updating email in Drupal user account doesn't update email in completed orders details

Patch in #28 has worked for me (for all commerce recurring draft orders). Thanks!

To get ALL orders updated, in addition to #28 patch, I applied patch from #3200326: Updating email in Drupal user account doesn't update email in completed orders details and it works.

I can confirm the patch in #28 is working.

Updated the patch to query only for "draft" orders.

Also, querying orders that don't already have the right email.
Fixed the tests.

The only thing I'm wondering is whether this code belong to the cart module (Since the order assignment logic lives there)... But I guess it can stay in the order module as we don't check the "cart" flag.

hm... actually, I'm not sure about the order presave change... As this could update the order email of placed orders...

And.. This would actually prevent an actual update from the UI as the value set on the customer would always override the order email.

I think we should either remove the order presave change, or limit it to draft orders.

The attached patch is maintaining the order email only for draft orders. Once an order is no longer a draft, it shouldn't be magically updated...

1. +++ b/modules/order/commerce_order.module
   @@ -115,6 +116,33 @@ function commerce_order_field_formatter_info_alter(array &$info) {
   +/**
   + * Implements hook_ENTITY_TYPE_update() for user entities.
   + */
   +function commerce_order_user_update(UserInterface $user) {
   +  // Maintain the email up to date for orders that aren't placed.
   +  if (empty($user->original) || $user->getEmail() == $user->original->getEmail()) {
   +    return;
   +  }
   +
   

   I feel like this could go wrong in many ways. If we have orders ensuring the email is fresh, let's ditch this hook.

   Checkout causes an order to be saved whenever the step changes, or whenever its even refreshed.

2. +++ b/modules/order/src/Entity/Order.php
   @@ -677,9 +677,14 @@ class Order extends CommerceContentEntityBase implements OrderInterface {
   +    if ($customer->isAuthenticated()) {
   +      if (!$this->getEmail() ||
   +        // Keep the order email updated for draft orders.
   +        ($this->getEmail() != $customer->getEmail() && $this->getState()->getId() === 'draft')) {
   +        $this->setEmail($customer->getEmail());
   +      }
   

   We could move this to a refresh to ensure it's always up to date. But I think draft orders get saved enough that it'll catch user email changes.

Test failure:

1) Drupal\Tests\commerce_promotion\Kernel\Entity\CouponTest::testAvailability
Failed asserting that false is true.

I bet this email update sync shows a test with bad data, that's why it failed.

So what about this instead?

The only potential problem I see with this is potentially reverting an intentional change made to the email address (e.g if a checkout pane allows explicitly specifying an email address for example)...

Better with the patch. The other problem I see with this approach is that until the order is refreshed, the order email is potentially wrong.

The other problem I see with this approach is that until the order is refreshed, the order email is potentially wrong.

Yeah. The only time I could see an issue is if the admin placed the order for the customer. Otherwise, the order refreshes pretty often when a customer is using it. Like every checkout step save.

So, are we good with this approach?

In the absence of feedback, committed the fix.

I removed patch #28 and updated Drupal commerce (that now includes the fix in #39) but commerce recurring draft orders are not updated if the user changes their email. Patch #28 was working for me though but I cannot use it anymore as I updated Drupal commerce.

Please see the issue already created here: #3200326: Updating email in Drupal user account doesn't update email in completed orders details