Fixes:
384) Spree::OrderMailer basic behaviour doesn't aggressively escape double quotes in confirmation body
Failure/Error: adjustments = adjustments.to_a + order.shipment_adjustments.to_a
ActionView::Template::Error:
Cannot have a has_many :through association 'Spree::Order#shipment_adjustments' which goes through 'Spree::Order#shipments' before the through association is defined.
# ./app/helpers/checkout_helper.rb:10:in `checkout_adjustments_for'
# ./app/views/spree/order_mailer/_order_summary.html.haml:43:in `_app_views_spree_order_mailer__order_summary_html_haml__2911251238692323485_70331958934800'
# ./app/views/spree/order_mailer/confirm_email_for_customer.html.haml:23:in `_app_views_spree_order_mailer_confirm_email_for_customer_html_haml__3734564010704881256_70331959518520'
# ./app/mailers/spree/order_mailer.rb:35:in `block in confirm_email_for_customer'
# ./app/mailers/spree/order_mailer.rb:33:in `confirm_email_for_customer'
# ./spec/mailers/order_mailer_spec.rb:20:in `block (3 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# ActiveRecord::HasManyThroughOrderError:
# Cannot have a has_many :through association 'Spree::Order#shipment_adjustments' which goes through 'Spree::Order#shipments' before the through association is defined.
# ./app/helpers/checkout_helper.rb:10:in `checkout_adjustments_for'
Fixes:
259) Spree::ShippingMethod#shipments can gather all the related shipments
Failure/Error: expect(shipping_method.shipments).to include(shipment)
ActiveRecord::HasManyThroughOrderError:
Cannot have a has_many :through association 'Spree::ShippingMethod#shipments' which goes through 'Spree::ShippingMethod#shipping_rates' before the through association is defined.
# ./spec/models/spree/shipping_method_spec.rb:190:in `block (3 levels) in <module:Spree>'
Fixes:
292) OrderManagement::Subscriptions::ProxyOrderSyncer#sync! when the subscription is not persisted and the schedule includes upcoming oc that closes after ends_at does not create a new proxy order for that oc
Failure/Error: order_cycle.schedules << schedule
ActiveRecord::HasManyThroughOrderError:
Cannot have a has_many :through association 'OrderCycle#schedules' which goes through 'OrderCycle#order_cycle_schedules' before the through association is defined.
# ./spec/factories.rb:29:in `block (4 levels) in <top (required)>'
# ./spec/factories.rb:28:in `each'
# ./spec/factories.rb:28:in `block (3 levels) in <top (required)>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:59:in `block (4 levels) in <module:Subscriptions>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:65:in `block (4 levels) in <module:Subscriptions>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:133:in `block (6 levels) in <module:Subscriptions>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:133:in `block (5 levels) in <module:Subscriptions>'
Failure/Error: enterprise.andand.touch
ActiveRecord::ActiveRecordError:
cannot touch on a new or destroyed record object. Consider using persisted?, new_record?, or destroyed? before touching
# ./app/models/spree/address.rb:155:in `touch_enterprise'
# ./spec/factories/product_factory.rb:12:in `block (3 levels) in <top (required)>'
# ./spec/factories/variant_factory.rb:26:in `block (4 levels) in <top (required)>'
# ./spec/models/spree/variant_spec.rb:9:in `block (2 levels) in <module:Spree>'
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. 🔥
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.
