Voucher adjustment have complicated calculation that prevent us from
using Spree::Calculator, and we need to override CalculatedAdjustments
method, so no point using it.
We still keep the same methods to stay as consitent as possible in
regards to adjustments
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.
Add missing, "inverse_of" and "dependent" options. Use :nullify as
for "dependent" because we would want to keep the adjustments on order
even if the voucher is deleted.
At the time when we can apply a voucher to an order (payment step) we
don't have any data on possible taxes and payment fees. These are
calculated when we move to the summary step. So voucher are applied in
two step:
- create an "open" voucher adjustment on the order when a customer enters
a voucher code.
- when we move to the summary step, recalulate the amount and
possible tax for the voucher adjustment, once taxes and payment fees
have been included in the order. And then close the original and update
order to reflect the changes
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.
As part of this PR https://github.com/openfoodfoundation/openfoodnetwork/pull/10329
LocalisedNumber validation was tightened, but that means negative number
were not valid anymore.
This commit has been cherry-picked after this fix has already been
applied. Now we just change the order of characters in the regex because
humans are used to reading the minus at the beginning of the number. But
this change doesn't change the logic at all.
We're now handling these values on the frontend, so can keep this simple.
fixes up:
Add numericality validation for *
Add translation for Active Record error message
The browser is now responsible for dealing with the decimal separator, for all numeric preferences (as input[type=number]; see Spree::Admin::BaseHelper::preference_field_tag). Calculators are the only place that numeric preferences are used.
It will enforce that only one comma or dot (depending on user's locale) is entered, thus avoiding any ambiguity, and mis-interpretation (eg 100,001 could be interpreted as more than 100 thousand or 100 with a decimal place).
