feat(administrateurs/procedures#show): warning/alert when procedure_expires_when_termine_enabled is not true on current procedure
feat(administrateur/procedure#update): after an update redirect to procedure show: suggested by: https://ux.stackexchange.com/questions/55291/after-updating-form-should-redirect-back-to-form-itself-or-to-the-show-page-or-b and confirmed by Olivier
clean(Flipper.archive_zip_globale): no more in use, so remove all occurences
Update app/views/administrateurs/procedures/_suggest_expires_when_termine.html.haml
Co-authored-by: Pierre de La Morinerie <kemenaran@gmail.com>
Update app/views/administrateurs/procedures/_suggest_expires_when_termine.html.haml
Co-authored-by: Pierre de La Morinerie <kemenaran@gmail.com>
Update app/views/administrateurs/procedures/_suggest_expires_when_termine.html.haml
Co-authored-by: Pierre de La Morinerie <kemenaran@gmail.com>
Update spec/views/administrateurs/procedures/show.html.haml_spec.rb
Co-authored-by: Pierre de La Morinerie <kemenaran@gmail.com>
fix(review): typo, why ena?, who knows
fix(env.example.optional): add missing DEFAULT_PROCEDURE_EXPIRES_WHEN_TERMINE_ENABLED
wip(dossier_created_hook): add tile to administrateurs/procedure#show in order to crud dossier_created_hook
refactor(css.utilities): remove merge helpers.scss within utils.scss (same purpose). use scss each for spacer modifiers
refactor(dossiers/_merci.html): extract partial _merci so we can re-use it in preview of dossier_created_hook.
feat(wip): current progress
Context: we want to validate public and private types_de_champ
separately.
Before we validated the whole revision (and then validators themselves
enumerated all champs, public and private).
Now we validate the actual public types_de_champ, which will let us
validate separately the private types_de_champ.
Deep-cloned objects have all their relationships stale. Thus, for a
newly deep-cloned revision, `revision.types_de_champs` returns `[]`,
even when it actually has associated types de champ.
This causes consecutive champs creations and re-ordering to fail in
subtle ways, like:
```
procedure.draft_revision.add_type_de_champ(…)
procedure.publish_revision!
procedure.draft_revision.add_type_de_champ(…)
procedure.draft_revision.move_type_de_champ(…) # this will fail
```
As `publish_revision!` created a new stale revision, moving the type
de champ fails because not all existing champs are found until the
object is refreshed.
We don't hit this path in production, because usually only a single
operation is made in a request.
To fix this, save the new revision before associating it as the draft
procedure.
(Another option would be to `reload` the revision after creation, but
this seems better contained and matches the name of the method.)
We used to pre-validate the procedure, to display in advance if the path
could be used.
Now that the path autocomplete is long gone, we can remove this kludgy
code.
