This groups the Customer Totals report by variant too (among others,
including by product), and then changes the report to use the variant
SKU not the product SKU.
This adds a spec for customer totals grouping and details, which
replaces the test specific to the SKU column.
This conversion is done by Transpec 3.4.0 with the following command:
transpec spec/lib/open_food_network/orders_and_fulfillments_report_spec.rb
* 8 conversions
from: == expected
to: eq(expected)
* 8 conversions
from: obj.should
to: expect(obj).to
* 1 conversion
from: obj.stub(:message)
to: allow(obj).to receive(:message)
For more details: https://github.com/yujinakayama/transpec#supported-conversions
Note that, as explained in
https://apidock.com/rails/v3.2.13/ActiveRecord/Relation/delete, `delete` does
not trigger callbacks and so it skips the products cache logic.
If we still want to avoid instantiating the AR object, we need to explicitly
call that logic for the cache to be up-to-date.
A previous pull request added support for flexible decimal characters
when editing money amounts.
https://github.com/openfoodfoundation/openfoodnetwork/pull/1831
This pull request applies the same principle to the weight calculator
which was missed in the previous pull request.
The `registration_path` helper resolves to `/signup` in Spree
controllers due to spree_auth_device > config > routes.rb.
We worked around that in:
https://github.com/openfoodfoundation/openfoodnetwork/pull/3174
Here we add a spec for this so that we can test more easily if we
remove that workaround or detect it's accidental removal.
The `registration_path` helper resolves to `/signup` in Spree
controllers due to spree_auth_device > config > routes.rb.
We worked around that in:
https://github.com/openfoodfoundation/openfoodnetwork/pull/3174
Here we add a spec for this so that we can test more easily if we can
remove that workaround or detect it's accidental removal.
The shipping methods are updated to their target settings after the
subscription order has been created, so the order is created with the
"require_ship_address" factory default which is "true".
The shipping method setting at time of order creation has implications
on whether a shipment is set up for the order or not.
This fixes some assertions from using the same subscription shipping and
billing addresses, and distributor address.
One of the specs also pass because the subscription shipping address
matches the distributor address. This commit makes that scenario
clearer.
