We currently have promotion conditions, but other entity types (payment gateways, shipping methods) need it as well, so we need to move them into the base commerce module. We also want to make sure they're completely divorced from core conditions.
We looked into core conditions and how both core and rules use them, and decided that we don't want to use Context, since it imposes a DX penalty and doesn't match our use case (where we always have a single entity provided, while the configuration form does the rest, unlike rules where every setting is a context). Having our own plugin type will also help us build the custom condition UI for which we're wrapping up the design.
Comments
Comment #2
bojanz CreditAttribution: bojanz at Centarro commentedComment #3
bojanz CreditAttribution: bojanz at Centarro commentedWrapping this up today.
Comment #5
bojanz CreditAttribution: bojanz at Centarro commentedIncludes several bug fixes as well:
- Promotion::applies() was accidentally OR-ing the conditions
- OrderTotalPrice crashed if the given order did not have the same currency as the condition
- PluginSelect was passing wrong configurations on plugin change, causing orphaned keys on plugin change
- Various lacking test coverage that's now complete
And includes an OrderItemQuantity condition.
Note that the OrderTotalPrice's plugin ID will be fixed in #2885398: Remove the commerce_promotion_ prefix from condition and offer plugin IDs.