This method is named "update distribution charge". What this method actually does is delete all of the fee adjustments on an order and all it's line items, then recreate them all from scratch. We call this from lots of different places all the time, and it's incredibly expensive. It even gets called from inside of transactions being run inside callbacks. Renaming it hopefully will add a bit of clarity.
This needs to be a lot more granular!
Fixes#6435 i.e. If the customer paid for their order by Stripe/Paypal then the Enterprise needs to know that the order was cancelled in order to arrange a refund. Refunds are not automatically processed when an order is cancelled.
This will send a very basic email to the shop, it only includes a link to view the cancelled order in the admin area initially.
I created a CustomerOrderCancellation object here because orders can be cancelled in two ways (1) by the customer, so an email should be sent to the shop. (2) by the shop, so an email doesn't need to be sent. However the code for cancelling order happens in Order#cancel via the state machine. Rather than passing some sort of parameter into #cancel to indicate whether it is a customer or shop cancelled order it might be clearer to have a CustomerOrderCancellation object, there could be other differences between customer or shop cancelled orders in future maybe.
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.
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.
Guest orders also have an associated customer record that is created
by Spree::Order#ensure_customer at checkout. Subsequent orders will use
that one due to Spree::Order#associate_customer.
Removes use of #handle_asynchronously, which we need to do elsewhere. Fixes:
BulkInvoiceService#start_pdf_job starts a background process to create a pdf with multiple invoices
Failure/Error:
expect do
service.start_pdf_job [1, 2]
end.to enqueue_job Delayed::PerformableMethod
expected to enqueue exactly 1 jobs, but enqueued 0
# ./spec/services/bulk_invoice_service_spec.rb:8:in `block (3 levels) in <top (required)>'
