For payment that complete during the checkout (Paypal, Stripe) the
amount was recorded twice against `order.payment_total`. This is because
the `payment_total` gets updated in an afer_save Payment callback when a
payment is completed, and then once more when we process payment in
`Spree::Order#process_each_payment`.
This is an existing issue on master, but it was hidden by the
`update_shipping_fees!` callback, it trigerred an update of the order's
total, which then updated `order.payment_total` with the correct value.
Now that we removed the callback, the bug showed up.
Note, I updated the stripe specs for consistency even though they are
currently disabled.
It should be handled in the controller, it's currently handled in
`Spree::OrderContents#remove`. As long as we don't manually remove line
item from an order we should be good.
Currently it gets trigerred each time the order is saved, which seems to
happen mutiple time when we finalize an order. It's a bit useless to
recalculated the fees over and over
Context, it was added here : 217eda8362
`Spree::OrderContents#update_or_create` is used to update the cart when
on the /shop page. If you start an order and proceed to the "Order
summary" step, and then decide to update your order by using the shop
link next to the cart, such update wouldn't update the shipment.
This result in the order page in the backoffice displaying the wrong data,
and more importantly, in the stock not being updated.
So now we ensure shipment will be updated, which result in the checkout
flow being restarted, thus making sure the shipment is updated.
A Vine voucher is really a specific type of FlatRate voucher but because
a Vine voucher can be used by mutiple enterprise, it can be considered
different enough to warrant it's own class.
It still share a lot of the behaviour of a FlatRate voucher, so to avoid
duplication, all the shared functionality have been moved to a
Vouchers::FlatRatable concern.
- As per the new changes, unit_type change will create a new product rather than give errors.
- on bulk-update screen as well, two products can have same name with different unit_type
The original Spree code allow for a tax adjustment to be considered a
refund in a specific scenario:
- instance is using inclusive tax
- instance that applies different tax rate in different tax zones
This scenario should not happen with how our instances are configured
More info: https://github.com/openfoodfoundation/openfoodnetwork/pull/6565#discussion_r566535431
There is no easy way to make the original product invalid, but we can
make sure the cloned product will be invalid. The cloned product add
"COPe OF " in front of the product's name, so by starting with a name
that's long enough, the cloned product will have a name longer that 255
char and will then be invalid.
I disabled Metrics/AbcSize for ensure_standard_variant as I don't think
that's hard to understand the code. And utimately it will be removed
once product actually becomes optional.
Spree::Price parsing was returning 0.0 when given a an empty string as
price, resulting in a variant being valid even if no price was given. It
only happened if `Spree::LocalizedNumber` wasn't used.
Spree::LocalizedNumber` return nil if given a blank number.
The VINE Api require a secret and an API key to be used. The secret is
used to sign the request. The secret is linked to the API key so we need
to store it along side the key.
