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
Validate that a dossier on a `for_individual?` procedure always has
an `individual` associated record.
For this, the individual needs to be built before the record is
validated (i.e. even before the `before_create` callback is run).
This should help with #4596: now if a dossier is created without an
`individual`, or if the `invividual` record is later removed, the
validation will fail.
When receiving a request that expects JSON, return a simple '200'.
This avoids the unecessary work of rendering all the HTML page (which
ultimately will not be used).
Make the default behavior of `update_brouillon` be to update the draft,
instead of submitting the dossier.
This makes all requests made to `update_brouillon` without specifying
an extra `submit_draft` parameter to just save the draft. It will make
autosaving the draft easier and safer.
The code paths for deleting a dossier were different, depending on
whether the dossier was deleted by the user, or from the Manager.
This commit unifies the two code paths into one.
This has the effect of:
- An operation log is now recorded when an user deletes its own dossier;
- Gestionnaires are now notified even when the dossier is deleted from
the Manager;
- The `support:delete_user_account` task now requires the email address
of the author.
