Currently ProgressBar is used to monitor upload progress of attachments.
But there's two cases where the associated DOM element may be removed:
- In the champs editor, when the list scrolls, DOM elements are removed
and added dynamically by React;
- In the user form, the user might start an upload on a repetition, and
then remove the associated row during the download.
In both those cases, we don't want the missing DOM element to trigger
an error.
We have errors in production where the job starts correctly (i.e. the
blob exists), but `blob.open` fails with a `ActiveStorage::FileNotFound`
error.
When checking later in production, the blob has been deleted.
This points to the blob (and the file) being deleted during the virus
scan job.
In that case, ignore the error (rather than retrying the job).
Currently, deselecting all values from a multiple dropdown rendered as
checkboxes doesn't have any effect when submitting the form (the
previous values are still there, instead of being deselected).
This is because unchecked checkboxes are not sent by the browser – so
the "empty selection" never gets sent.
Rails `form.check_box` usually works around this by inserting an empty
hidden checkbox element, that will be sent even if all others are
de-selected. But the documentation warns that this is not possible when
iterating over an array (rather than a model). Which is our case here.
To fix this, this commit uses `collection_check_boxes` instead. It will
insert the proper hidden checkboxes in all cases, and fix our use case.
See https://api.rubyonrails.org/classes/ActionView/Helpers/FormOptionsHelper.html#method-i-collection_check_boxes
This fixes an issue where clicking quickly on several "Remove row"
buttons on a repetition field results in autosave errors.
This is because the N+1 autosave request is correctly sent after the
Nth response from the server, but _before_ the row element is actually
removed from the DOM. So the N+1 request actually sends the fields for
the deleted row, which makes the server raise an error.
With this fix, the row gets properly removed when the server responds,
and before the next request is started.
Before, when autosaving a draft, removing a repetition row would
send `_destroy` inputs to the controller – but not remove the row
from the DOM. This led to the `_destroy` inputs being sent again
on the next autosave request, which made the controller raise
(because the row fields were already deleted before).
To fix this, we let the controller response remove the deleted
row(s) from the DOM.
Doing it using a controller response avoids the need to keep track
of operations on the Javascript side: the controller can easily
know which row was just deleted, and emit the relevant changes for
the DOM. This keeps the autosave requests robust: even if a request
is skipped (e.g. because of a network interruption), the next request
will still contain the relevant informations to succeed, and not let the
form in an unstable state.
Fix#5470
After clicking on a radio button option, it is impossible to revert to
the "None of the values selected" state.
However on non-mandatory fields, reverting to the no-selection value
should be possible.
To fix this, add an explicit "N/A" option.
- Make `type_de_champ.procedure` a requirement;
- Move the procedure_id assignation to `before_validation` (otherwise
the record is invalid, and never gets saved);
- Make `champ.dossier` a requirement;
- Move the dossier_id assignation to `before_validation` (otherwise
the record is invalid, and never gets saved);
- Allow specs to only build the champ (instead of saving it to the
database), which bypasses the requirement to have a dossier.
current year + 50] (or [entered_date; current_year + 50] if old date already entered) because:
The type_de_champ Datetime is used for close future dates and very close past dates (for accident declaration for ex.)
The select currently has a range from 1950 to 2100, so 70+ years not supposed to be used, leading to:
- many bad data entered (0000 or 1950 to not scroll)
- making it difficult for users to give the proper date (current date is lost in the middle of 149 others) so risk to be lazy and select a random one or genuinely make a mistake
ActiveStorage jobs are now moved to their own queue.
For consistency, we also move our own analysis jobs (VirusScannerJob)
on the same `:active_storage_analysis` queue.
Starting from Rails 5.1, `form_with` behavior is to generate remote
forms by default.
However with Turbolinks disabled, the form gets sent, but nothing is set
up to handle the server response (like replacing the content of the
page).
So we have two choices: either enable a global config option that makes
`form_with` generate non-remote forms, or do it explicitely on each
form. I chose the explicit way, so that developers expecting the usual
remote behavior of `form_with` are not surprised.
