jquery-ujs automatically disable submit button when submitting the form.
If one choose cancel on the leaving page warning, then the submit buttons
end up in a disable state, with no way to re enable them. This fix
prevent the warning from being triggered when submitting the form, so
we can't end up in the scenario described.
Buttons will be enabled once the form has been interacted with.
Update unsavedChanges stimulus controller to handle this. It should
still be generic enought that it can be reused.
Add UnsavedChanges stimulus controller, it should be generic enough so
that it can reused somewhere else. It works with both 'beforeunload' event
and 'turbolinks:before-visit' when using turbo links.
Since https://github.com/openfoodfoundation/openfoodnetwork/pull/10317 we are displaying the error message also in the flash message. For unknown reason, build didn't fail for that PR, but, as the PR adds some error message, we need to change the spec to reflect that change.
This PR separates error in checkout page itself, and errors in flash message banner.
Specs should test classes and modules independently and they should not
be in the same module. It also avoids indentation and accidental
namespace polution.
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.
Sidekiq doesn't have any features to limit memory usage or execution
time. We need a separate process for this. Forking avoids the boot time
of a fresh process and copy-on-write ensures minimal memory overheads.
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.
It's just testing that we are not using code which has been deleted in
the past. I don't think that there's a risk that we introduce this again
by accident. Right now, this spec just wastes resources.
