The best practise we have been promoting is that the fulfilment event is "order paid in full".
However, our order conversion / account creation rules only run on "checkout complete", which most often comes after "order paid in full".
This means that at the time of fulfilment the order owner might not be known yet, which makes it impossible to open a recurring order, for example.

The solution is to run 'commerce_checkout_order_convert' and 'commerce_checkout_new_account' on "order paid in full" as well.

Comments

bojanz’s picture

bojanz CreditAttribution: bojanz commented

This is what I committed to commerce_license_billing:

function commerce_license_billing_default_rules_configuration_alter(&$configs) {
  // The order account rules run at commerce_checkout_complete, which is usually
  // after commerce_payment_order_paid_in_full. This means that if the checkout
  // was anonymous, a recurring order can't be opened because the order owner
  // is not yet known. Until this is fixed in Commerce, this module needs to
  // ensure that these rules run at commerce_payment_order_paid_in_full as well.
  $configuration_names = array(
    'commerce_checkout_order_convert',
    'commerce_checkout_new_account',
  );

  foreach ($configuration_names as $configuration_name) {
    if (isset($configs[$configuration_name])) {
      $configs[$configuration_name]->event('commerce_payment_order_paid_in_full');
    }
  }
}

commerce_payment should implement a similar alter hook.

rszrama’s picture

rszrama CreditAttribution: rszrama commented
Title: The Paid in full event can't always be used for anonymous checkout » Process anonymous checkout rules "When an order is first paid in full"
Category: Bug report » Feature request
Priority: Major » Normal

If I may, I'm going to retitle this and make it an open question; the idea is to process our anonymous checkout related rules (new account creation or assignment of orders to existing accounts) either "When an order is first paid in full" or when "Completing the checkout process." I don't think this would cause duplicate account creation attempts, but it's worth checking to ensure when these events are fired synchronously Rules isn't preserving an older version of the order without a uid set.

Can we think of any drawbacks to this idea? Order statuses being changed such that a checkout URL is no longer valid could be one.

bojanz’s picture

bojanz CreditAttribution: bojanz commented

We definitely want to process on both events because we don't know which will fire first.
Both of them check that order:uid is 0 first, so they shouldn't be able to interfere with each other.
Our dear order locking prevents any synchronous changes.

mr.andrey’s picture

mr.andrey CreditAttribution: mr.andrey commented

Could this prevent a License from assigning a role?

I've noticed an odd issue on a client's site. When an order is created through a regular checkout process, the license is created and activated and the person is assigned the proper role. When it is created through a recurring order, however, the license is created and activated, but the role is never assigned.

It would make sense that if the event "commerce_payment_order_paid_in_full" is triggered on an anonymous order, it won't assign the role because it doesn't have access to the uid at the time of execution.

Any ideas around this issue?

UPDATE: In my case, the issue was likely the previous License expiration overriding the current active license. There's a patch for this:
https://www.drupal.org/node/2577655