This query object is meant to be reusable but those includes are
context-specific and will likely not be needed when reusing the query
elsewhere. If we keep them there, chances are next dev might not notice
it and will introduce a performance regression.
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)
```
Example error:
Tag Rules creating allows creation of rules of each type
Failure/Error: expect(tag_rule.preferred_shipping_method_tags).to eq "volunteers-only"
expected: "volunteers-only"
got: ""
(compared using ==)
# ./spec/features/admin/tag_rules_spec.rb:81:in `block (3 levels) in <top (required)>'
Setting `locals: { :@order => order }` no longer works; `@order` is not set as expected in the partial. Fixes various errors eg:
Failure/Error: = "#{@order.number}"
ActionView::Template::Error:
undefined method `number' for nil:NilClass
# ./app/views/spree/admin/orders/invoice.html.haml:14:in `_app_views_spree_admin_orders_invoice_html_haml__1740595365701113578_70025078036080'
# ./app/services/invoice_renderer.rb:3:in `render_to_string'
# ./app/controllers/spree/admin/orders_controller.rb:89:in `invoice'
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)>'
When an order is submitted and the payment fails, the failed payment's adjustments (payment fees) are set to `eligible: false` to indicate they do not apply. These should not be counted as being included in an order's adjustments.
When checkout fails and the payment states dont match (inside the if), in-memory data of the failed payment can be lost but updating the payment state is the fundamental part here so that further checkout attempts work. We may improve this update statement so that all the data of the failed payment is persisted
