Not getting order notification e-mails - Checkout completion action not triggered?

The checkout completion trigger is being pulled; I just verified that on the Livetest.

Hi!

I'm using D6.13 & UC-RC2.

I have just noticed that, when I submit order in the review order form it redirect to checkout completed page. In that checkout completed page I'm getting an error message "Unable to send e-mail. Please contact the site admin, if the problem persists.", but I'm receiving the order completion emails.

Any help on this issue!

Order status is also not updating once the payment received through paypal.

L.C.

Hi!

Got the spot, I just saw the recent logs in the reports.

I got two errors over there! One is type:ca message: "Attempt to e-mail invoice for order 22 to failed." and
an other one is type: mail Message: "Error sending e-mail (from abcprabhu@gmail.com to )."

Order invoice notification failed due to bug in this function:

<?php
function uc_order_action_email_invoice($order, $settings) {
  $language = user_preferred_language($account);

  // Token replacements for the subject and body
  $settings['replacements'] = array(
    'global' => NULL,
    'order' => $order,
  );

  $recipients = array();
  $addresses = token_replace_multiple($settings['addresses'], $settings['replacements']);

  foreach (explode("\n", $addresses) as $address) {
    $recipients[] = trim($address);
  }

  $settings['message'] = uc_order_load_invoice($order, $settings['view'], $settings['template']);

  if (empty($recipients)) {
    watchdog('ca', 'Attempted to e-mail an invoice with no recipient.', array(), WATCHDOG_ERROR);
    return;
  }

  foreach ($recipients as $email) {
    $sent = drupal_mail('uc_order', 'action-mail', $email, $language, $settings, empty($settings['from']) ? uc_store_email_from() : $settings['from']);

    if (!$sent['result']) {
      watchdog('ca', 'Attempt to e-mail invoice for order @order_id to @email failed.', array('@email' => $email, '@order_id' => $order->order_id), WATCHDOG_ERROR);
    }
  }
}
?>

The $email variable is empty!

So... did you set your store e-mail in your store's contact settings?

Hey I really forgot to update store's contact settings!

Ref: http://www.ubercart.org/docs/user/313/store_settings

Thanks for your message. Problem solved, now I'm getting the order notification mails.

Regards,
Prabhu.C

Hi,

I think bloke_zero's problem and abcprabhu problem are different issues. I've been setting up ubercart with worldpay on a site and discovered an issue with how the worldpay server requests the completion page and ubercart. I have documented this here: http://www.ubercart.org/forum/bug_reports/12159/uc_cart_complete_sale_or... and http://drupal.org/node/506286 but as the issue would appear to be with uc_cart_complete_sale perhaps I should be raising the issue here.

Why uc_checkout_complete does not fire properly for worldpay
It's because of the way RBS Worldpay's callback mechanism works. Worldpay's server requests the completion page from your site. Their server generates the request and not the user's browser so Drupal does not have access to the correct $user. This breaks the logic in the uc_cart_complete_sale function - specifically the line

  ca_pull_trigger('uc_checkout_complete', $order, $user->uid == 0 ? $account : $user);

As $user->uid does equal 0 but $account as not been set because $order->uid is not 0. Therefore a null is passed in where a drupal user account should be.

A possible solution
Edit the part of the function that deals with existing account...

  if ($order->uid == 0) {
    //.... leave all the stuff for anonymous user's alone
  }
  else {
    //If the order is not anonymous but the $user is anon load up the order's uid - this probably from a RBS worldpay callback
    if ($user->uid == 0){
      
      $account = user_load(array('uid' => $order->uid));
      $message_type = 'logged_in';
    }
    else {
      if ($order->uid == $user->uid) {
        $message_type = 'logged_in';
      }
      else {
        $message_type = 'existing_user';
      }
    }
  }

Forgot to re-open this bug report as bloke_zero's bug was due to the issue explained in #13 and abcprabhu's issue was unrelated.

OK, I see what you're saying. Makes a lot of sense. Here's a patch to test, because I don't have a worldpay account, and I probably can't duplicate the problem.

I'm not sure why the Worldpay module can't address this itself? Presumably you can build the page callback that Worldpay requests a completion page from however you want. It shouldn't be directed to cart/checkout/complete but should have its own completion callback that can load whatever user is necessary. I'll have to think about any other implications this patch from Lyle might have, and a fix in Worldpay would seem preferable at this point.

I thought about suggesting a fix in uc_worldpay but what I don't understand is how the same issue doesn't occur for the paypal payment module when it processes an IPN.

I checked the paypal code to make sure that worldpay had missed anything obvious... and couldn't see anything.

Correct me if I'm wrong but as far as I can see...

1. Paypal IPN's are processed by the anonymous user as the request comes from the paypal server (like the worldpay callback mechanism)
2. To process an IPN the function uc_paypal_ipn() in uc_paypal_pages.inc is called
3. The $user variable is not manipulated
4. The if the IPN is for a completed payment the function calls uc_cart_complete_sale() and $order->uid will not equal zero but $user->uid will
5. Therefore $account will be null and the trigger uc_checkout_complete will be called with a null user object because $user->uid does equal 0

  ca_pull_trigger('uc_checkout_complete', $order, $user->uid == 0 ? $account : $user);

