This keeps the `OrderBalance` abstraction but removes the old code now
that the feature is enabled for all users in all instances and there are
no bugs reported. It's become dead code.
Fixes:
Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/models/spree/payment_spec.rb:10:in `block (3 levels) in <top (required)>'.
RuntimeError:
stubbed models are not allowed to access the database - Spree::Product#touch(updated_at,{:time=>2021-04-10 14:24:50 UTC})
This will let us branch by abstraction. All existing calls to
`#outstanding_balance` will go through `OrderBalance` hence, will
check the feature toggle.
Note that by default, `OrderBalance` will end up calling
`#old_outstanding_balance`. As the name states, that's exactly what
`#outstanding_balance` was so far. This means no consumers will see any
change in behavior. We just added on item in the call stack (sort of).
We set this value to `true` unconditionally in an initializer, and then check the value in various places via Spree::Config. It's never false, and it's not configurable, so we can just drop it and remove the related conditionals. 🔥
As is, `payment_total` is only increased after successfully processing
a payment and never updated. This inconsistency breaks
`CustomerWithBalance` which relies on it.
Needless to say that if we keep this denormalized column, we better make
it consistent. I investigated current Spree's master branch (709e686cc0)
and they also realized it was broken. Now `Payment` runs the following
from the `after_save` `update_order` callback.
```rb
order.updater.update_payment_total if completed? || void?
```
I also took the chance to rearrange tests a bit.
The original payment may not be valid because its credit card may be
expired. Stripe gives this as a valid scenario returning a success and
we should do too.
When creating the credit payment we end up validating all sources in
a chain as follows.
```
Payment being persisted -> source payment -> original credit card.
```
The source payment was valid when created (It would not be persisted
otherwise) but its source card may now be expired, and that's legit.
There was also an issue with the `#invalidate_old_payments` callback. It
was causing the original payment to be validated again and thus the
credit payment failed to be persisted due to the original credit card
being expired. Switching this callback to use `#update_column` skips
validations and so we don't validate the source payment. We only care
about the state there, so it should be fine.
Given the importance of this code, it doesn't bring me much confidence.
Apparently, this specs where using a non-existent state by mistake and
this went unnoticed because the payment creation was failing silently in
payment/processing.rb.
This unearthed the fact that our `#ensure_correct_adjustment` needs the
order to be persisted to succeed.
* master: (91 commits)
Bump ddtrace from 0.37.0 to 0.38.0
Add spec to cover SQL query issue with OCs where the only products from the coordinator inventory are renderer
Remove unnecessary order statement, the relation will only be used for counting products
Move select out of scope visible_for because it is breaking exchange_product queries and it's just not needed there. The only other use of this product's scope visible_for is the enterprise serializer so we add the select to it.
Make OC advanced settings work by permitting the extra parameter
Remove conflicting and duplicate route
Bump bugsnag from 6.13.1 to 6.14.0
Make charges update method update the first pending payment
Move require_login_then_redirect_to to the only place where it is called
Make broken spec fail reliably and set it pending
Updating translations for config/locales/en_GB.yml
Update all locales with the latest Transifex translations
Doc defensive coding needed by pin payments
Make method a little simple by extracting method
Simplify spec, the 2 minutes wait is not necessary anylonger
Make unauthorized in ControllerHelpers::Auth the same as in Spree::Admin::BaseController
Move unauthorized view to HomeController only, all other calls to unauthorized will go through Auth which will redirect to the home controller IF the user is logged in or to login if user is not logged in
Adapt specs to the move of unauthorized route from the spree routes to the main app routes
Delete spree_user_signup which is from spree promotions code that we dont use
Remove try_spree_current_user
...
