Introduce SolidusPromotions #5805

If we don't do this, and an in-memory order is calculated twice, we run the risk of wrong amounts. This is usually guarded against by calling `order.reset_current_discounts` in the `FriendlyPromotionDiscounter`, but the spec for the `AdjustLineItemQuantityGroups` action creates an order (calling `recalculate`) and then calls `compute_amount` with the stale discounts still on the order's line items. Anyways - After persisting adjustments, we can drop the current discounts.

We need to have the new action available, and we need it to have a partial.

The previous version did not work for an action whose name does not end in either `LineItem` or `Shipment`. Luckily we now have the `:level` method.

Easy upgrades are good!

We've refactored `call` out of the subject, but this PR did not know about that.

We have several actions, and several calculators. Not all calculators work for all actions (e.g. the DistributedAmountCalculator really only works for the AdjustLineItem action, and the `Tiered` ones don't work for `AdjustLineItemQuantityGroups`. Rather than creating a new configuration option for each calculator, let's use something like a Hash here.

This is to allow us to release versions in a simple, standard-compliant fashion.

This changes the API of the main class we're working with from `SolidusFriendlyPromotions::OrderDiscounter` to `SolidusFriendlyPromotions::FriendlyPromotionsAdjuster`. This class now simply calls the three other (otherwise somewhat confusingly named) service objects: - `LoadPromotions` - `DiscountOrder` - `PersistDiscountedOrder` This makes the code easier to read in my opinion, and simplifies the API for promotion handlers significantly.

When we test whether a promotion is eligible, what we do is we perform a dry run of the promotion adjuster. This change reflects that context in the naming of our arguments.

This is to aid readability.

This class suffered of unnecessary variables, and can also live with the service classes for the FriendlyPromotionAdjuster. It also could use a spec.

These are modules, and Rails offers a place for modules.

This class is useful for satisfying Solidus' need for a shipping promotion handler. With SolidusFriendlyPromotions, shipping promotions are handled just like other promotions, so we don't need to do anything here.

We want to have an action that creates a new discounted line item. Its discount should never be affected by promotions in previous lanes.

We want to be able to add a line item associated to a promotion actions (to see who created it).

This also introduced the `SolidusFriendlyPromotion::Actions::Automation` module that indicates this action is an automation. It's only available at the order level.

Solidus offers line item comparison hooks, and we'll make use of them.

This is not done automatically in Solidus, so we have to do it here.

Automatic items are probably already 100% discounted, and it's really hard to make their discounts play well with others.

StandardRb has added a new Cop.

Small typo

We want to see at a glance what the lanes of our promotions are.

It's quite slow to calculate usage counts. Let's instead display an infinity symbol for promotions that don't have a usage limit.

When a promotion has no usage limit, we can still tell admins whether a promotion has been used at all. Counting one is not so hard.

This does not set a default filter, so we can still see all promotions, but it's real easy to set the filter to today.

This way the column makes more sense in the admin.

The long one takes away a lot of row space.

Solidus 2.4 introduced a new admin navbar with new icons that can be enabled in the settings. Adopt to that.

Promotion Rules are not ordered, so the database might return them in any order. This adjusts the spec accordingly (especially Postgres returns them in a different order than expected sometimes).

There are now three spots in this code base that need a method to collect the line items that pass all applicable rules for an order and can be discounted. Time to extract.

When we do a buy-one-get-one-free promotion, you should get TWO free when you buy two. Ruby doesn't really allow changing methods based on who calls, so we have to use the `quantity_setter` attr_accessor as a kind of lock that unlocks setting the quantity when we want it.

There's two quantities we want to configure. Buy X get Y free...

Without the description, the calculator name might not tell you enough about how the calculator works. This is especially true for the tiered calculcators.

So you get a percentage based on how many items that match the criteria the customer has in their cart!

The default promotion adjuster has been renamed, and that has to be reflected in the README and in the migration guide.

We want user's to take advantage of semantic versioning.

This adds a documentation section so people know they have to change explicit references to the legacy system's promotion handler.

New standard version, new rules, new fixes.

This gem allows recalculating complete orders until they are shipped, because Solidus allows changing an order's contents until the order is shipped. This change adds a configuration option that disables the recalculation of orders after they are completed. Some shops make changes to existing promotions, and expect that this does not change complete, but unshipped orders.

In Rails 7.1.3, the `table_name_prefix` method is redefined if it is not already defined. Since we have multiple module definitions, we need to make sure that the class method is defined before we load `engine.rb`.

This reverts commit 6a69d1a35340b650fec1040da8184b4ec59964f1.

This was somehow missed in the past. Fixes solidusio#93

This fixes the foreign key constraint error when deleting a promotion code that has been applied to an order. This will, of course, change the applicability of the promotion in question for that particular order. If the order is shipped, no worries though: The adjustments will stay as our service object will not try to recalculate. If the order is not shipped, the promotion will stop being applied. However, if you as a user deleted the promotion or the promotion code, that's probably what you want. Fixes solidusio#94

Let's use the `discard` gem for soft-deleting promotions.

There are still a few bugs with the new admin, so let's disable that for the time being.

We don't want to allow people to edit or re-create deleted promotions, so we just indicate they're there for now. Let's see if we find a need to show them in some kind of uneditable mode.

When a promotion has been applied to an order, we need to make sure no adjustments remain that have that promotion's actions as their source. For incomplete orders, we can simply delete the adjustments, but for complete orders, we must stop the promotion action from being deleted.

We now protect against destroying promotion actions that have been applied to a complete order, so we can stop the dependent: :nullify thing.

There's no need for soft-delete on promotion actions, now that we have soft-delete on promotions.

We don't need soft-delete on promotion actions when we have soft-delete on promotions.

We were using Spree helpers before; those don't exist anymore. Also we missed importing the PromotionsHelper, and implicitly relied on the one provided by Solidus.

In some spots we were still relying on Solidus partials, even though we have them in the app.

Previously, the activation UI for promotions was based on complicated Javascript. This change allows us all the same options, and the user will be warned by validation errors if they try to create a promotion with both a code and the apply automatically option set. For existing promotions, `apply_automatically` will be disabled if either a path is set or a promo code is set.

This got by undetected because the spec was using the wrong model name.

If this promotion is activated by a path, it makes sense to be able to change it.

SQLite 2.0 has recently been released, but the Rails/Solidus ecosystem isn't quite there yet.

Promotion actions are not soft-deletable anymore.

3.0 restricts us to an older Rails version which uses Selenium the wrong way.

This used outdated syntax that did not actually work, and the spec indicated invalidity because of the promotion with ID = 1 not existing. Now we create a real promotion to test with, and we add the error in the correct way. As a bonus, we use I18n for the error message.

The spec setup of this spec added two rules of the same type to a promotion. Because the uniqueness validation was flawed, this was not a problem previously. We're now adding a different type of line item rule here. The behavior of the spec stays mostly the same, but the error message changes (because the `LineItemTaxon` rule does not have super-nice errors).

Associate promotion rules with their conditions It's easier to understand if we have multiple promotion actions that each have multiple promotion rules, than if we have multiple promotion actions that share a set of promotion rules on the promotion, some of which are relevant to the promo action and some which are not.

This will be covered by directly associating rules to actions.

Interestingly, these specs are still green.

Also fix the error message to reference the action. Promotions can now have the same rule twice!

Solidus Backend already initializes the pickers, if we do it a second time, an error occurs.

This large commit removes a lot of complexity by scoping rules to actions. Now, we do not have to distinguish between rules that apply for all actions and rules that are scoped to only some actions, and it's far more understandable how a rule comes to be.

This is to create the API needed for fulfilling the contract described in solidusio#5739.

Again, this is to fulfil the API requirements specified in solidusio#5739.

... also rename all the partials.

A rule is conceptually conditions attached to an action. In this gem, hoever, what we call "rules" are just conditions. This renames them appropriately.

This reads much better than `admin/conditions/conditions`.

Promotion Action is very generic and wordy. Just using "Action" does not work, because Rails will confuse it with its own concept of "Action". This changes the routes and params, and moves the individual promotion action forms to a benefit_forms directory.

It's clearer, and does not conflict with a lot of Rails nomenclature.

This file has not been in use.

These checks are not necessary any longer.

Not sure why this had to be updated.

Not all conditions work for all benefits. Validating this helps us with the UI, and it exposes some odd things in the spec suite.

We don't have the CSS from the classic promotions admin - but that CSS wasn't all that great to begin with. However, we do have Bootstrap and can make full use of it.

Much easier than having to initialize manually.

This isn't quite working yet.

We want to have some friction here, and communicate clearly there's no benefits or conditions.

We also wrap selecttwo in a Web Component, because it's just so good.

Use form-group everywhere.

This form was almost unintelligible before this change.

This should be a number field, and it's the most important calculator anyways.

Explicit is better than implicit.

Calculators are their own model, and we can just move them one level up, shortening some view references.

When applying or validating an order_promotion, we load all associated promotions and check their usage limit. A discarded promotion can still be associated with an order. If we do not load discarded promotions, then the order_promotion will not have an associated promotion and checking usage limits will result in an error.

When we delete a promotion, we want to be sure that dependent order promotions are also deleted.

This is an additional safeguard that makes sure orders do not get discarded promotions applied to their carts (by removing any manual connections through e.g. promotion codes).

Promotion Actions have been renamed to Benefits, and Promotion Rules to Conditions. This needs to be reflected in the README.

Solidus' promotion configuration interface changes a bit in 4.4, and with SolidusFriendlyPromotions 2.0 we want to adapt those changes.

We don't need to provide our own implementation any longer, Solidus ships with it!

Solidus has a new configuration endpoint for the promotions order adjuster class. Implement it.

This is not needed any longer, as this method is only implemented in solidus_legacy_promotions.

This is present in Solidus core, identically.

This allows the API feature spec to go through.

This is necessary for the API promotion endpoint to work.

We don't need to override Spree::Adjustment.promotion and Spree::Adjustment#promotion?

This will reset the connected order promotions when an order is emptied.

3.3.3 has weird issues, see https://stackoverflow.com/questions/78617432/strange-bundle-update-issue-disappearing-net-pop-0-1-2-dependency

Almost all of our specs don't use the RSpec DSL at the top level. This adds `RSpec.` to the ones that do.

This was relying on Solidus Legacy Promotions' permission set to be present, and it was testing the backend configuration with the redirect.

Spree::PromotionCodeBatchBuilder is from another gem.

We have no ApplicationJob.

With the initializer, we need a full Rails app to test the presence of the default classes. By leveraging `add_class_set` and `add_nested_class_set` from Solidus core with their `default` option, we don't need to do as much in the initializer.

Without this, we get version conflicts (but our code works with both 1.4 and 2.x)

We don't need ActionCable, and it's not loaded in our test suite. This stops Turbo from autoloading channels that need it. We don't need it.

This updates the `MIGRATING.md` file to reflect the current state of the gem.

This is the first step in making this gem independent of solidus_backend.

We don't depend on solidus_backend, and stores should be able to load the extension even if they don't use the backend.

Admin conflicts with the name for solidus_admin tests that will be coming up.

This mirrors what is done in Solidus core, and is cleaner anyways.

This is more in-line with the core Solidus gems, and it is also a lot faster.

Without this before the DummyApp call, we don't get the migrations and models from `solidus_legacy_promotions` that we need.

This loads the SolidusAdmin gem if available, and adds the routes to the Dummy App if the example in question is marked `solidus_admin`. In addition, this loads the accessibility matchers many of the admin specs need.

This allows the new Solidus Admin to display Adjustments with a source of type `SolidusFriendlyPromotions::Benefit`.

This was referencing a factory from solidus_legacy_promotions

This is all that's implemented in core currently.

With solidusio@10b555b merged, we don't need this override anymore, and our build should go green again.

This was an oversight.

This is still mentioning actions when we mean to say benefits.

If this is a vanilla install, we cannot make a foreign key constraint to the `spree_promotions` table as it is not present.

In case we don't have the legacy promotion system present, we can't sync things by default.

This way we keep our specs clear of the legacy_promotions gem, but we provide a way of syncing that is visible.

Solidus still supports Rails 7.0, and we should, too.

Adjustment#eligible defaults to true, and we never set it to false. It's a remnant of the legacy promotion system. I'm also changing the spec setup of those specs that indicate ineligible promotion adjustments from setting the eligible flag to false to setting the promotion up with an impossible condition instead.

This association is not used anywhere in the codebase, and it's probably a remnant of adjustments being directly associated with promotion codes. SolidusLegacyPromotions does this, but we have no need for this, because we can just as well join via the `friendly_order_promotions` table. An adjustment from a promotion with codes will have one of the promotion benefits as a source, and an order_promotion with a reference to the promotion code used. I could have also changed the association to one that follows this path, but I'm really not sure what we would use this association for.

In friendlycart/solidus_friendly_promotions#130, we changed the default of SolidusFriendlyPromotions.config.sync_order_promotions, but failed to adjust this spec accordingly.

In friendlycart/solidus_friendly_promotions#128 we renamed the config option `actions` to `benefits`, but failed to include that renaming in the benefits controller.

In our test suite, we need to have solidus_legacy_promotions loaded. This gem sets the `Spree::Config.order_contents_class` to the legacy `Spree::OrderContents`, but we need `SimpleOrderContents` so we don't run into the legacy promotion system.

Otherwise we don't load solidus_legacy_promotions, and its migrations don't run.

This spec was failing before because the sync option was not set.

This mirrors the setup in Solidus core, and in Solidus Legacy Promotions.

Solidus core does not depend on solidus_dev_support, so we should not either.

As preparation for the solidus integration, we don't need to create tables and then rename them. Let's rather have them the right name from the get-go.

This has the same effect and removes a rubocop issue.

In the new solidus_promotions gem, we need some way of distinguishing factories and associations from the legacy_promotion ones. In `solidus_friendly_promotions`, that prefix was `friendly_`, in `solidus_promotions`, it's `solidus_`.

It's not needed, we have SolidusPromotions::TestingSupport::FactoryBot.

This will always be available, and users should not configure it.

If we have this gem loaded, we definitely want it to be visible. We also want the menu items to be tested.

The else case here cannot be reached (I tried), and the case statement is repeated in the method below.

This does not make any difference but gives better stats.

All of these have no preferences, but associations, and therefore need to be updateable.

Also fix the spec name so it actually runs.

This reflects better what it does.

This looked a bit garbled without these extra w-100s.

Solidus Core now ships with a Null promotion handler.

We'll just be using Spree.solidus_version instead, like all the other gems.

This is to indicate clearly that this JS is used for the backend UI.

…tion This rename is for consistency only.

This allows developers to more clearly see what they need to do in order to implement custom promotion benefits.

This should give developers better hints as to how to use this gem.

As pointed out in https://github.com/solidusio/solidus/pull/5383/files#r1391519251, the new promotion code batch builder had worse performance characteristics than the one in the legacy promotion system. This gets the characteristics back to those of the legacy promotion system. Time spent and memory usage still go up significantly and linearly with the number of batches. I ran some specs with the following code: ```rb context "with a very large number of promotion codes" do let(:number_of_codes) { 10000 } it "creates the correct number of codes" do puts Benchmark.measure { subject.build_promotion_codes } expect(promotion.codes.size).to eq(number_of_codes) end end ``` With a 1000 codes, I measured: ``` Randomized with seed 49097 1.036322 0.028977 1.065299 ( 1.074396) ``` With 10000 codes, I measured: ``` Randomized with seed 33250 9.606364 0.278920 9.885284 ( 9.978242) ``` Memory usage went up linearly as well.

Much of this code has been lifted from some tax abstraction in core, and some of the comments had not been updated.

With the removal of our own .rubocop.yml, a few new linting problems appeared.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce SolidusPromotions #5805

Introduce SolidusPromotions #5805

Commits on Oct 25, 2024