BigDecimal was throwing an error here (in Rails 5) unless it received a string, but I think this is actually an issue with the way params were being passed in the relevant spec, as opposed to the controller itself.
This removes the following annoying deprecation warnings that happen in
each test.
```
DEPRECATION WARNING: You are trying to generate the URL for a named route called :main_app but no such route was found. In the future, this will result in an `ActionController::UrlGenerationError` exception. (called from process_action_with_route at /usr/s
rc/app/spec/support/controller_requests_helper.rb:49)
DEPRECATION WARNING: Passing the `use_route` option in functional tests are deprecated. Support for this option in the `process` method (and the related `get`, `head`, `post`, `patch`, `put` and `delete` helpers) will be removed in the next version without
replacement. Functional tests are essentially unit tests for controllers and they should not require knowledge to how the application's routes are configured. Instead, you should explicitly pass the appropiate params to the `process` method. Previously th
e engines guide also contained an incorrect example that recommended using this option to test an engine's controllers within the dummy application. That recommendation was incorrect and has since been corrected. Instead, you should override the `@routes`
variable in the test case with `Foo::Engine.routes`. See the updated engines guide for details. (called from process_action_with_route at /usr/src/app/spec/support/controller_requests_helper.rb:49)
```
Closes#6727.
This avoids the authorization of all the VOs of the hub, which will go
through VOs that may have become invalid due to their underlying product
not belonging to the supplier the hub has permissions with (or any other
data integrity issue).
This is utterly confusing for the user who is only given a generic error
and doesn't understand what's wrong with the particular VO they changed,
while it may be fine after all. What's more, this often results in
a customer support request, which then may end up with a dev finding out
which VO is broken.
Also, there's no point in loading them from DB if the users didn't touch
them.
This removes the following two deprecation warnings that we are getting
by millions (the two for each controller action test):
```
DEPRECATION WARNING: You are trying to generate the URL for a named route called "main_app" but no such route was found. In the future, this will result in an `ActionController::UrlGenerationError` exception. (called from process_action_with_route at /usr/
src/app/spec/support/controller_requests_helper.rb:49)
DEPRECATION WARNING: Passing the `use_route` option in functional tests are deprecated. Support for this option in the `process` method (and the related `get`, `head`, `post`, `patch`, `put` and `delete` helpers) will be removed in the next version without
replacement. Functional tests are essentially unit tests for controllers and they should not require knowledge to how the application's routes are configured. Instead, you should explicitly pass the appropiate params to the `process` method. Previously th
e engines guide also contained an incorrect example that recommended using this option to test an engine's controllers within the dummy application. That recommendation was incorrect and has since been corrected. Instead, you should override the `@routes`
variable in the test case with `Foo::Engine.routes`. See the updated engines guide for details. (called from process_action_with_route at /usr/src/app/spec/support/controller_requests_helper.rb:49)
```
It slows down our test suite and clutters the output a lot. As per my
investigation, this is something that arose in
https://github.com/rails/rails/pull/17453 and addressed in
https://github.com/rails/rails/pull/17725. TL;DR: Engines need to define
their routes in controller tests as shown in
https://github.com/discourse/discourse/pull/3011.
This, however, revealed a much complex reality in our case. We're still
using a `Spree::Core::Engine` with its own routes at
`Spree::Core::Engine.routes`. So we can't skip defining `routes { }` for
each of its controllers unless we merge this engine into our app, but
that's going to require more effort. What could that entail in
https://github.com/openfoodfoundation/openfoodnetwork/compare/master...coopdevs:move-users-to-app-routes.
To make it even worse, note that we override spree's core routes from
our own, resulting in a controller whose actions are being served from
routes defined in either `config/routes.rb` or `config/spree/routes.rb`
🙈.
If an admin changes the amount on a tax rate, and that rate has been used by adjustments in the past, we need to soft-delete and clone it to preserve the data integrity of previous adjustments that were created using that rate.
This makes it possible to deploy it without releasing it to users since
the toggle is not enabled for anyone.
It aims to make the balance calculation consistent across pages.
We only care about non-cart orders and skipping carts, saves PostgreSQL
query planner to go through thousands of records in production use cases
(my food hub).
We go from
```sql
-> Index Scan using index_spree_orders_on_customer_id on spree_orders (cost=0.42..12049.45 rows=152002 width=15) (actual time=0.015..11.703 rows=13867 loops=1)
```
to
```sql
-> Index Scan using index_spree_orders_on_customer_id on spree_orders (cost=0.42..12429.46 rows=10802 width=15) (actual time=0.025..17.705 rows=9954 loops=1)
```
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.
DEPRECATION WARNING: `#deliver` is deprecated and will be removed in Rails 5. Use `#deliver_now` to deliver immediately or `#deliver_later` to deliver through Active Job.
