The CI build can't find the downloaded file and fails like:
```
2) enterprise fee summaries csv downloads smoke test for generation of report based on permissions when logged in as enterprise user generates file with data for the enterprise
Failure/Error: sleep 0.1 until downloaded?
Timeout::Error:
execution expired
# ./spec/support/downloads_helper.rb:34:in `sleep'
# ./spec/support/downloads_helper.rb:34:in `block in wait_for_download'
# ./spec/support/downloads_helper.rb:33:in `wait_for_download'
# ./spec/support/downloads_helper.rb:11:in `downloaded_filename'
# ./engines/order_management/spec/features/order_management/reports/enterprise_fee_summaries_spec.rb:119:in `block (5 levels) in <top (required)>'
# ./engines/order_management/spec/features/order_management/reports/enterprise_fee_summaries_spec.rb:80:in `block (4 levels) in <top (required)>'
# ./spec/support/downloads_helper.rb:22:in `with_empty_downloads_folder'
# ./engines/order_management/spec/features/order_management/reports/enterprise_fee_summaries_spec.rb:80:in `block (3 levels) in <top (required)>'
```
No need to slow down the build with partial coverage analysis that won't
be merged in a single report for the whole build.
Also, this makes builds fail because we are not running the whole suite.
The custom RSpec matchers they use raises the following deprecation
warning
```
Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/support/matchers/delegate_matchers.rb:22:in `block (2 levels) in <top (required)>'.
```
It's not worth maintaining those matchers to test such
implementation-related thing. Whether or not any delegations work is
something that will be caught by integration tests or directly stubbing
the collaborator object's methods.
This stems from
https://github.com/openfoodfoundation/openfoodnetwork/pull/6902.
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.
We had a very prominent footer showing how to get in contact with the
local instance people but most users need to get in contact with the
enterprise they are buying from. So removing all those details and
replacing them by a simple "powered by" line will hopefully direct
attention to the shop's contact details.
- This is an option, and by default it has the previous behavior: look only for visible element
- This option allows us to look for non-visible elements
- Using new altInput from flatpickr create a input hidden element. This is why we need to look at this element.
- Using the altInput from flatpickr forces us to use this default date format
- As we now use `altInput` from flatpickr, the value used to communicate between backend and frontend is stored into an input type hidden.
