-
-
Notifications
You must be signed in to change notification settings - Fork 730
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
Vouchers part 1 #11002
Vouchers part 1 #11002
Conversation
This should be done at the model level
9eeed29
to
202b004
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.
Nice. Looking great! ✨
@@ -46,7 +46,6 @@ | |||
= yield | |||
|
|||
#footer | |||
%loading |
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.
Nice.
@@ -57,7 +57,7 @@ | |||
|
|||
it "updates fees and taxes and redirects to order details page" do | |||
expect(order).to receive(:recreate_all_fees!) | |||
expect(order).to receive(:create_tax_charge!) | |||
expect(order).to receive(:create_tax_charge!).at_least :once |
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.
So now it's called multiple times? I would have thought that the transition happens only once.
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 puzzled over this a bit, but it looks like this happens in relation to what the test setup is doing as opposed to what happens in the test itself. Basically before the test even starts (or when the order object is called and lazy-instantiated) the process of created a completed order (:completed_order_with_totals
) is running through various bits of logic in a sequence like adding line items and creating shipments and setting the shipping address, etc etc, and some of that is doing things that are triggering tax-related callbacks because the order total is changing or the tax address is changing?
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.
Looks good 👍
@@ -204,6 +203,7 @@ def shipping_method_ship_address_not_required? | |||
|
|||
def process_voucher | |||
if add_voucher | |||
VoucherAdjustmentsService.calculate(@order) |
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.
As long as taxes don't change after this it should be fine. If I followed correctly taxes are recalculated if address changes, and also after the order move to the "payment" step, which all happen before we can reach this code, is that correct ?
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.
Great, looks good to me too! I have a suggestion for bonus points though ;)
@@ -1114,11 +1114,8 @@ | |||
let(:voucher) { create(:voucher, code: 'some_code', enterprise: distributor, amount: 6) } | |||
|
|||
before do | |||
# Add voucher to the order |
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.
These comments might seem superfluous to some, but as a first-time reader of the code, I find them a helpful narration :)
Ok, someone needs to help me out here.
In summary I can't find anything that's not working - but I also didn't see any changes at all. So maybe we are good to merge this. Or please provide some more details for testing, @Matt-Yorkley. Or do you have any insights, @filipefurtad0? Thanks! |
Correct
The code that takes care of that has been moved around, but it is expected to work as before. So If you didn't find anything broken that means we are all good.
I am not sure about this one. |
@Matt-Yorkley can you clarify this ? see Konrad question above
|
That's right 👌
Hmmm that's strange, I thought there was an option to set the value of Anyway, I think we can merge? |
What? Why?
Addresses a couple of things related to checkout processing and vouchers. This was previously combined with some other changes, but I've split them into two smaller chunks so it's easier to review. This is part one.
Partially fixes #10857, should be fully fixed by the next PR (#11003).
Review notes
Hopefully the commits are pretty well explained by their names but here's some extra notes:
Removed an Angular loading indicator which in some cases was causing the screen to be blocked with a dark background and little loading animation in cases where it shouldn't be there, mostly on the order completed page. This was previously used by Angular but isn't needed any more.
The customer details controller was doing a weird thing where it was handling applying taxes on admin adjustments, but that shouldn't be the responsibility of that controller, so its moved out to
#create_tax_charge!
where all other tax handling is done.Handling of the issue where taxes on an order need to be recalculated if the order's address changes was being done solely by the customer details controller and that's now done at the model level, because it should apply to any context and not just that one controller.
Taxes on enterprise fees don't get applied until the order is at least in
payment
state, eg it's passedcart
,address
, anddelivery
states. This is in line with how all tax handling works since split checkout was introduced.The way that re-calculating voucher amounts based on the order total was being handled was a bit off in certain cases where a voucher was already present, as it was using the order amount with discounts applied instead of the order amount before discounts. Eg: if the order total is 20 and a voucher for -5 is present and the order total changes to 22, when recalculating the voucher amount it should be using the pre-discount total of 22 and not the discounted total of 22 - 5 (17) when making calculations.
What should we test?
If an order has progressed to at least
payment
state then submitting a change to it's address should recalculate tax correctly if the change of address would change it's tax category. Note: which address gets used for tax purposes depends on an admin configuration setting.Some of the issues outlined in [Vouchers] Errors when/from iterating between /summary and /cart page #10857 around errors when recalculating a voucher amount on an order should be resolved but maybe it's best to test that along with the next PR Vouchers part 2 #11003 (and it's still behind a feature toggle here)?
Release notes
Changelog Category: Technical changes
The title of the pull request will be included in the release notes.