Promotion weight is not respected if applied via coupon

There has been several issues opened related to this behavior. changing this now would be a BC. Applying coupon based promotions first was done by design afair, I don't completely recall the rationale behing this decision though.

Surely we could do something to provide a backward-compatibility layer? For example
- Create a config that will determine global behavior for when coupon promotions should be applied - change it to TRUE via hook_update, default to FALSE for all new installations
- In order processor collect coupons, and associated promotions
- If the site opt-in for applying coupons first, apply them (same as it is today)
- If the site opt-out from applying coupons, merge them with available promotions and sort based by weight
- Apply all applicable promotions

For the context - this is coming as a request for one of our clients in fashion industry. According to them it's an industry standard to create a coupon-activated promotion that will discount products already affected by another promotion. So for anything that's already discounted they want to have a flash-sale 10% off (or similar) which will apply additional discount on top of already discounted prices. This can be done by setting weights accordingly, but not if promotion is activated via coupon as that voids the promotion weight given all coupon-promotions are applied first.

I am ok with proposing a patch but can't afford spending time on creating one if it will be rejected anyways given there are some reasons for this being handled as it is today.

#3010862-25: Add missing promotion compatibility strategies → is related

This is a common use case in which the store is on sale and a coupon is provided to be applied on top of that. However, because the coupon is always applied first, you unexpectedly provide a larger discount than expected.

The client is perplexed as to why this occurs. To make matters worse, we can't explain why it "has to be this way."

@zaporylie's proposal appears to be very feasible, don't you think, @jsacksick?

I have a different problem regarding the promotion weights of coupon and non-coupon promotions.

You cannot apply a coupon promotion that is not compatible with others, when a non-coupon order already applies to a certain cart - no matter which weights the promotions have.

A concrete example, we have:

• promotion A: weight -1, with coupon
• promotion B: weight 0, no coupon, automatically added at 50,-
• promotion C: weight 1, no coupon, automatically added on having certain brands with a minimum value in the cart

It's no problem, when A and B get combined, also no problem B+C, but A+C should never be allowed. We do not care, if A is applied and B cannot be applied then anymore, but it should always be possible to enter one of the two possible coupon codes.

So, let's assume our cart's total is above 50,- - so B and C get applied automatically.

If we make A compatible with other promotions, we are allowed to enter the coupon code and A gets applied additionally -> but we do not want to allow A+C, so that's a problem.

If we declare A as non-compatible with others, we simply do not have any chance to get the coupon code applied, although it's prioritized first, but unfortunately the automatically added promotions are already applied to the cart, so A loses this battle and won't get applied at all

If coupon promotions are always applied first, why is there the option to set the weight in the first place?

Isn't the point of ordering the weight of the promotions to let the admin decide what they want? or am I missing the point?

I'm not against changing this... We'd probably need to expose this setting in a new UI though and tests coverage...
Also, as far as I remember, whenever I tried merging coupon based promotions with the one returned by loadAvailable(), tests were failing... I think the promotion compatibility doesn't work as expected in this case.

I don't exactly remember, but there was some logic failing...

@zaporylie: Let me know if you're still interested to work on this.

I can take a code out from the client's codebase where I worked on the workaround for the current limitation. I will post it as a patch in the following days. Glad to hear you're open to make this change.

Hi again, I thought I would have time to do this before my family vacation, but I didn't. I am still interested in providing a patch/MR, but that will realistically happen in more than 2 weeks, so if someone else is interested in working on this issue feel free to do so.