Discountable amounts by adjustments #6371
Draft
+961
−187
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
changelog:solidus_core
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6371 +/- ##
==========================================
+ Coverage 89.45% 89.47% +0.01%
==========================================
Files 974 979 +5
Lines 20322 20412 +90
==========================================
+ Hits 18179 18263 +84
- Misses 2143 2149 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
tvdeyen
reviewed
Nov 17, 2025
| it " will not create the adjustment" do | ||
| expect { | ||
| subject | ||
| order.save! |
Member
There was a problem hiding this comment.
We only want to check for amount zero and marked for destruction here and not save the order.
promotions/app/models/concerns/solidus_promotions/discountable.rb
Outdated
Show resolved
Hide resolved
promotions/app/models/concerns/solidus_promotions/discountable.rb
Outdated
Show resolved
Hide resolved
This was referenced Nov 17, 2025
mamhoff
force-pushed
the
discountable-amounts-by-adjustments
branch
from
5f2c828 to
fc5b38b
Compare
This was referenced Nov 20, 2025
Similar to the work in solidusio#6360, this improves the DSL for creating benefits. Rather than having to define one method that cares for applicability to a discountable, we now simply define that a benefit `#can_discount?` an object if its public interface has `#discount_{discountable_type}` defined. This does not change the implementation of the different methods, but that will come when we refactor the promotion system to use a single system of record for discounts. Then, different objects will need different discount records (line items and shipment use adjustments, but shipping rates use shipping rate discounts etc.). I'm not doing the work for adding deprecation warnings here, as this code was never meant to be overridden up to now. Also fixes some AI slop in the docs.
Instead, follow the deprecation message's instructions.
In the unlikely case people have used these modules, warn if they are included.
This allows setting the current promotion lane to the current thread, and run computations with the current promotion lane set. This is useful for calculating what the discounted amount of a promotable is within e.g. the `default` lane even if there are adjustments for the `post` lane. I'm using `Thread.current` here because we don't always have an order to store the current lane on.
This will return the lanes that came before the current lane. Useful for finding the discountable amount by lane.
This can be used to select all adjustments of an adjustable - a line item or shipment - that are associated to a promotion benefit by lanes. This is useful for getting the current discountable amount programmatically, as will be seen in upcoming commits.
This can be used to calculate the current discountable amount while calculating promotions.
When we call order.reset_discounts, we don't want to deal with those that are currently valid/eligible during promotion recalulcation, we want all discounts to be zero. We could destroy them, but zeroing them is more efficient, because it's likely that an adjustment might not change during adjustment recalculation, in which case we don't need to destroy and re-create.
We want the individual benefits to issue exactly the kind of object that
will discount it, so we need to make some adjustments:
- Dynamically call a discount_#{discountable_type} method
- Create the right kind of discount object per discountable type in
those methods
- Always test the compute_* methods simulating a calculation process
This way we can have a single source of truth for what's being discounted.
Also removes the now-unnecessary `PersistDiscountedOrder` class.
Calculators now rely on `discountable_amount`, which goes back to `previous_lane_discounts`. We need to stub it, because using the SolidusPromotions::Promotion.within_lane helper will reset it (often during spec setup).
mamhoff
force-pushed
the
discountable-amounts-by-adjustments
branch
from
fc5b38b to
bd24d6b
Compare
github-actions
bot
removed
the
changelog:solidus_core
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR changes the new promotion system to calculate discounts entirely via adjustments rather than using in-memory
ItemDiscountobjects.The advantage of this approach is that it allows to a) calculate discountable amounts for line items outside of the
DiscountOrderloop. This is useful for calculating discounted prices, a feature I have on the roadmap. It specifically covers needs like the one addressed in this commit. This way, we have one system of record, not two.The other advantage is that we can remove the pretty complex
PersistDiscountedOrdercode, and just rely onorder.save!to do the right thing.It also dovetails nicely with the work on the in-memory order updater.
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: