Remove benefit "level" mixins #6378
Merged
+328
−38
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
the
changelog:solidus_promotions
mamhoff
force-pushed
the
remove-benefit-modules
branch
3 times, most recently
from
e0420a1 to
20edc22
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6378 +/- ##
==========================================
- Coverage 89.46% 89.46% -0.01%
==========================================
Files 977 977
Lines 20350 20386 +36
==========================================
+ Hits 18207 18238 +31
- Misses 2143 2148 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mamhoff
force-pushed
the
remove-benefit-modules
branch
from
20edc22 to
54f5816
Compare
5 tasks
tvdeyen
force-pushed
the
remove-benefit-modules
branch
from
54f5816 to
aa37ca8
Compare
tvdeyen
approved these changes
Nov 24, 2025
Member
tvdeyen
left a comment
tvdeyen
left a comment
There was a problem hiding this comment.
Great work. Ruby is a meta programming super star.
TIL inherited and method_added.
adammathys
approved these changes
Nov 25, 2025
Member
adammathys
left a comment
adammathys
left a comment
There was a problem hiding this comment.
Looks good, just one small typo.
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.
mamhoff
force-pushed
the
remove-benefit-modules
branch
from
aa37ca8 to
a0ab878
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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 applies the same refactoring that was done in #6360 to benefits, which have a similar API (they only discount when they can discount, the same way conditions only check eligibility if they are applicable).
This work is extracted from #6371. If we get this in earlier, that work gets easier to review.
Note that I have
notgone to the trouble to add deprecation warnings here.If anyone can show me real-world code that has actually created new benefits and that would benefit from a deprecation warning, I'll happily add them.Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: