Promotion activation

[stem]

Hey there,

I know there is discussion about adding ability to replace the promotion system, but I wanted to discuss the current architecture if it is there to stay.

From what I understand, and please, correct me if I'm wrong, when a line item is added to the cart or has its quantity updated, the PromotionHandler::Cart is activated with the affected line item.
Then, it loops through all active promotions, even the ones that are not currently associated to the order if they are automatically applied, and perform all needed actions.

Once again, as I understand it, the CreateItemAdjustmentAction is the only default action which work on a line item level. But it does not use the line item passed inside the payload it receive, and instead loops on all items associated with the order.

So the big questions : why do we have to pass a line item to the PromotionHandler::Cart object ? Can we avoid the loop and work directly the the line item in the payload ?

I'm asking 'cause we have created a service object to add multiple line items at once, and we're hitting a big performance block inside the cart handler. To talk with numbers :

• we have 300k+ variants
• we currently have 86 active promotions, each one with a few variants associated but mostly, variants are not on sale
• if I add 11 products at once to a newly created and empty cart, I end up activating 946 promotions (each one of them for each line item, so 86 * 11), which turns to ~10k calls to Spree::Promotion#line_item_actionable? (some promotions are not using CreateItemAdjustement, so 80 promotions * 11 newly added line items * 11 line items in the cart in this case)

And that's for an empty cart!
The same modification on an existing cart with 10 other products (the average cart size on our shop is ~25) would call Spree::Promotion#line_item_actionable? ~18k

Another way we can go is by not activating promotions for each line item, but only once for the order, but I don't know if there is any side effect to know about.
That would drastically decrease the work it has to do, but will still be a O(N) according to the cart size, which is way worst than the O(1) we would have if the CreateItemAdjustment could work on the newly added or updated line item only.

What do you think about all this? Are we walking to dead end trying to add multiple product at once? Is it possible to use the payload's line item inside CreateItemAdjustment ?

[kennyadsl]

So the big questions : why do we have to pass a line item to the PromotionHandler::Cart object ? Can we avoid the loop and work directly the the line item in the payload ?

I don't know the answer TBH, but I'd make an attempt to change the code and see if specs fail. I hope this helps us identify potential issues hidden somewhere in the promotions code. If everything is green, I think we can work on a PR for this.

[hrdchz]

@stem You may find this useful. We had a need for promotions that could invalidate / remove from the order. This was a long time ago when I tried to find this out. #3644

But if I remember, it looked like all promotions get activated, then the result of the promotion is based on the validity of the adjustment. "Line item rules" are checked for validity, but as best I can tell, there are no line item rules, so the promotions always apply. We modified the cart handler to not check line item rules and all tests were green except:

https://github.com/solidusio/solidus/blob/master/core/spec/models/spree/promotion_handler/cart_spec.rb#L125

This is expecting 2 active promos, for the line item and order, but we remove the line item. Changing that from 2 to 1, all specs pass.

IDK if this will reduce your trips to the db, but maybe?

[hrdchz]

Another thing to consider: both OrderContents#update_cart and OrderContents#after_add_or_remove have a PromotionHandler::Cart.new, although the after_add_or_remove version includes the line item. I'm guessing that could be removed? The outcome of including the line item just means that all promotions get activated, since a line item will never have any rules and Promotion#eligible_rules will always return [] as a result.

[hrdchz]

hm I did a quick check and that does break a number of specs. Don't have time to dig into it today.

EDIT: Right the reason for that should be obvious, they are for different scenarios: updating vs creating a cart / new line item.

[stem]

I have a working solution (at least on my use case and in production).
I'll try to make a PR from what I've done and see what happens with solidus spec suite 😅

[hrdchz]

oh good. I'll keep an eye out. I still haven't had a chance to do a proper PR on my solution.

[mtomov]

Hi,

when you say

I know there is discussion about adding ability to replace the promotion system, but I wanted to discuss the current architecture if it is there to stay.

do you have any links to those discussions?

We at Lawbite are building a brand new Rails app, which will need promotion & credits functionality that overlaps to 90% what Solidus promotion engine has on offer. I wonder if you were me, how would you go about building it? Do you know of any gems built solely for that purpose, or good examples ?

Thank you!

[mtomov]

Thanks @stem !

I'm interested in the current one, but as we're not an e-commerce store, I'm planning to use the design of the promotion system as built in Solidus to create our own. If we find generic enough pattern, happy to open source it as a rails engine. I've started to explore the implementation at voucherify.io to see if they might have arrived at a few better ideas.

[ikbenben1976]

@mtomov did you end up figuring out something with voucherify? We are embarking on building out our rewards program and were going to use either solidus' promotions engine or voucherify's very flexible approach.

[mtomov]

Hey @ikbenben1976 ,

We created our own "promotion engine" with inspiration from Solidus's one, i.e. you have Rules and Actions that are tied to a Promotion. We stored the "applied promotions" in a table (like Solidus's Adjustment table). Then the complicated logic was to create this single entrypoint for the promotions engline - something like PromotionApplicator#apply that would run through all applied promotions + all active promotions, and update the "applied promotions" table along with the respective values for the calculated discounts.

I think Solidus also has different actions - like shipping discount, whole order discount and line item discount - we kept it to line item discount only, as whole order discount could be trickier to calculate tax, etc with.

Let me know if more questions.

[ikbenben1976]

@mtomov, so the team has made quite some progress within Solidus itself creating campaigns and like yourself, tying into Solidus' "promotions engine". One area where we've got stuck is our rewards program has points that Users can exchange for free products; free products creates an issue with the creation of shipments. Did you have this issue as well and if so, do you have any suggestions on how to solve it? Currently, the team is just applying a discount that reduces the cost of the product to $1.00; however, this is not desirable.

[mtomov]

@ikbenben1976 , our project was a legal services marketplace, so we didn't have to deal with shipments.

I'd imagine that in this case, one would create an Action to deal with "points exchanged for free products". I find it a bit strange that those points don't convert to monetary amount in some way (and not free products), but that's probably your business requirement.

I'd look into the Spree's CreateLineItems which I think matches rather closely your use case. The key I think is to store the free line items in a separate table as they do: has_many :promotion_action_line_items. This might need to be paired with a 100% discount on this "free" item (just as your team are already doing with the discount to $1.00).