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.
Otherwise we would try to take stock from the producer stock level
without respecting their on-demand settings. So from now on:
If stock level or on_demand are set on the override then it's not using
producer stock levels.
We allowed this for producer stock and need to do the same for inventory
stock. This will allow us to create backorders for missing, but promised
stock.
We weren't bothering with stock when items were on demand anyway. But we
want to track stock now so that we can backorder more when local stock
levels become negative.
During checkout, stock is adjusted when a shipment is finalised. The
chain is:
* Order state change to complete.
* Trigger Order#finalize! which updates shipments.
* Trigger Shipment#finalize! which adjusts stock on the variant.
* A variant holds stock in stock items or in a variant override.
The spec was asserting on all shipments of the order but there were one.
In consequence, the spec didn't assert anything. Now I set up a shipment
that is asserted on. I'm stil not sure how useful this spec is though.
- increments! & decrement! skip validations
- replaced increment! method calls
- one call was for a redefined increment! method
- the other for a regular(ActiveRecord::Persistence)
- removes increments/decrements definition now useless
