Saisies champ : ne mettre l'entreé 'aucun' que si on est en radio. En effet, dans le cas des selects, c'est gérer directement par le select, dans les autres cas ce n'est pas pertinent

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

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formidable] Export depuis http://trad.spip.net de la langue en

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