The function will be called but nothing is done with the return value, i.e. the checkout completion message. The message is displayed when a user is returned to the Ubercart checkout completion page from PayPal. The IPN is used as a verification of payment in the event that that fails. I've done at least half a dozen redirected payment services and have never run into a limitation in the way checkout works now. That's not to say it shouldn't be updated, but at the same time if we can avoid altering it until 3.x-dev, that would be preferable.

The problem is that when ca_pull_trigger('uc_checkout_complete', $order, $user->uid == 0 ? $account : $user); is fired with a null for the $account variable the payment is not updated correctly (if the item is non-shippable it is not set to complete) and the invoice email is not sent out.

I see. I'll consider that, and looking at the code, I don't see any obvious reason why this would cause a problem. I'm trying to decide if it would be more problematic for the Worldpay module to simply add global $user = user_load(array('uid' => $order->uid)); to its logic on the callback.

I couldn't see any obvious reason either but I'm not an expert in ubercart conditional actions :).

Something's stopping ca_pull_trigger('uc_checkout_complete', $order, $user->uid == 0 ? $account : $user); from doing the expected actions and it seems to be related to the null value passed in. I don't have a handy test site linked to a paypal sandbox but I'm sure if you didn't return to the ubercart checkout completion page for a non-shippable product the expected actions wouldn't happen when the completion IPN is sent.

As for fixing it in the worldpay module I'm not sure that loading the global $user with a valid user without the user logging in is a good idea... it could present a security risk as the global will be set by an anonymous session without any user entering their password.

Tomorrow I'll set if I can find out with the expected actions aren't happening when a null's pass in.

I think I've found out why the 'uc_checkout_complete' trigger is not being fired correctly.

I set up a test environment without any payment gateway (paypal, worldpay) and hacked the uc_cart_complete_sale() to always pass an empty variable for the $account variable. Here's what I found out.

When ca_parse_trigger_args() is called in ca_pull_trigger() it returns a false as the second null argument fails the test

    // Check the type and fail if it is incorrect.
    if (gettype($arg) != $entities[$value['#entity']]['#type']) {
      return FALSE;
    }

and the ca_parse_trigger_args() returns false and therefore ca_pull_trigger doesn't continue and just returns FALSE too. So none of the actions that should take place (possible sending an invoice email and marking the order complete) occur.

Therefore in order for the trigger to fire correctly a valid user object has to be passed in and as shown by the worldpay experience it is possible to call uc_cart_complete_sale() and it not pass in such an object. (The condition is when $order->uid > 0 and $user->uid == 0). I believe (but have not tested) that the same thing would occur for the paypal payment module when it processes a completion IPN.

I think that the patch in #16 makes a reasonable assumption - if the order has a uid > 0 and the user is the anonymous user then the trigger should be pulled with the order->uid's user object as the second argument.

subscribing

@rszrama or @Island Usurper - I was wondering if you'd had any more thoughts regarding this issue - especially given the results of my testing reported on #23

I'm still not sure why PayPal IPN doesn't have this problem. Anyway, I think this patch might be better or easier to understand.

Some third party gateways will tap the return URL before the user is redirected to it.

IE, when the transaction is completed, the gateway requests the return URL directly, AND redirects the user to the same return URL.

This can cause issues where the site allows anonymous purchases and creates accounts on order completion. The automatic login will be assigned to the request which creates the account, but that means that the automated request initiated by the payment gateway is logged in, and the anonymous user remains logged out.

I don't see how this would prevent the email being sent, but after discussion with rszrama on IRC I figured it might be worth flagging this in case the two are related.

Here. You take this one, Ryan.

Hmm... not sure if Lyle's latest patch is working. I just patched a local site and then checked out anonymously with a new e-mail address. No e-mail was sent to the new user. : (

Aha! Spam folder to the rescue! It did in fact work for me with authenticated checkout and anonymous checkout for both a pre-existing and new account. Now the only thing to test is PayPal WPS redirect...

Ok, all tested out ok for me. Committing.

Suh-weet. My real question would be to test this along with File Downloads... ;)

Just to confirm (and for Google juice) we've been getting the same issue with Paypal IPN. uc_paypal calls uc_cart_complete_sale , which fires the uc_checkout_complete hook as described above. I've just gone through all the steps alexpott etc. went through, but for uc_paypal ...! But Island Usurper's user_load patch is tidier than mine was, so applying that instead. Nice work.

I'm having the same problem and seeing errors like:

Error sending e-mail (from "XYZ" <info@xyz.com> to ).

The site is using ubercart 6.x-2.2 and SMTP Authentication Support version 6.x-1.0-beta3.

Previously, although these errors were showing up, notification emails were sent out. But, recently the notification emails have stopped being sent out for some reason.

So, I would assume that it is something to do with the SMTP setup? None of it has changed though... weird.

[UPDATE] Only some users are not receiving notifications. I got mine, so that is a separate issue. But, I still see the empty email address problem even though I checked the ubercart code and it seems to have the patch above applied to it. I get 3 errors reported for every order like:

ca - Attempt to e-mail invoice for order 1066 to failed.
mail - Error sending e-mail (from "XYZ" <info@xyz.com> to ).
smtp - Error sending e-mail from info@xyz.com to : You must provide at least one recipient email address.

Anyone have any ideas?

Right now I'm using CSS to hide the error messages on the checkout complete page but would like to get rid of these errors if possible.

Thanks,
Kristen