Sending large reports via Cable Ready is unreliable. The events are
dropped at an unknown point and the report is never displayed to the
user. Instead we just send a link to the report via Cable Ready and
offer a button to load the report on screen.
This has the UX benefit of warning the user about the size as well.
Weaker devices can struggle rendering big HTML documents.
Nested forms are not valid HTML and we were submitting the wrong
authenticity token to Rails when updating the enterprise.
I inverted the hierarchy of the form and the panels. The menu and
tab-panel structure now sits above and the enterprise edit form is
nested within.
The current structure is not ideal but it's only a transition phase. I'm
expecting the page to get re-designed at some point and re-writen
without AngularJS.
The check for invoiceability is already done by the reflex triggering
the job. Let's DRY the code, save time and be more flexible in the
future.
Also checking the order of actually generated PDF pages.
It allows us to list enterprises from any OFN server, not just ofn-au.
The app could even accept any enterprise on any server providing its
data in the DFC format.
In the past, we needed the report blob to know when the report has been
finished and uploaded. But not we use cable_ready to notify when the
report is done and we don't need the blob in the controller.
the invoices feature is enabled:
1. we filter non-invoiceable order
2. for each invoiceable order, we check if we need to generate a new invoice or update the latest invoice
Rubocop was complaining about too many arguments. But
`ApplicationJob#perform` needs all arguments handled in one call. While
we could allow the `perform` method generally to have more arguments,
there could be other methods called `perform` which should still be
scrutinised. Instead, it seems acceptable to me to have more arguments
as long as they are clearly named as keyword arguments. Rails uses this
a lot to document all options including their default values, for
example in Active Storage. It's better then bundling several arguments
in an undocumented hash just to reduce the number of given arguments.
And once we upgraded to Ruby 3.1, we can clean the method calls up as
well. `call(user: user)` becomes `call(user:)` without repetition.
I added a system spec to verify that the download link can be generated
within the mailer in a background job. ActiveStorage is a bit particular
when it comes to genererating URLs and depending on the situation it may
generate a redirect URL, a proxy URL or link directly to the storage.
But we want a redirect URL here.
Using the clever concurrency testing borrowed from SubscriptionPlacementJob, but I thought a shorter pause time (just 100ms) would be sufficient.
I considered doing this with a new 'state' field (upcoming/open/close), but decided to keep it simple.
Best reviewed with whitespace hidden.
Unfortunately the spec isn't allowed in CI. But it worked on my environment, I promise.
I chose `xit` so that it doesn't run unnecessarily. Perhaps we could use `pending` instead, which would execute, and notify us if it suddenly started working one day. But I doubt it.
This job is responsible for delivering a payload for one webhook event only. It allows the action to run asynchronously (and not slow down the calling process).
```
/Users/jibees/dev/openfoodnetwork/app/jobs/report_job.rb:22:in `write': "\\xFE" from ASCII-8BIT to UTF-8 (Encoding::UndefinedConversionError)
from /Users/jibees/dev/openfoodnetwork/app/jobs/report_job.rb:22:in `write'
from /Users/jibees/dev/openfoodnetwork/app/jobs/report_job.rb:8:in `perform'
```
New Rails apps come with this class already, the job generator creates
it for every new job and Rubocop requires it as well. Let's make our
lives easier and use the same structure as other Rails projects. This
class may be handy one day.
This is supposed to lower the memory footprint of all Puma workers. The
reports code will occupy needed memory in one Sidekiq worker instead of
in several Puma processes.
The current code doesn't limit the execution time yet. We either need a
way to terminate the report rendering after a while or send an email
with a link to access a rendered report.
