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

Exemple d'emploi: un site qui gère des inscriptions à des évènements,
avec plusieurs dates possibles, pour modifier directement les infos sur la date de l'evenement retenue si la personne change d'avis.

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

Utiliser objet_modifier plutôt que sql_updateq pour générer une révision quand on modifie les traitements ou les saisies.
La restauration de révisions ne fonctionne pas pour autant, mais c'est un autre problème à régler.

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.