option globale pour avoir un afficher_si sur le bouton de validation, cf. https://contrib.spip.net/Formidable-le-generateur-de-formulaires#comment507495

profiter de l'option afficher_si_avec_post des dernières versions de saisies, pour pouvoir tester/retester le multi-étapes

configuration globale du formulaire : cela n'a de sens de pouvoir régler précédent/suivant que si on active le multi etape

uniformisation de la présentation des case dans le formulaire de config des options globale d'un formulaire

ppasse de admin* à admin, soyons clair sur les statut, pas besoin d'une explication si le libellé est clair. Ping @nicod_

Mieux : on collecte tous les messages de retour (le personnalisé + ceux des traitements), ce qui permet ensuite de les distinguer plus facilement avec des sauts de lignes.

Ticket #44 : afficher les messages de retour des traitements même s'il y a un message personnalisé, car ils peuvent contenir de informations importantes, ou être indispensables au fonctionnement même du formulaire s'ils contiennent du JS qui déclenche des actions. On fait au plus simple : Le message perso est placé au début, séparé par un saut de ligne.

systématiquement le cas en base.
Par conséquent les comparatifs de md5 pour vérifier des modifs //
peuvent parfois foirer (PRX38, spipfactory, Nat33 via @marcimat).

On résoud cela en
1. Identifiant retrospectivement les saisies
2. S'assurant avant d'enregistrer en base que les saisies soient bien
identifiées

formulaires_editer_objet_verifier() ne prend que 3 arguments + retenir correctement l'id_formulaires_reponse

par définition lorsqu'on fait un revert sur un constructeur de formulaire, on veut revenir aux saisies anciennes, donc inutile de dire qu'il y a eu une différence, ni de faire quels que tests que ce soit de vérification

Il arrivait parfois, lorsqu'on modifiait une saisie d'un formulaire
existant, et qu'on validait la modif des saisies, que formidable nous
disait que le formulaire avait été modifié en base, alors que ce n'était
pas le cas.
Pourquoi cela ?
Parce que le md5 des saisies initiales stocké par le plugin saisies
était faite à partir des saisies passés au squelette.
Or lorsqu'on passe un tableau en contexte de SPIP, celui transforme
tout `integer`en `string`.
Cela posait problème si les yaml indiquait des paramètres par défaut
sous forme d'entier et pas sous forme de string.
En effet le md5 initial était calculé par saisies sur un tableau du type
````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string '40' (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Alors que la vérification par formidable se faisait sur un tableau du
type

````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string 40 (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Forcément les hash n'était pas les mêmes, et cela provoquait une erreur.

Pour éviter cela, on imite le comportement de spip avant de calculer le
hash lors de la vérification: on transforme recursivement dans le
tableau les `integer` en `string`.

sécurité : une fois les saisies stockés en base, les effacer de la session, pour éviter de retrouver des vieilles

issue #9 : lorsque id_revision est passé au formulaire de config de traitement, celle-ci prend le pas sur ce qu'il y en base. Et on passe id_revision à ce formulaire si on l'avait déjà avant

pb #9 : lorsqu'on arrive à la config des champs de formulaire depuis un demande de restauration, prendre les champs de l'ancienne version

- si une personne reprend une veille session alors qu'il y a une modif
en base des champs de formulaire, la veille session est annulée
(correction faite au niveau du plugin saisies
saisies@673fcfac)
- si une personne modifie les saisies et qu'entre le moment où il
commence sa modification et le moment où il valide l'ensemble des
modifs, une tierce personne a modifié en base :
  - on met un message d'erreur
  - on demande de recommencer les modifs, à partir de ce qu'il y a en
  base

Plus de séparation entre les traitements à choisir et leur configuration, moins de marges inutiles, plus d'espace.

charger() et pas à la fin de traiter(), sinon on ne peut pas accéder a
leurs valeurs dans le pipeline formulaire_traiter()

Modification d'une réponse depuis l'espace privé : le faire même si le formulaire n'autorise pas la modification par les utilisateurs de leurs propres réponses

Exemple d'emploi: un site qui gère des inscriptions à des évènements,
avec plusieurs dates possibles, pour modifier directement les infos sur la date de l'evenement retenue si la personne change d'avis.

Utiliser objet_modifier plutôt que sql_updateq pour générer une révision quand on modifie les traitements ou les saisies.
La restauration de révisions ne fonctionne pas pour autant, mais c'est un autre problème à régler.