Total per customer at the coupon level is ignored for unknown customers

Committed.

@agoradesign: Yes, this behavior is inconsistent with how the promotion setting works. And it doesn't really make sense to allow a coupon that has a limit per customer to be applied if the customer is anonymous. That is a bug to me.

From a customer perspective, this is horrible though. As a consequence, I'd say, I won't show the coupon redemption form at all on the cart page in future projects anymore and wouldn't recommend this at all

Well, that is only if you specify a usage limit per customer? Why would you specify a limit that you allow to be bypassed?

It seems this behavior was implemented on purpose (See https://www.drupal.org/project/commerce/issues/2902495#comment-12847063).

However, I'm currently working on a headless site where customers are able to checkout as anonymous and we get the order email from the Payment gateway AFTER the order is placed, which means coupons that are limited per customer can be applied and they won't get "revoked" since the order is already placed.

Perhaps we need another setting to make this configurable... Perhaps I should consider reverting this until we gather more feedback from the community as this can be somehow considered as a "breaking change".

Not sure what's the best way to go with this.

After considering this a bit more, decided to revert the change until we actually figure out a new setting that basically controls whether or not anonymous users are skipping the "total per customer" limit.

We probably should add this setting at both the promotion & the coupon level.

@rszrama: I've been discussing this today with one of our customers, and I'm not really sure how we should proceed with this because:

• If we change the label of the current setting to "Total uses per email address", it suddenly becomes inconsistent with the methods (getters/setters) as well as the field name ("usage_limit_customer"), but maybe we could live with that? (Getter is getCustomerUsageLimit())
• If we go with that additional setting "Skip the limit check"... this basically means that we're going to potentially update hundreds of thousands of coupons (potentially even millions), to set this to TRUE by default. (Core has support for that via the setInitialValue() method, but not really sure how scalable it is, just afraid that the update could hang.
• We could probably come up with alternative wording, and have the setting defaults to FALSE instead? So you'd have to check it to change the current behavior. In this case, we could go with "Evaluate the limit for known customers only" (Then we go back to "customer", which is a nebulous concept like you pointed out.

Thoughts?

he clarified how the checkbox is really independent of a particular kind of usage limit.

Well, actually, that's not entirely true.... the code does the following:

    // If there are no usage limits, the coupon is available.
    if (!$usage_limit && !$usage_limit_customer) {
      return TRUE;
    }

    if ($usage_limit_customer) {
      $email = $order->getEmail();
      if ($email && $usage_limit_customer <= $usage->loadByCoupon($this, $email)) {
        return FALSE;
      }
    }

    return TRUE;

Which means, if no usage limit is configured, the coupon is available. ANd then, only if a usage limit per customer is configured and the order email is known, we evaluate the limit.

Not really sure if this means we need to come back to this again, or if we can still go with what we agreed upon.

This is probably because the email isn't being set on the order when the apply coupon button is pressed. It is available within CouponRedemption::validateInlineForm() as $form_state->getValue('contact_information').

This would be an improvement, sure, but this would only work if the pane is actually filled.

I'm fairly confused by this issue. It seems we've got reverted commits, but the issue summary isn't clear about what's going on.

What's unclear about what's initially described? The coupon customer usage limit is being ignored, when the order email isn't known, while the promotion usage limit is, evaluated (i.e if a customer usage limit is set at the promotion level, and the email isn't known, the promotion isn't going to apply).

@erom: Your patch seems to be addressing a different issue. This patch was about fixing the behavior for anonymous users which are able to use a coupon that have a customer usage limit.

For example, you set the "total per customer" field to 1 but the customer is anonymous, the limit is bypassed (ie the coupon applies).

I haven't tried to reproduce the issue your patch is attempting to solve, but this should be reported in a different issue.