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

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.

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.

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…

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

1. Était factuellement faux, car confondant l'identité de l'utilisateur et son identifiant SPIP
2. Était marqué en balise HTML de manière sématniquement incorrect.
3. Faisait une requête SQL inutile

encore un peu plus de séparation en fieldset dans la config des enregistrements + un changement de label + deux / trois broutilles de mise en forme

problème indépendant de la conservation de l'identifiant auteur.

On sépare donc cela.
Première étape : séparation dans l'espace de config.

label + explication pour la variable d'anonymisation + pas besoin d'une chaine de langue pour l'intro du select (surtout avec un nom absolument pas explicite)

identification ne sert pas que pour la modification des réponses, mais aussi pour interdire les réponses multiple, on reformule la chaîne de langue.

La fonction "d'anomysation" dans traiter/enregistrement  concerne uniquement les auteurs connectés, on modifie les labels en conséquence.
On affiche les options pour cette fonction que si elle est cochée.

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

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

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