c'était un bug introduit en r101363

permettre de mettre _FORMIDABLE_EXPIRATION_FICHIERS_EMAIL à 0 pour que les liens envoyés par email restent valable à l'infini

profiter de la nouvelle version de cvtupload pour permettre de remplacer les fichiers lors d'un envoi de formulaire de modification d'une réponse

et maintenant le cas où on envoie la réponse, mais on l'enregistre pas. On en profite pour mutualiser du code

traitement email, cas simple: les réponses ont déjà été enregistrées. Dans ce cas, on se contente d'ajouter un lien, expirable, pour télécharger le fichier

et se servir du fait que maintenant les mails partent après l'enregistrement pour mettre l'url de la réponse dans le mail

Ajout d'une option dans le traitement par email : elle permet d'indiquer un ou plusieurs emails en fonction de la valeur qui a été 
saisie dans un champ du formulaire. Particulièrement utilise pour un sélecteur qui indiquerait que le formulaire est à destination
de tel ou tel service, sans transmettre les couriels en question dans le html du formulaire.

Ainsi, si un sélecteur a 3 choix (le test s'appuie sur la clé, pas le texte de la sélection) (par défaut dans les saisies : choix1|Texte),
il est possible d'écrire, si le champ est nommé `@selection_1@` :

```
@selection_1@/choix1 : un_courriel@domain.tld
@selection_1@/choix2 : autre@domain.tld, et_autre@domain.tld
@selection_1@/choix3 : secretariat@domain.tld
```

On remarque qu'il faut revenir à la ligne pour créer un nouveau test. 
Le nom du champ est entre @ (comme ailleurs dans Formidable), la valeur du champ à tester est précédée d'un /
Les emails sont précédés de : et peuvent être séparés par des virgules.
Les espaces ne comptent pas.

Les tests ne sont pas exclusifs : si plusieurs conditions sont valides, les couriels sont cumulés.

+ Notice PHP en moins sur $destinataires parfois.

Suite à discussion sur IRC, la communication de l'IP de l'envoyeur aux destinataires doit être une option désactivée par défaut (nicod, Rastapopoulos)

Le mail envoyé aux destinataires du résultat du formulaire indique l'adresse IP du posteur (utile dans un contexte international pour vérifier la cohérence du contenu des infos saisies avec l'IP) (Bertrand)

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é