-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable promotion adjuster #4460
Configurable promotion adjuster #4460
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it! I left a couple of things I think should be changed, though.
Also, can you please provide a real-world example of when someone could use a custom version of this? Not because I don't think there will be, but it will be super useful when writing a how-to for this preference based on a real need.
Thanks Martin! 🙏
0c2e655
to
1c2d9bb
Compare
The Order Updater does many things, and one thing it does only semi-well is recalculating promotion adjustments. Promotion adjustments have an action as a source, but when the action asks its promotion whether it's eligible for a particular promotable (the promotion adjustment's adjustable), the promotion will only ask those promotion rules that are of the `applicable` to the promotable's type. This is not necessarily true for line item promotion adjustments, for example. What this commit does is a first step: Extract the current promotion-related behavior from the order updater. It also extracts the relevant specs from the order updater.
426e078
to
e8b14d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved but if you have time to fix that occurrence of legacy it would be great!
This provides an extension point for adjusting promotions.
The `Spree::Adjustment#recalculate` method is used only for unit cancels and promotions at this point, and it's preferable that this logic is handled inside the Spree::Promotion::OrderAdjustmentsRecalculator. I cannot deprecate `Spree::Adjustment#recalculate` and friends yet, because the unit cancel code still depends on it.
We want to make the contract between the order updater and the promotion adjuster simpler. What this does is move the promo total calculation for both items and the order into the OrderAdjustmentsRecalculator. This restricts the surface area of the contract between order updater and promotion adjuster to JUST the order's and line item's promotion total, which is everything the taxation code needs.
e8b14d4
to
4b5d9f1
Compare
We introduced an extension point for promotion adjustments in solidusio#4460 [1]. We change the expected interface from `#adjust!` to `#call` for consistency, as that's the new standard we want to follow (see solidusio#4677 [2] for an example). That's going to ease the adoption of a service layer if we eventually introduce them. [1] - solidusio#4460 [2] - solidusio#4677
We introduced an extension point for promotion adjustments in solidusio#4460 [1]. We change the expected interface from `#adjust!` to `#call` for consistency, as that's the new standard we want to follow (see solidusio#4677 [2] for an example). That's going to ease the adoption of a service layer if we eventually introduce it. [1] - solidusio#4460 [2] - solidusio#4677
We introduced an extension point for promotion adjustments in solidusio#4460 [1]. We change the expected interface from `#adjust!` to `#call` for consistency, as that's the new standard we want to follow (see solidusio#4677 [2] for an example). That's going to ease the adoption of a service layer if we eventually introduce it. [1] - solidusio#4460 [2] - solidusio#4677
@@ -163,6 +162,7 @@ def update_adjustment_total | |||
order.included_tax_total = all_items.sum(&:included_tax_total) + order_tax_adjustments.select(&:included?).sum(&:amount) | |||
order.additional_tax_total = all_items.sum(&:additional_tax_total) + order_tax_adjustments.reject(&:included?).sum(&:amount) | |||
|
|||
# TODO: Delete this line in Solidus 4.0, when it is run in `update_promotions`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mamhoff while taking a look at this PR again, I notice this line. Is this comment still valid? I think we are already doing this in the update_promotion
method so we can probably already remove this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed with @mamhoff about this, and it is actually valid. People might be calling update_item_promotions
in their own store, which doesn't include this promo_total
calculation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary
This adds an extension point for a configurable promotion adjuster to the app configuration, and uses that extension point to point to a new
Spree::Promotion::LegacyAdjuster
. This LegacyAdjuster does all the things that the order updater in conjunction with the Spree::Adjustment class was doing.Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed (
cross them outif they are not):I have attached screenshots to demo visual changes.I have opened a PR to update the guides.I have updated the readme to account for my changes.