Fixes an issue where the LineItem :sorted_by_name_and_unit_value scope was not working with removal of the default scopes on line item and variant, which meant that the join in the scope was excluding soft-deleted items that should not have been excluded.
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 observed invalid payment states in Bugsnag but we don't actually know
in which state the payment intent was in. From the context we can guess
that it was "succeeded" but it would be good to validate this. And in
the future it would be good to know if there are other invalid states we
can end up in.
The notification to Bugsnag happens in another part of the code.
Fixes:
Spree::Preferences::Preferable persisted preferables requires a valid id but returns default values
Failure/Error:
class CreatePrefTest < ActiveRecord::Migration
def self.up
create_table :pref_tests do |t|
t.string :col
end
end
def self.down
drop_table :pref_tests
end
StandardError:
Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:
class CreatePrefTest < ActiveRecord::Migration[4.2]
# ./spec/models/spree/preferences/preferable_spec.rb:225:in `block (3 levels) in <top (required)>'
For some reason the order objects were stale here when calling order.update! from either a payment or shipment callback, which was overwriting those states as nil on the order.
This new class lets us [Branch by
abstraction](https://www.martinfowler.com/bliki/BranchByAbstraction.html)
by encapsulating an order's balance. As a result, that's the only place
where we need to check the feature toggle, instead of every place where
`#outstanding_balance` is called (quite some). That would be very hard
to review and it'd be more likely to introduce bugs.
What I like about this is that we also managed to group together the
data and logic that we had spread in a few places and have it nicely
encapsulated. So, where we had a number, we'll now have an object.
Once we fully change all `#outstanding_balance` consumers to use this
new abstraction we'll be able to remove the methods this class replaces.
These are: `Spree::Order#outstanding_balance?`,
`Spree::Order#display_oustanding_balance` and
`OrderHelper.outstanding_balance_label`.
This is just the first step. I'll follow this up with a PR per
page/mailer/whatever where we use the balance to replace it with an
instance of `OrderBalance`. That is, splitting up what I explored in
https://github.com/openfoodfoundation/openfoodnetwork/pull/6959 but in
very small and manageable pieces.
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. 🔥
