Promotions and LineItem's eligibility

[RyanofWoods]

Overall, the promotion's system is pretty flexible out of the box, thanks to the different models. As a recap:

Promotion handlers are responsible for activating a promotion at the right step of the customer experience.
Promotion rules are responsible for checking whether an order is eligible for a promotion.
Promotion actions are responsible for defining the discount(s) to be applied to eligible orders.
Adjustments are responsible for storing discount information.

However, promotion rules actually do more than they state. They can actually also state whether the promotion adjustments should be made on the promotable (the LineItem in most cases) via actionable?. This breaks their single responsibility as well as makes the Rule less reusable...

Not one model is solely responsible for this logic, so it can end up in a rule, action and or even a calculator. For example, say you want to create an adjustment on the most expensive item:

• a rule would be bad because it makes it less reusable and it also doesn't work well when the promotion has other rules, maybe the most expensive item isn't actionable because of another rule
• an action is better, but what if you sometimes want to filter out types of items. Do you make another action?
• a calculator works well, but there are many standard calculator types (percent, fee, tiered), should 3 new calculators be made?

The most expensive item adjustment is a bit of a special case as other actionable? cases can work nicely with other rules, such as item types, but still it makes the rule less reusable.

I am thinking this logic could be extracted out to a new model for the CreateItemAdjustments Promotion action, perhaps filters or something. They could just use LineItem scopes and/or selects. But note, like above, some filters could clash if you want the most expensive item but also to exclude item types (the most expensive item on the order could be the excluded type).

[elia]

Looking at the code there's also a stream of ifs checking constantly if the actionable/promotable is a LineItem or an Order, which is a big smell in itself and feeds back into the issue you described.

About the problem you describe I'll just say that's yet another manifestation of how the current promotion system could use a replacement.

Maybe we need a pluggable system in which you can swap a promotion system for another one… or maybe a middleware like system in which an order goes through different transformers that will create adjustments… or something else. But it's evident that the current solution only covers well only a handful of cases, a few more can be forced to work in the system, and many others are completely out of its league.

[seand7565]

@RyanofWoods I wrote up a whole post about this before checking here, only to find you beat me to it by two weeks 😆 Pasting my post here - definitely agree with you, and I have a solution that I think makes sense - would love to hear your thoughts on it! (You too, @elia!)

---

TL;DR: Discounting a specific product in an order is kind of weird, and break separation of concerns.

The Problem

---

Assuming the following:
Promotion rules job is to determine eligibility.
Promotion actions job is to determine application.

In theory, once the order is determined to be eligible for the promotion, the promotion rules role should end, and the promotion actions role should start. Most of the time, that's how it works. Consider the following:

Promotion A applies a $10 discount to orders that are over $100. The promotion rule verifies that the order is over $100. The promotion action applies a $10 discount. Simple!

However, if you discount specific products, that's not how it works. In this case, the promotion rules verify eligibility, then the promotion action checks the promotion rules to determine what items it should apply to, then it applies discounts. In other words, the promotion rule is determining both eligibility and has a say in application. Here's the counterpart to the first example:

Promotion B applies a $10 discount to Product A on orders that have Product A. The promotion rule verifies that the order has Product A. The promotion action checks each line item against the promotion rule. The promotion action applies discounts wherever the promotion rules say it should. The promotion rules responsibility - which usually ends at "eligibility" extended in this case to "application".

The Argument

---

I think the original line of thinking was that the promotion rule should determine eligibility for the order, then determine if each line item is eligible. My argument is that when we check the line items, we're already in the "application" phase - the "eligibility" phase has passed, and that's all the rule should be concerned about. Application should solely be the responsibility of the promotion actions.

This causes some issues that I think others have experiences as well - the option value, product, and taxon rules require a lot of insider knowledge to use effectively. You have to know that if you use the product rule with the item adjustment action, that you're creating this promotion:

• Apply $10 ONLY to product A, on orders that contain product A
  and not this promotion:
• Apply $10 to orders that contain product A
  It has been my experience that most people unfamiliar with Solidus expect that rule/action combo to do the latter, not the former.

The Solution?

---

The product, taxon, and option value rules should change from:

• If order contains x, order is eligible. Also, discount will only apply to x.
  to just:
• If order contains x, order is eligible.

With that change, we're losing the ability to apply discounts only to certain products - but that should be the domain of the promotion action anyway, as it deals with application. So, we'll need a way to target products, option values, and/or taxons on the two promotion actions that care about that (create item adjustment + create quantity adjustment). They should change from:

• Check the promotion rules - apply the adjustment only to the items the rule wants us to
  to:
• Apply the adjustments only to provided option values/products/taxon products

With these two changes, application is solely the responsibility of the promotion action, and the promotion rule only deals with eligibility. No more crossed responsibilities! 🎉

[kennyadsl]

Nice writeup @seand7565!

It has been my experience that most people unfamiliar with Solidus expect that rule/action combo to do the latter, not the former.

I would have bet the other way around instead! 😬 But yes, we should provide more clarity, and probably both options.

With your solution implemented, how can we set up a promotion similar to Apply $10 ONLY to product A, on orders that contain product A when people are expecting that version instead? I'm confident there's a way, just wanted to be sure.

[seand7565]

@kennyadsl Thanks! I'm envisioning the same fields that the "products" rule has on the action. So when adding the "line items" action, there will be an additional field where you can add a product. If no products are in that field, it acts in the default manner (applies the discount to all line items). If there is a product in that field, it applies the discount only to those products. So for this promotion: Apply $10 ONLY to product A, on orders that contain product A, previously you'd have to set it up this way:

Products rule, product A selected
Line item action, $10 off

But with this change, you can just set it up like this:

Line item action, $10 off, product A selected

In other words, the promotion is no longer "Apply $10 ONLY to product A, on orders that contain product A" but just "Apply $10 ONLY to product A", since the first requirement (apply only to product A) includes the second requirement (only where order contains product A) - because if product A is not in the order, no discount will be applied in either case.

[seand7565]

It would also allow you to easily do promotions like "Apply $10 ONLY to product A, on orders that contain product B", which AFAIK is either impossible or really hard to set up on the existing system, since checking for the existence of product B using the products rule would prevent you from targeting product A for the discount.

[RyanofWoods]

I think it would be nice if the solution was more flexible and not just specific products. For example, perhaps another abstract class for the action to filter out the LineItems. We then can have subclasses that act as filters to target the necessary items by:

• product;
• colour;
• other custom product attributes.

The latter would be nice for the project I am working on as we have a need to target "subscribed" items. It could also be nice to be able to use multiple filters which will make them more reusable. Without multiple filters, you can imagine an influx of filters like what's occurring for rules:

• all items with specific color;
• most expensive specific color;
• all subscribed items; and
• most expensive subscribed item etc.

(using color and product filters would also mean not having to target every single desired variant!)

Lastly, some stores may want to filter out/exclude items.

---

It's worth noting, some duplication may occur between rules and these filters - targeting how the order should be eligible and how the adjustments should be applied.

---

It would be great if we could get some data about promotion usage from actual stores before designing a solution.