Coupon redemption fails for guest checkouts, if order has no email yet

I know this is by design currently and I have no easy solution yet. We could also set this a feature request, of course.
The point is, that for one-/single-page-checkout you always want that on the same page. Also in other cases you often want the coupon redemption form placed in an early step.

So I think Bug is also fine.

That is because you have a usage limit per customer set... This is a tricky problem, on one hand some merchants would like the coupon code to be allowed even if the order email is not, but at the same time they usually don't want the coupon code to be reused by the same customer... I think the solution to that problem is generating unique coupon codes that can be used only once in total.

Related issues #3017503: Allow users to explicitly require customer email for coupon usage → and #3278227: Total per customer at the coupon level is ignored for unknown customers → .

This is probably more like a feature request however, fixing this could lead to bug reports... so... not sure what to do here.

Okay I have an idea how this might be solvable in a good fashion: For that we'd need to store the email address in the order with priority, at least for anonymous checkouts!

Then the other validations might happen without having too specific hacks / workarounds. The email address is something special for guest checkouts, so I think it would be fine logically. The question is, is that acceptable and solvable in code?

The email is set when the pane is submitted, so if it's placed in the same step, this isn't going to work unless the pane is ajaxified.

@jsacksick yes, maybe we could already set it earlier in ContactInformation::validatePaneForm()?

Or maybe the coupon validation could at least get the email value from form state, if not yet saved on the order and set it?

(Just some brainstorming...)

But then you'd need to ajaxify the pane and save the order from there... We're doing this in shipping and getting bug reports every now and then due to race conditions... So I'd suggest you to create your own pane if you'd like to see this fixed faster.

@jsacksick the coupon form is already ajaxified.

I implemented a working POC, which of course is not "the yellow from the egg" :D - just to document in code, what might be an idea.

Risks I see here is for example setting an invalid email address on the order!

It works, if the contact_information is in the same pane as the coupon redemption form - which is the context of this issue. Maybe you'd like to have a look and maybe this is a starting point for improvements or better solutions.

Static patch attached, if someone needs a quickfix / workaround.

I'm sorry but a fix like the one in the patch isn't acceptable as is...
The added logic is making too many assumptions. The contact information pane might not be used or might not be present... This can't go in as is...

@jsacksick yeah that's kind of what I wrote in #12 and didn't set it to "Needs review" for that reason.
It should just write the idea into code and act as basis for feedback to iterate on.

Thanks!