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.
I couldn't fix it easily. But I also think that the testing approach had
low value here.
It raised:
```
Failures:
1) Map map can load does not show alert
Failure/Error:
assert_raises(Capybara::ModalNotFound) do
accept_alert { visit '/map' }
end
Minitest::Assertion:
Capybara::ModalNotFound expected but nothing was raised.
[Screenshot Image]: /home/runner/work/openfoodnetwork/openfoodnetwork/tmp/capybara/screenshots/failures_r_spec_example_groups_map_map_can_load_does_not_show_alert_64.png
# ./spec/system/consumer/map_spec.rb:11:in `block (3 levels) in <top (required)>'
# ./spec/system/support/cuprite_setup.rb:39:in `block (2 levels) in <top (required)>'
# ./spec/base_spec_helper.rb:153:in `block (3 levels) in <main>'
# ./spec/base_spec_helper.rb:153:in `block (2 levels) in <main>'
```
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 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.
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.
