🚀 New extension:

solidus_friendly_promotions

is hitting its first Release Candidate. This gem replaces Solidus' promotion system and switches out the promotion application algorithms. It's somewhat invasive, but it has a number of neat features that core Solidus does not and cannot have (for backwards compatibility reasons): • Shipping Rate Discounts (to preview what discounts you will get if you choose a particular shipping method) • Stackable adjustments (allows distributing a flat amount safely on already discounted line items) • Free items / Goodies (buy one, get one free type things) • No more zero-amount adjustments • No more ineligible adjustments • Ability to use calculators for shipment discounts • Readable and understandable code • Migration path for historical promotions, order_promotions, and adjustments including optimized SQL migrations for all databases • New admin UI We've heavily tested it on our store, and will be deploying very soon. One of the goals was to research which extension points are necessary for switching out all of the promotion system in core, and I want to specifically thank @kennyadsl, @Jared Norman and Adam from SuperGood Software, and @tvdeyen for reviewing my PRs. Another thank you goes out to @elia for helping me get started with the extension and (especially) the sandbox. We've tried to be very thorough with testing this extension, and hope for very few bugs and inconsistencies. While we stop supporting a lot of the existing API for promotions, almost every sensible promotion rule or action should be easily portable. There's a migration guide as well. I would LOVE reports on how hard it is for y'all to integrate this in your stores. https://github.com/friendlycart/solidus_friendly_promotions https://rubygems.org/gems/solidus_friendly_promotions

Thanks for sharing @mamhoff, we look forward for this to be the default in Solidus! 😄

Oooh this is cool!

Very cool!

Cant wait to test this in our stores. Great work @mamhoff Thank you for your ongoing effort in making Solidus better even in hard to understand code paths.

We are now live with the release candidate. Check out www.candlescience.com, there's a free sample you can choose that will yield a promotion, and if you try ordering a very large amount of stuff you'll find an interesting selection of shipping previews and adjustments. You know you don't actually have to order stuff to see it in action.

Nice BFCM strategy!

BCFM?

I just converted our bundled items promotion in under 30 minutes. It's now lots of faster and easier to maintain. Call me impressed.

That's awesome. I'm not sure I'll end up with time to check it out properly before I head to RubyConf, but this looks very promising.

Nice, you singled out the one thing that took us the longest to figure out. 🙂

Hi, I'm testing this out. Looks nicer than the old system! A couple of beginner questions: • What is the meaning of the "Should also apply to line items" checkbox? (pic 1) • What is the meaning of "Quantity per applicable line item quantity" (pic 2)

The product rule can apply to the order ("does the order contain the product?"). If that returns true, a line item action will discount all line items in the order. If the checkmark is set, however, only line items matching the rule are discounted.

Very cool! We worked with @Connor Ferguson, @kennyadsl, and @Nacho Abad for promotion customizations and were even meaning to find a way to show shipping discounts. There's a bit of overlap here, but we also covered a few other areas related to stacking. I haven't checked this out too deeply, but I wonder if these ideas would fit into the extension points you had in mind too. Our main focus was stackability. However, stacking rules and ordering required a few more knobs, especially for % off adjustments on a running total, where order makes a big difference. We mainly cover: 1. Stackable (can this apply to the same item at the same time as other promotions, within a given category?) 2. Orderable (some promotions need to be applied first and the following ones will be applied on the running total) 3. Categorizable (categories used as independent ordered stacking contexts)

The features you're describing are covered.

The lane sounds similar to category/context idea we were using, which has some coarse ordering. However, from https://github.com/friendlycart/solidus_friendly_promotions/commit/b85a1b78a92d5156aa3f4af9122304b1e7ec5b37, it sounds like you were not thinking that each individual promotion would have an order. Within a lane, can you control the order in which promotions are applied, and decide whether certain promotions are allowed to be stacked (within the lane and for a specific applicable)?

True: Promotions within a lane will conflict (biggest discount wins). You can add as many lanes as you feel useful, but my impression is that customers will not understand their discounts if you do too much stacking. So, no: no way of controlling the order in which promotions are applied within a lane. What's the use case?

We want precise control over what can be stacked and order. Although our stacking contexts have their own ordering like lanes, the most used behavior is the promotion ordering AND stackable flag within each context. Imagine just a single context. By default (no rules), we have a 25% off sale. However, in some scenarios, you may want promotions to combine before order after the 25% off is applied to an item. If the user has $10 off code, you could allow that to be stacked with the 25% off, and then you may decide if you want that to run before or after the 25% off since the calculation will differ based on the running total. However, there's also a 50% off code. Since that's such a big deal, you don't want it to be combinable, so you put that in the same context, make it non-stackable, and put it first. Now, when somebody applies the 50% off code, no other promotions within that context can be applied to that discountable. It's definitely a power user capability with some foot guns and management challenges though. As you've probably imagined, having ordering between hundreds of promotions in a single context, does become hard to reason about. This also mirrors existing capabilities we have from another system, so having the all the options makes migration simpler.

Right, I think I get what you want. How do you implement the admin UX for ordering of promotions per context? Is there public code? Of course, ordering is easy on the db level, but hard to do once you have hundreds of promotions.

There's just a position field added for each promotion (and each category too), so they'll be 1, 2, 3, ... By default, we'll just add a new one to the last position, or you can pick a number, which will then shuffle everything down. You can also drag and drop to reorder in the list. Code isn't public currently, but that part at least is pretty straightforward. Each promotion gets a stackable boolean, a category/context, and the position. As you said, the ordering for db and code isn't too bad, but the human factor becomes hard with hundreds. A helpful power user feature would be a rule playground / simulator, with the ability to save test cases and scenarios in the UI. Basically unit testing for the user. Mistakes are inevitable with hundreds of promotions.

I think this is not a good default set features, as some of these features can get really complex very quickly. However,

solidus_friendy_promotions

does offer a few features this can help with, and can likely be a good base to implement it. What do you think about meeting about this in the new year sometime? We're really looking at several challenges with this gem: Can we get it to be Solidus' default? Does it offer the right abstractions and extension points for features like the above? @kennyadsl what do you think, how can we move forward here?

Sure thing @mamhoff, I’m available anytime to discuss that. With the UI revamp in progress, this might be a good moment so that we don’t have to restyle both promotions systems but only the new one. Who wants to stick to the legacy one can use the old UI. In terms of feature complexity, along with @jon_wu, we tried hard to start with something simpler but the marketing department of the company pushed even harder for these requirements to be respected exactly as described since the initial version.