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.
The user should need to tick only one box to agree.
We don't remember yet if someone agreed to the platform TOS and
therefore the box is always unticked to start with.
Remembering the agreement is another issue:
https://github.com/openfoodfoundation/openfoodnetwork/issues/6328
Checking for `false` instead of a falsey value allows us to distinguish
from an unset variable and disable the checkout button only when a
checkbox is present and unticked.
This was working with the seller's terms but now it includes the
platform's terms as well.
Pending:
- Simplify Ansible code
- Unify the two terms checkboxes if both required
The checkout page shows a checkbox to accept the platform's Terms of
Service. Ticking the box doesn't have any effect yet but at least people
are aware and are presented with a link to the terms.
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. 🔥
This was triggering two separate updates, and each of those updates could trigger callbacks, and those could trigger other callbacks. Here we're doing the same thing, but with one update.
