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.
The new job class blends code from the BackorderJob and the
CompleteBackorderJob for the specific case of adjusting quantities after
an order has been cancelled.
I would like to write a more general class which can be used for any
order amendmends but this was the quickest solution to cater for
currently running pilots.
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
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.
Added layer of security, we encrypt the API key and related secret.
It requires setting up some encryption keys that can be generated wiht
`bin/rails db:encryption:init`
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.
We have only one stock location and that has the default set to false.
Now we can simplify code.
The mentioned Bugsnag notification has not been found. The stock item is
always present in this case but it doesn't hurt to guard against it with
`&.`.
Although the change fix the issue in the back office scenario, it has
the side effect of getting the order total out of sync. Updating a
payment adjustment need to be followed by udpating the order total and
payment amount to keep everything in sync.
