Indentation

reçoit un accusé de réception de soi même !

Vérification que les réponses sont bien contenues dans une variable de type tableau et que le nombre d'éléments n'est pas nul

Controle du numero d'id_reponse en base
Mise à jour du champ maj dans la table spip_formulaires_reponses
Vérification de l'id_auteur lorsqu'un id_formulaires_reponses est fourni pour éviter qu'un 
auteur modofie les réponses d'un autre

Changement de méthode d'obtention de l'id_formulaire pour calculé l'id_auteur scrambled. Avant il était toujours vide et c'était seulement l'id_auteur et le mot de passe qui servait au scramble.

- les traitements doivent noter qu'ils ont bien ete executes dans ['traitements'] pour ne pas etre executes plusieurs fois
- un traitement qui veut/doit passer apres un autre peut ne rien faire et rendre la main au premier tour pour laisser l'autre se faire
- on refait la boucle 5 fois au maximum pour executer tous les traitements
- si des traitements n'ont pas pu etre executes, on declenche un mail au webmestre avec l'erreur et un dump de  dans le mail pour ne pas perdre de donnees
- si aucun traitement n'a ete execute (defaut de configuration?) on declenche un mail au webmestre et un dump de  dans le mail pour ne pas perdre de donnees

Cette modification entraine une petite incompatibilite sur les traitements perso : ceux-ci seront executes 5 fois et une erreur sera generee si ils ne sont pas modifies pour renseigner ['traitements']

Securite : toujours utiliser l'id passé en argument de #FORMULAIRE_FORMIDABLE et non celui qui est posté et a pu etre corrompu. On centralise la conversion de l'id en id_formulaire

Extensibilite : fournir id_formulaire et id_formulaires_reponse si possible en sortie de la fonction traiter (pour les pipelines)

Ajout d'un nouveau champ dans les traitements permettant de spécifier l'adresse email d'un des destinataires comme un des champs du formulaire.

Ne pas laisser des entités dans les champs de mail qui ne gèrent pas le HTML : c'était déjà le cas pour le sujet mais pas pour le nom de l'envoyeur. On fait donc filtrer_entites().

puisque le message de retour passe par |propre, inutile de mettre un <br /> devant... cela évite d'avoir un <br /> en début de message

comme le fait remarquer cedric, il n'est pas très poli de ne mettre aucun message après la validation d'un formulaire. Mettons un message par défaut à l'enregistrement en bdd.

possibilité d'exclure certains champ de l'analyse (utile notamment lorsque on des champs qui sont uniquement là pour conditionner l'affichage d'autres champs)

Version 1.5.2 pour formidable et 3.0.3 pour facteur désormais.

pas garder de traces des utilisateurs ayant répondu (tout en gardant
la possibilité d'avoir des réponses uniques, modifiables

* traitement de l'anonymisation. Elle permet de créer des formulaires dont les réponses sont anonymes (pas d'adresse IP, pas de nom de cookie, pas de login)
* export de l'analyse des données en en CSV depuis l'Espace Privé

L'ajax a du mal à se charger correctement. Pour le moment, on l'enlève jusqu'à ce qu'on comprenne d'où vient l'erreur.
- <:bouton_radio_modere_xxx:> passe dans l'extension forum en spip3. A prendre en compte dans formidable.
Est-ce qu'on met un nécessite pour l'extension forum alors ?

Gestion des from sur les emails envoyés post saisie : il faut garder le from par defaut de SPIP car sinon on ne peut pas utiliser les SMTP un peu sécurisés, et de plus un mail avec même dest et from a toutes les chances de se faire arrêter par les antispams...