We now check if the shipping method changed before we actually select
it. Fix the related spec.The spec was wrong because order.select_shipping_method
fails silently. That means the shipping method wasn't getting
updated on the order, thus the test was passing.
I though that once the shipping method was set it's available on the
order, but apparently it's not always the case. At least some of the
test scenario have order with no shipment, thus no shipping method set.
We need to recalculate the voucher adjustment(s) in the following
scenarii :
When a voucher as been added to the order and :
* Moving to the payment step from details step, to take into account
potential change in shipment fees. (this happen if we return to the
details step after reaching the summary step)
* Moving to the summary step from payment step, to take into account
payment fees
Some important logic happens after the order transition from one state
to another. In particular, voucher are recalculated. To fix any
inconsistency, we make sure the order is the state matching the checkout
step we are on.
I wrongly assumed that `voucher.create_adjustment` would return nil
if failing to create an adjustment. I will in fact return an
adjustment object with errors.
The voucher apply button is inside form that has another a submit button,
it leads to a weird situation where either one will submit the whole
payments page form. Adding a named parameter on the voucher apply button
means we can distinguish between the two by checking for the presence
of params[:apply_voucher].
Refactor split checkout to use the new controller. But unfortunately
we can't have nested form, so adding a voucher is still handled by
SplitCheckoutController.
The split checkout page uses `mrujs` and `CableCar` to set the form as
a remote one and perform `CableCar` operation if any : https://mrujs.com/how-tos/integrate-cablecar
The previous solution broke the cart handled by angularJS, it looks like
`morpdom` (https://mrujs.com/references/remote-forms-and-links Navigation Adapter section )
was doing something that angularJS didn't like when redirecting to
the current page.
With the power of `CableCar`, we now replace the #voucher-section on the
split checkout page instead of doing a redirect.
The checkout payment step will also show a warning.
The amount used is stored in the adjustment created, so we will be able
to track how much has been used down the line.
If a feature is activated or not depends on the database which is reset
after each test scenario. So enabling a feature doesn't leak into other
scenarios.
Just enabling the feature is less code and more realistic than mocking a
method call.
