l'espace privé affiche pour un formulaire donnée le formulaire, sans passer d'identifiant explicite de réponse précédente. Du coup l'option d'identification par id de réponse plantait (erreur sql). On corrige cela (Florence Henry, contrib)

méthode d'identification de la réponse à éditer : par passage explicite
de l'identifiant, sans tenir compte ni du cookie, ni de l'id_auteur.

fichiers dans tmp/cvtupload. C'est une précaution, si jamais le
déplacement merdouille.

Cvtupload a son propre mécanisme de nettoyage de son dossier.

verifier que l'erreur de fichier est strictement égal à zero. Si c'est équivalent à zero, c'est juste qu'il n'y a pas de fichier (envoi multiple de fichier). Et du coup ca ne sert à rien de faire un traitement dessus.

En plus cela provoquait des fausses erreurs en essayant de zipper des fichiers inexistants. Bizarrement cette erreur se produisait qu'en cas d'ajax.

retrouvent dans #GENERER_SAISIES.
Conséquence: lorsqu'on envoie le formulaire à nouveau après le post, les
champs sont préremplis. Ce qui ne correspond pas du tout au comportement
attendu "Le formulaire, à nouveau", et pas "le formulaire, à nouveau,
prérempli". Ceci pourrait expliquer du reste pourquoi des gens envoie
plusieurs fois le même formulaire.
On vide donc les _requests de saisies après l'application de l'ensemble
des traitements.

oups, lorsqu'on ajoute des arguments à une fonction, fusse-t-elles interne, il faut vérifier tout ses appels

La conséquence concrète de ce bug était perverses et peu visible. Dans
les cas où un formulaire était soumis avec un fichier, mais qu'il y
avait une erreur au premier envoi, lors du second envoi on avait une
erreur mysql de type duplicate entry, et, conséquence étrange, la saisie
immédiatement après la saisie fichiers n'était pas enregistré en base.

Suite demande de Florence Henry : pouvoir avoir plusieurs champs destinataires comme destinataires des messages

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