Très légère modification de la signature des mails de notification pour mieux respecter les standards en la matière

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)

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

Ding ding ding, il est 3h00, c'est l'heure de permettre de poster une réponse Formidable par API Collection+JSON ! En plus des champs du formulaire (input_1, etc), il faut rajouter 'id_formulaire' dans les 'data' envoyés. Après ça teste l'autorisation du coup, et c'est parti pour verifier() et traiter(). On repart avec un 201 et le retour en JSON de la nouvelle réponse créée.

On donne accès en lecture aux formulaires et aux réponses en Collection+JSON. Plus tard le postage de réponses à un formulaire, en écriture donc.

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.

On ajoute deux pipelines qui permettent d'étendre l'export des réponses : un pour les titres de colonnes, et un pour chacune des réponses.

Dans un formulaire, quand on choisit de réafficher à l'utilisateur les valeurs qu'il a saisi, on ne veut pas lui montrer les <hidden>. Up de z : version 2.9.15

Ferme #3735

http://zone.spip.org/trac/spip-zone/browser/_plugins_/verifier/paquet.xml?rev=54497
J'en profite pour mettre yaml en 1.5.2 car la version 1.5.0 posait problème avec spip, la version 1.5.1 pourrait être suffisant, mais je mets la 1.5.2 car l'unique différence entre les deux version, c'est que la 1.5.2 est compatible spip 3.0.x et 3.1.x
http://zone.spip.org/trac/spip-zone/changeset/74084/_plugins_/yaml

+ pas de formulaire dans une boite dans la colonne extra des analyses

on accede aux reponses quelles que soit leur statut, mais a l'analyse uniquement si il y a une reponse publiee au moins
+ eviter les liens redondant vers soi meme dans la colonne de gauche

Plein d'accolades pour la syntaxe dans ce fichier, de l'indentation, et deux vérif que l'id est bien un entier.

Fix https://core.spip.net/issues/3617 : passer $set a objet_modifier_champs pour qu'elle ne detecte les conflits sur $_POST que quand c'est pertinent

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.

Retour avec message d'erreur si aucune réponse exportée.

Ajout de l’identifiant du formulaire courant dans les appels à #AUTORISER pour permettre un controle d’accès par formulaire.

bugfix utilisation des div au lieu de ul/li dans les formulaires en SPIP 3.1+, necessite saisies 2.3.0 minimum

pour un admin restreint à partir du formulaire de configuration de
Formidable et non plus à partir d'une variable globale

r84696 avait cassé le modèle <form> quand on a PAS form&table puisque la table FORMS n'existe alors pas/plus

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

Revision de la fonction affiche_resume_reponse introduite par r84737 pour lui faire interpreter les champs.
C'est un peu lourd de passer par saisie pour reformater ensuite le HTML en texte brut mais faisons au plus simple.
On ajoute un pipeline qui permet de faire des petites mises en forme perso sur les champs au besoin (ou sur l'affichage de la reponse).

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.

Cf : http://thread.gmane.org/gmane.comp.web.spip.zone/36491