décide s'il affiche ou pas son message spécifique, en connaissant par
ailleur le message general.

Up de y.
Fix #58 (again !)

Puisque maintenant le javascript est à part, on peut mettre une case à
cocher pour demander d'afficher explicitement les messages de retour de chaque
traitement si jamais on a défini un message général.

Au passage on déclare bien les jointures pour tout le monde comme pour les docs aussi, et le champ vu en exception pareil

Issue 42 : améliorer la liaison des formulaires avec un champ vu comme pour les documents : il FAUT savoir quels liens ont été mis à la main et lesquels sont automatiques suivant les modèles dans les textes. Surtout qu'il y avait un bug : ça virait les liens même ceux mis à la main si on les trouvait pas dans les textes. Maintenant ça fait tout comme les documents : si le form n'est plus en modèles dans les textes, ça passe juste en vu=non, mais le lien reste.

date_soumission devient date_envoi, plus proche du langage courant, tout
en évitant de confondre avec date_reponse qui pourrait être la date de
l'objet.
On fait pas de migration de structure SQL car il s'agissait d'une branche de dev qui n'a existait que 24h et n'a a priori été déployé que chez le dev.

issue #32 champ date_soumission : déclaration + installation + remplissage avec la date actuelle si on est sur une ancienne version

On profère l'appelation date_soumission à date_reponse car date_reponse
est peu clair, puisque c'est un champ d'un objet _reponse.
date_soumission permet de dire : "là date à laquelle la réponse a été
soumise"

oups

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.

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

Etape 2: séparer clairement l'id_auteur de la variable php d'identification + migrer les données et traitements existants

enregistrées correspond au seul traitement "enregistrement".
On déplace donc la config dans les réglages de ce traitement.
La migration des réglages est prévues lors de la mise à jour du plugin.

- un statut poubelle -> est supprimé
- un statut refusé -> n'est pas supprimé
Ca correspond en gros à ce qui existe pour les articles

Ajouter un champ CSS aux formulaires… pour permettre de rajouter des classes CSS sur les formulaires.

Après des années avec une table de liaison générique, on ajoute enfin le formulaire editer_liens… uniquement sur les objets configurés pour ça évidemment.

Ferme #3735

Formidable 2.9.4 : On permet d’avoir un champ où les valeurs sont uniques. Par exemple un champ email où 2 personnes ne peuvent pas remplir le même email.

Les listes de reponses sont par defaut non signifiantes car n'affichant aucune autre information que la date de saisie et l'IP source.
On permet de configurer pour chaque formulaire une chaine qui sera utilisee pour afficher un resume de chaque reponse (les champs @input_1@.. etant remplaces par leur valeur).
Ceci rend les listes de reponse beaucoup plus utilisables.

spip.php?page=formulaire&id_formulaire=2&var_mode=recalcul

Statut archive (refuse) pour les formulaires : ils ne sont plus visibles en ligne mais on conserve le contenu et les reponses
+ la balise #FORMIDABLE n'affiche que les formulaires publies (ou prop en preview) dans le site public

Dans r80736 l'erreur c'était moi puisque je n'avais pas vu que traiter() serializait les valeurs multiples en une seule pour le stockage.
On retablit donc l'unicité de (id_formulaires_reponse,nom) en unifiant prealablement les éventuelles valeurs multiples importées de f&t, et en conservant la clé primaire qui n'est par contre pas inutile.

Corriger une erreur de structure SQL : la clé primaire sur id_formulaires_reponse,nom de la table spip_formulaires_reponses_champs empechait l'enregistrement de plusieurs réponses pour un même champ. Corrolaire : seul le premier choix des choix multiples (cases à cocher) étaient donc enregistrés.

On ajoute une clé primaire simple sur la table, ce qui a l'avantage de faire fonctionner la recherche de manière plus robuste, et on migre en renommant la table, la recreant, et transferant les donnees de l'ancienne vers la nouvelle.
Migration et installation validée en MySQL, à valider en SQLite (mais devrait être OK)

Lors de l'import f&t les formulaires sans réponses sont mis en statut proposé, les autres en publiés

on ajoute une recherche sur la page des reponses, ça ne marche qu'avec le patch http://core.spip.org/projects/spip/repository/revisions/21176

chaines de langue pour les statuts, liste des réponses plus claire, et filtrage des réponses par statut dans la page des réponses (onglets Toutes/A modérer/Validées/Supprimées)

afficher toutes les infos du formulaire sur la page de vue, l'aide memoire de la colonne extra ne s'affichait pas dans tous les cas, traitement propre sur le message de retour

squelette HTML du formulaire d'edition, declaration champs_editables et champs_versionnes dans l'API tables_objets_sql, nommage génériques et implémentation des fonctions de editer/formulaire (avec support des vieux nommages)
+ ajout d'une chaine de langue sur erreur de format
+ bugfix verification unicité de l'identifiant

Ajout d'une date de création du formulaire (nommée date_crea parce que date est un mot reservé mysql)
Incrémentation mineure de version et de shéma

Version 1.8.4 : report de r78009, passer le champ saisies de la table spip_formulaires en longtext pour permettre d'y stocker des formulaires longs

- déclarer 'spip_formulaires' en objet éditorial
- renommage des pages exec homogène avec le reste de SPIP : formulaires, formulaire  et formulaire_edit
- décoration des listes de formulaire aux nouvelles normes

Reste à gérer les réponses...

Petit inconvénient aussi, il fait du coup des urls propres pour les formulaires…

On décore d'un graphisme les analyses des réponses de formulaire en mettant des barres de progression et des pourcentages. Le code provient du module de sondage qu'on va intégrer directement dans formidable en créant un nouveau type de retour.