option global pour activer de formulaire pour activer la vérification des valeurs acceptables pour les saisies. A voir pour plus tard comment on régle saisie par saisie

formulaire. Mais du coup, on avait plus _saisies en contexte, et par
conséquent formidable_definir_contexte_avec_reponse() ne pouvait pas
trouver correctement les saisies de type fichier.
On corrige en relisant les saisies directement passé à
$contexte['_formidable']

Plus compréhensible si on demande d'abord statut des réponses, les dates de début et de fin, puis les options. z+1

Permettre en option de ne pas joindre les fichiers dans un export de réponses : sur certains gros formulaires il vaut mieux télécharger un simple csv et récupérer les fichiers par FTP par exemple.

traitement. Utiliser cette vérif à chaque étape.

Pour le traitement enregistrer, tester l'unicité d'un champ si le champ
est dans l'étape courante.

Correction : en fait bouton_precedent n'existe pas dans SPIP (c'est qui les boulets qui ajoutent un bouton_suivant sans faire un bouton_precedent en même temps? :D). Donc on utilise une autre chaine par défaut.

Nouvelle fonctionnalité : on utilise toutes les modifs faites en amont sur Saisies. On peut donc maintenant configurer certaines options globales dans l'interface du constructeur. Pour cela on déclare au constructeur quelles options on accepte (c'est propre au contexte de Formidable).

Dans le lot, il y a donc la personnalisation du bouton final, et… le multi-étapes !

Pour cela, il a fallu faire un refactoring de la fonction verifier() de Formidable où tout était en dur… On l'a donc vidé de son contenu, afin que Formidable utilise enfin l'API CVT de Saisies avec la fonction saisies().

Au passsage, il y avait une vérification propre à un traitement (enregistrement) sur l'unicité : on en profite pour mettre en place un fonctionnement générique et extensible. Tout type de traitement peut désormais déclarer une fonction de vérification qui lui est propre avec traiter/montraitement_verifier(). Et si ça existe, ça sera utilisé.

Il reste un problème avec ce dernier point : pour le cas habituel ça continue de marcher pareil MAIS quand on active les étapes… Pour le moment j'ai fait le choix lorsqu'il y a étapes, de lancer ces vérifications propres aux traitements à la toute fin, quand on sait qu'on est à la dernière étape. Mais du coup ça ne va pas, car les erreurs ajoutées peuvent être sur des champs qui sont à d'autres étapes. Et CVT ne le sait pas, il reste sur la dernière étape. Donc ça montre "Vous avez X erreurs" en haut, mais on ne voit pas forcément le ou les champs précis en erreur s'ils sont ailleurs. Je ne sais pas encore comment résoudre ça…

du sens de rendre nospam obligatoire. Surtout cela évitera des demandes
systématique d'ajout de captcha.

Masquer les hidden, quelque soit la profondeur.

retour sur r111847, créer un traitement['enregistrement'] = array() vide, ce qui activait un enregistrement de manière non volontaire -> on désactive ce type d'enregistrement involontaire

Si on poste un champ checkbox vide, celui-ci ne renvoie rien.
On ne va pas mettre de valeur_non dedans, car cela complexifie la
structure de donnée.
Mais pour autant, on veut que la valeur nulle soit stocké en base.
Pour cela on s'appuie sur la nouvelle fonction
saisies_saisie_est_tabulaire() qui permet de savoir si une saisie est ou
pas de type tabulaire.

Merci à Florence Henry d'avoir remonté le problème sur la liste des
utilisatrices.

Je monte la version de facteur après sont dernier commit, et fait un z+1 pour être réduire aux max les possibilités qu'une vielle version soient en ligne (pour info, il ne devrait pas y avoir de problème d'encodage, j'ai fait deux vérifications avant mon commit)

enregistrer les config de formidable dans #CONFIG{formidable} et pas dans #CONFIG{formidable/analyse}