pas besoin de définir les constante dans un fichier d'options, ne le définir que lorsqu'on s'en sert

La fonction "d'anomysation" dans traiter/enregistrement  concerne uniquement les auteurs connectés, on modifie les labels en conséquence.
On affiche les options pour cette fonction que si elle est cochée.

qui est passé au squelette de construction d'accusé de reception.
Par ex pour ajouter automatiquement certains messages en fonction des
résultats.

C'est plus propre que de faire cela par le pipeline recuperer_fond, car
cela ne dépend pas du formatage fait par le squelette.

Ceci créait une erreur si jamais un champ obligatoire était en
afficher_si et que la condition d'affichage n'était pas rempli.
Et pour cause, on disait de ne pas tenir compte des afficher_si, et de
vérifier tous les champs.

En fait il n'y a jamais eu d'enregistrement dans formidable de la config
des traitements qui ne sont pas activés. Et pour cause : dès lors qu'il
y a une config pour un traitement, celui-ci est considéré comme actif.

Du coup je sais pas ce qui m'a paris de faire r112371.

Les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y a comme env['id'] l'id du formulaire. Ce qui fait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaite pas.
Cependant, on ne peut pas modifier directement le contexte du formulaire
de config des traitements, car plusieurs plugins utilise des tests sur
$contexte['id'] et pas sur $contexte['id_formulaire'].
Par conséquence, on se contente d'annuler ce contexte['id'] dans le html
avant de charger les saisies.

les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y avait comme env['id'] l'id du formulaire. Ce qui faisait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaitait pas. Pour éviter cela, on précise de quel id on parle lorsqu'on charge le formulaire de config des traitements

conditionné par un afficher_si sont mis à null si la condition n'est pas
validée.

Ce qui veut dire concrètement que si on décoche une case d'un
traitement, toutes les infos sur ce traitement sont perdus. Or on peut
vouloir conserver les réglages d'un traitement sans pour autant
l'appliquer (si jamais on veut rebasculer).

Pour revenir à ce qui était le comportement historique de formidable
(basé sur un bug de saisies), on dit explicitement qu'on ne veut pas de
_request mis à null en cas d'afficher_si.

d'accusé de réception

  - mutualisation du code avec les autres saisies
  - conséquence : on peut l'appeler en précision le type de saisies pour
  selectionner la saisie. Donc pas limité au select, mais aussi radios
  ou checkbox