The check for whether the checkbox should be checked or not was made by
matching the whole string. Thus, given two options 'valid' and
'invalid', the check for the presence of 'valid' would succeed even when
only 'invalid' was present in the values (because
`'valid'.includes?('invalid')`.
The code now checks against the list of items in the selected_options.
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
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
