saisie champ : si forcer_type est n'est pas un tableau, ne pas essayer de le fusionner directement avec un tableau pour ajouter fieldset

saisie champ, l'option qui filtre par type conserve l'arborescence des fieldsets + lorsque deux champs sont homonymes, les conserve

retour sur r115838 : si un fieldset à un label, l'utiliser comme optgroup. On précise toutefois entre parenthese le nom, si jamais on a plusieurs fieldset avec le même label

si on autorise les pages publiques pour les formulaires, alors il faut mettre le lien pour les voir en ligne s'ils sont publiés

mettre dans l'aide memoire la liste des options possibles pour les champs y c'est pertinent. Utile notamment pour créer des afficher_si et autre

saisie champ : si un fieldset n'a pas de label, utiliser le nom de la saisie comme titre de optgroup

saisie champ : pouvoir voir les fieldset dans les fieldset. Par contre on rend pas cela comme dans des optgroup dans des optgroup, mais on aplatit les fieldset a partir du second niveau (normalement d'ailleurs on déconseille les fieldset dans les fieldset)

Reconnaitre la signature <formulaire|formidable|identifiant> (un modèle formidable ne contient pas forcément id=identifiant)

Possibilité de définir un texte spécifique pour l'accusé de réception, différent du message de retour du formulaire.

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

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…