On peut vouloir envoyer un accusé de réception uniquement, sans le mail de notification de base (donc sans destinataire).

Permet d'ajouter automatiquement ses propres destinataires.
Exemple d'usage :
- j'associe via cextras un email aux evenements
- je crée un formulaire formidable avec une saisie evenements
- je notifie automatiquement tout les emails associés aux évenements
choisis par l'internaute

Ne filtrer qu'une seule fois les destinataires des emails pour s'assurer des doublons + appliquer trim par securité

oups, dans la config d'un traitement, une case décochée a bien une valeur enregistré en base (''), donc faut modifier le test

effacer TOUT les anciens résultats, et pas uniquement pour les champs
qui viennent d'être postés.
En effet, les nouvelles valeurs peuvent conditionner le non-affichage
d'un champ pour laquelle une valeur avait été enregistrée avant. Dans ce
cas il faut aussi effacer cette valeur.
Exemple
- Le formulaire est configuré de sorte que si la case_1 est cochée, alors afficher le champ input_1.
- Premier enregistrement de la réponse : case_1 cochée, champ input_1
valant 'toto'
- Modification de la réponse : case_1 décochée.
  - Avant ce commit, la valeur 'toto' restait associée à case_1 en base,
  faussant tableau d'analyse et autre
  - après ce commit, ce n'est plus le cas

nouveau raccourci pour le message de l'accusé de réception : @message_retour@. Permet de prendre le message standard de retour de formulaire puis de le compléter

Amélioration de l'anonymisation dans le cadre une d'identification par identifiant de la personne identifiée. Modification légère de la base.

Possibilité d'utiliser une méthode d'identification par l'identifiant de la personne identifiée tout en anonymisant les réponses.

Modification d'une réponse depuis l'espace privé : le faire même si le formulaire n'autorise pas la modification par les utilisateurs de leurs propres réponses

options pour ne pas envoyer d'email en cas de modif de réponse (par exemple: lorsqu'on modifie depuis l'espace privé)

lors de l'enregistrement d'une réponse, indiquer dans la chaine de traitement s'il s'agit d'une modif d'une reponse, pour que les les traitements ultérieures puissent, le cas échéant, avoir un comportement spécifique

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.

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

traitement. Utiliser cette vérif à chaque étape.

Pour le traitement enregistrer, tester l'unicité d'un champ si le champ
est dans l'étape courante.

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…

Si on poste un champ checkbox vide, celui-ci ne renvoie rien.
On ne va pas mettre de valeur_non dedans, car cela complexifie la
structure de donnée.
Mais pour autant, on veut que la valeur nulle soit stocké en base.
Pour cela on s'appuie sur la nouvelle fonction
saisies_saisie_est_tabulaire() qui permet de savoir si une saisie est ou
pas de type tabulaire.

Merci à Florence Henry d'avoir remonté le problème sur la liste des
utilisatrices.

reprenne ce travail)

afficher la config de réglage de l'unicité des réponses que si on aura réellement besoins (tous les traitements en PHP se basent sur le principe que le règlage par défaut = cookie, donc c'est bon normalement)

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

ne pas proposer de ne pas stocker l'id_auteur si jamais on utilise l'id_auteur pour identifier une réponse et qu'en plus on a besoin d'identifer une réponse

dire supprimer l'id_auteur

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.

on conditionne au fait qu'on teste l'unicité d'un champ

mettre la case rafraichir le cache avant affichage résumé de la réponse, juste pour des raisons esthétiques