An inner join with the billing address was hiding some orders when
sorting by billing address name. Telling Rails that those fields are
referenced triggers an outer left join including orders without billing
address.
But when the Bulk Order Management page sorts by `bill_address_lastname`
then Ransack does most of the magic, except that we need to override the
select in combination with distinct results.
bill_address is already joined in this query.
The class variable isn't needed outside this scope.
Arguably I think the condition on the select isn't needed; it wouldn't hurt to always select spree_addresses. But I'll try to avoid changing too much..
Thus, we display the orders that contains at least one line item (whatever its state) + the finalized orders
NB // Finalized state : complete canceled resumed awaiting_return returned
With the help of the bullet gem, and since we remove a couple of N+1s
already, remove them all was just a few keystrokes away. This commits
gets us from 42 SQL queries to 17, and 364.5ms to 253.9ms on my machine
where I just have the sample data's orders. As usual, this will have
a much bigger impact in scenarios with more data.
This removes the N+1 queries caused by
`Api::Admin::OrderSerialier#ready_to_capture` when used from
`Api::OrdersController#index`. While it's fine for the single-order
controller actions, it's not for this one that deals with a collection
of orders.
Fortunately, `SearchOrders` is used only in this controller action so we
can put the `includes` calls there, otherwise, we would need to refactor
it a bit to pass in a context-specific AR relation.
The q['inventory_items_shipment_id_null'] search element was generating duplicates where there were multiple line items on an order that were ready to be shipped, with id = null
