We rely now on the exhaustive list of states an order can be in after
checkout. What made this all a bit more messy is that I made up the
"checkout" order state, likely mixing it from the payment model states.
This simplifies things quite a bit and gives meaningful names to things.
We don't care about the conversion from hash to JSON (that's an
ActiveModel::Serializer responsibility that is thoroughly tested) but
our logic so we can skip that step which only slows down tests.
It consistently reduced ~1.5s on my machine but it's still too slow to wait
~8.5s to get feedback from them.
Instead of relying on Spree::Order#outstanding_balance we make us of the
result set `balance_value` computed column. So, we ask PostgreSQL to
compute it instead of Ruby and then serialize it from that computed
column. That's a bit faster to compute that way and let's reuse logic.
We hide this new implementation under this features' toggle so it's only
used when enabled. We want hit the old behaviour by default.
We're in Rails 4.2 so we can remove it. This gets rid of the following
message when running tests:
```
DEPRECATION WARNING: Suppressing Selenium deprecation warnings is not needed any more. (called from block in <top (required)> at /usr/src/app/spec/spec_helper.rb:214)
```
Devise has been complaining about this for a while in the test suite:
```
[Devise] including `Devise::TestHelpers` is deprecated and will be removed from Devise.
For controller tests, please include `Devise::Test::ControllerHelpers` instead.
```
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.
It's simpler if there is just one place to add a new product. Closes#6650
This removes the 'creating directly from the new product path' test scenario because we have another 'assigning important attributes' scenario above which provides enough coverage.
Spree used to give you more options to configure ActionMailer but our
setup is much simpler. We can remove unused code.
The removed option was never used by OFN and defaulted to true. We don't
need a database migration because the value isn't set in the database.
These states are reached when the order is complete and shipped. An
admin can create a new return authorization, which will set the order in
`awaiting_return` state. It's only after, when we call
`return_authorization#receive` that the return authorization moves to
`received` state and the order to `returned`.
You can do so from the UI by editing the return authorization and
clicking on Receive. However, we didn't find any order in such state in
UK, FR and AU. The UX is quite obfuscated. That must be why no users
clicked on it.
The `returned` state cannot count for the balance as is, since some of
the products are returned to the shop. That's enough for now.
