Needs review
Project:
Commerce Core
Version:
3.x-dev
Component:
Promotions
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
1 Nov 2018 at 16:25 UTC
Updated:
8 Jul 2025 at 14:44 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
oleksiyComment #3
kristiaanvandeneyndeHere's a reroll
Comment #4
kristiaanvandeneyndeOkay, that went green so here is with updated tests.
Comment #6
kristiaanvandeneyndeRefinements up for discussion:
Will fix the single failure shortly.
Comment #7
kristiaanvandeneyndeThis fixes the test failure. Could use some input on the 2 points raised in #6
Comment #8
kristiaanvandeneyndeThe entity reference to the (in)compatible promotions should not be translatable... (IMO)
Comment #9
bojanz commentedUpdating title.
Lisa had a good comment in https://www.drupal.org/project/commerce/issues/2762997#comment-12342017:
Comment #10
tonytheferg commentedCould this patch include an option to require the criteria of selected discounts rather than merely allowing compatibility? This is a concept I'm chewing on for complex promotions.Comment #11
kristiaanvandeneyndeReroll, haven't taken #9 into account yet.
Comment #12
gge commentedHi,
Just tried to apply #11 to a Commerce 8.x-2.20 site. The patched applied correctly but when trying to run update.php got this:
Drupal\Core\Entity\Sql\SqlContentEntityStorageException: Table information not available for the 'compatibility_promotions' field. in Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldTableName() (line 391 of core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).Thanks.
Comment #13
andriy khomych commentedRerolled #11 patch for the last dev commerce version:
Comment #14
andriy khomych commentedRerolled #11 patch for the 8.x-2.21.0 version:
Comment #15
artem rudnitskiy commentedHi everyone, I have issue related to missing this new promotion compatibility strategies. I have promotion with 'Not with any other promotions' compatibility strategy. When I added coupon to the cart in the edit form, the first time it added correctly. But the next time when I'm trying to apply any non-coupon related changes, while saving the order, the promotion condition rejected the already added coupon due
to promotion compatibility strategy. Looks like the condition 'Only with the selected promotions' will solve the problem. So it will be grate to see this update in nearest module version if it possible.
Comment #16
flocondetoilePatch #14 reroll against commerce 2.27. I change the number of the hook_update_N() after the last committed in -dev. I wonder how we can manage this kind of hook_update_N() in a patch, because if used on a project, then the next hook_update_N() could not be played because already done with this patch.
Comment #17
flocondetoileLittle fix added about the promotion form (put the new field into the compatibilty details group).
Comment #18
dd_leo commentedPatch #17 is not relevant in Commerce version 2.28.
The problem mentioned in the #16 comment arose.
I changed the hook_update_N () number.
Comment #19
jsacksick commentedAny chance to get a patch that applies?
Comment #20
nathaniel commentedreroll
Comment #22
rgnyldz commentedPatch seems to apply without any issue bu nothing happens when I click on "Only with the selected promotions" or "Any promotion except the selected promotions"
I'm on drupal 10.0.1, commerce 2.32 and php8.1
Edit: Add log message
Comment #23
rgnyldz commentedMy mistake, I did not run db update and cleared cache.
Comment #24
rgnyldz commentedI also have an edge case for you :)
I created a content type called Campaigns so the admins can create a page containing the promotion information and display it on a page with a reference field to promotions. So they have to only work on one page for all the info like promotion itself and images, descriptions etc.
But inside the node edit page the radio buttons inside the inline entity form(simple) do not work. I presume that the patch is specific for the promotion edit page ?
Comment #25
zaporylieIt seems to me like this patch won't work with coupons as the coupon validation constraint calls Promotion::applies() and that happens after the promotion preprocess removes all the promotion adjustments and before the processor adds them back.
Disclaimer - I didn't test that theory but working on something similar now so wanted to chime in.
Comment #26
bceyssenspatch #20 seems to work for us with latest 2.x dev version.
Comment #27
nicolas bouteille commentedHello,
We have the same need than what was described on #9
For Black Friday, we want to offer -50% on all products, but also -70% on some categories.
Our clients need to be able to buy a product at -50% and another at -70% in the same cart / order.
It looks like as described in #9, in Commerce right now, when a promotion in incompatible with another one, it means they cannot be used in the same cart / order at all, even though they don't affect the same product. Which I think is too bad :/
I was actually surprised to discover this is the behavior so far.
Since Lisa's idea has been posted 6 years ago, then reposted on #9 4 years ago, I can only imagine this requires a lot of work and will not be available anytime soon… but can I suggest that this idea be at least mentioned in the description / roadmap of this issue?
Also, in the mean time, could you advise me on how you would implement my current need?
I was thinking about adding a custom plugin to be able to exclude specific products or taxonomies.
That way, I could create -50% on all products except one category, and another promo -70% on this specific category. Marking both promo compatible so that they can be both used at the same time but making sure on my end that they cannot affect one same product.
That makes me think that somebody has probably already created this kind of excluding plugin?
Thanks for your help.
Nicolas
Comment #28
nicolas bouteille commentedOk just some follow up, here's how I managed to create a new condition to exclude some products (I will do the same for categories)
I just created a new plugin OrderItemExcludeProduct that extends OrderItemProduct and only overrides the evaluate() function to negate it:
I also took care of displaying a huge warning to make sure the person creating the promotion also adds another condition such as Specific product category AND selects 'Condition operator' : 'All conditions must pass'. If not, the consequence will be : the promotion will be applied on any product not excluded here, even if it does not match the other condition(s)...
By the way, the default value for Condition operator is 'Only one condition must pass' but shouldn't it say 'At least one condition must pass'?
I just tested this and it does not break if I have more than one condition passing...
Comment #29
derekw commentedPatch no longer applies to 3.0.2
Comment #30
flocondetoilechanged version
Comment #31
flocondetoilepatch rerolled against 3.1.0 version
Comment #32
flocondetoileFor those who need the patch without the hook_update_N, as me who run this patch since 4 years (I implements the update_N in a custom module to not break other futur hook_update_N of the module), here it is.
PS: this patch is only for being added in some custom projects's composer.json
Comment #33
jsacksick commented@flocondetoile: Can we get an MR? So we can see if the tests are passing/failing?
Comment #35
jsacksick commentedI opened an MR with the patch from #31.
Comment #36
jsacksick commentedI'm curious, this patch was never RTBCED, @flocondetoile: Have you been encountering any issue in the projects where this has been applied?
I also think there are some use cases that won't work properly (due to how coupons are applied for example).
Comment #37
flocondetoileI ran this patch since 4 years without issues. But I didn't have use case with coupons. I used it to make promotions incompatibles with others, without any coupons behavior associated with them.
Comment #38
derekw commentedI did have trouble using this patch when a coupon was applied and both were targeted at order items. When the coupon was applied no other discounts were applied even if they were applicable. Fortunately the coupon use was a rare case for us. Otherwise the patch worked.
Instead of using the Compatibility with other promotions feature I added custom conditions to evaluate order item product variation attributes for determining promotion applicability, and that was adequate to deconflict promotions.