Formidable, le générateur de formulaires

23 janvier 2012 – par Maïeul, RastaPopoulos – 2737 commentaires

1
2
3
4
5
184 votes

Un générateur de formulaires facilement configurable pour les non-informaticiens et facilement extensible pour les développeur⋅euses.

Sommaire

Introduction

Historiquement, deux plugins avaient déjà été développés précédemment pour gérer des formulaires :

  • Forms &Tables, qui n’a pas été complètement porté pour SPIP 2.
  • et spip-formulaire créé par artego mais qui n’était plus maintenu.

La question s’est donc posée : construire sur la base d’un des deux plugins ou repartir de zéro ?
Form &Table, très complet pour les utilisateurs, présentait l’inconvénient d’avoir un côté « fourre-tout » qui le rendait difficilement modifiable et difficile à personnaliser par les dévs.

Il a finalement été décidé de repartir de zéro pour proposer quelque chose :

  • de plus facile à utiliser pour les utilisateurs d’une part,
  • mais aussi de plus facile à personnaliser pour les développeur⋅euses.
    Avec le parti pris de se baser de préférence sur plusieurs petits plugins spécialisés et de tirer parti de la nouvelle norme CVT.

Interface utilisateur

L’utilisation basique de l’interface est abordée dans ce screencast : Mon premier formulaire pas à pas : c’est Formidable !

Appeler mon formulaire

Vous devez appeler le formulaire ayant le nom « formidable », en lui passant en paramètre l’identifiant de votre formulaire.

Dans un contenu
Utilisez le modèle <formulaire> classique : <formulaire|formidable|id=34> ou bien <formulaire|formidable|id=contact>

Dans un squelette
#FORMULAIRE_FORMIDABLE{34} ou bien #FORMULAIRE_FORMIDABLE{contact}

Afficher les résultats du formulaire

Dans un contenu
Utilisez le modèle <formulaire_analyse|id_formulaire=34>

Pré-remplir dynamiquement les champs d’un formulaire

À noter, vous avez la possibilité de surcharger dans l’appel, les valeurs par défaut des champs de votre formulaire. Pour cela, vous devez passer un tableau de nom=>valeur en deuxième paramètre. Vous pourrez trouver les noms de vos champs dans l’aide-mémoire situé sur la page de configuration des traitements.

Dans un contenu
Le tableau de valeurs dans un paramètre defaut sous forme d’une suite de chaînes « clé,valeur » séparée par des virgules :
<formulaire|formidable|id=contact|defaut=hidden1,valeur,input_5,autrevaleur>

Dans un squelette
Le tableau en deuxième paramètre :

  1. #FORMULAIRE_FORMIDABLE{contact, #ARRAY{nom_du_champ, Ma valeur}}

C’est particulièrement utile pour remplir un champ caché avec une valeur dynamique venant du squelette :

  1. #FORMULAIRE_FORMIDABLE{contact, #ARRAY{hidden_1, #ID_DOCUMENT}}

Pré remplir les champs depuis une ancienne réponse

Si les réponses sont enregistrées, on peut passer en troisième argument un identifiant de réponse.

  1. #FORMULAIRE_FORMIDABLE{contact,'',23}

pour modifier la réponse 23.

Champs oui-non et case unique

Pour rendre obligatoire la réponse « oui » à un champ de type oui-non ou case unique (pour la validation de conditions d’utilisation par exemple), il faut simplement rendre le champ obligatoire.

Courriels de notification

Une option des traitements proposés permet d’envoyer un mail de notification automatiquement, à chaque saisie d’un formulaire.

Le squelette par défaut employé pour la mise en forme de ces mails est plugins/formidable/notifications/formulaire_email.html. Vous pouvez le copier dans le répertoire ’notifications’ de votre squelette et l’y modifier à votre guise. Cette modification vaudra pour tous les formulaires.

Pour utiliser un squelette spécifique pour les mails de notification de l’un seulement des formulaires définis avec Formidable, il suffit d’ajouter son squelette dans le répertoire ’notifications’ de votre dossier squelettes, mais en ajoutant l’identifiant.

IDENTIFIANT étant l’identifiant du formulaire défini dans Formidable, les squelettes doivent se nommer :
formulaire_IDENTIFIANT_email.html pour le mail aux destinataires
formulaire_IDENTIFIANT_accuse.html pour l’accusé de réception du visiteur

Conservation des IP

Les adresse IP des personnes répondant aux formulaires sont stockées en base de donnée. Depuis la version 1.5 (SPIP 3) / 0.7 (SPIP < 3), elle sont automatiquement hashé, de manière à ce que l’IP ne soit plus reconnaissable, au bout de 124 jours (environ 4 mois).

Pour changer ce délai, vous pouvez redéfinir la constante _CNIL_PERIODE dans votre fichier mes_options.php.

Par exemple :

  1. define('_CNIL_PERIODE', 24*3600);

permet de hasher les IP toutes les 24 heures.

Si vous voulez désactiver le hashage, mettez la valeur à 0.

Envoi de fichiers

Lire l’article complémentaire : Envoyer des fichiers avec un formulaire Formidable.

Voir aussi sur le wiki


-  Complément de doc et exemples sur les boucles et balises de formidable
-  Exemples de stylage CSS d’un formulaire Formidable
-  todoFormidable
-  Formidable, présentation aux Grottes (2010)

Dernière modification de cette page le 28 mai 2019

Discussion

5 ans 1 an 3 mois Sans limite
Par date
Filtrer

663 discussions

  • Chrys

    Bonjour,

    J’aimerai savoir si avec Formidable on peut créer un formulaire comme ce qui suit.

    À vrai dire, j’ai déjà créé le formulaire que je souhaite avec l’aide d’un intervenant du forum spip. Mais celui-ci ne fonctionne pas comme attendu.
    Il est visible ici : https://www.the-ghost-bassist.com/bootsy-collins-i-m-leavin-u
    Vous pouvez le tester avec toto@free.fr

    Il s’agit pour les visiteurs de remplir quelques champs pour voir apparaître une ligne lui permettant de télécharger un fichier (zip ou RAR).
    L’admin lui, devrait recevoir une alerte mail lui indiquant le nom du fichier télécharger, le nom et email du visiteur.

    Est ce possible !?

    Merci

    Chrys

    Répondre à ce message

  • 12
    Bert75

    Bonjour,

    Désolé de cette question de débutant, mais je n’ai pas trouvé moi-même la réponse :
    Le retour de formulaire que je reçois est visiblement en HTML, peu facile à lire (beacoup de lignes vides, pas d’alignement etc) et à exploiter (automatiquement), donc je pense que tout le monde a du modifier ce comportement par défaut ;-)

    J’utilisais avant (pas sous SPIP) un php qui faisait les traitements & verifs puis le POST et j’envoyais simplement en PLAINTEXT la liste des champs remplis (non vides) sous la forme :

    [nom_du_champ] [hor_tab] [Valeur_entrée] [NewLine]
    par exemple :
    Name Franck TOTO
    Email moi@truc.com
    Expert On
    CallMe On

    (et terminé par l’@ IP, mais grâce à RealET, c’est bon maintenant sous formidable)

    Ce qui me permettait facilement d’exploiter manuellement ou d’extraire automatiquement les infos (c’est déjà du CSV tab separated).
    Je suis sûr que c’est possible avec formidable mais j’ai du rater qq chose...

    Merci d’avance !

    • RastaPopoulos

      Je ne comprends pas vraiment ce que tu veux faire, et je ne vois pas de quel « retour de formulaire » tu parles. À mon avis, avant Formidable, tu devrais d’abord comprendre, l’API « CVT » des formulaires de SPIP.

    • Bert75

      Je veux juste recevoir un email résultant du remplissage du formulaire qui a la forme (en plain text) décrite ci-dessus. Par exemple :

      Name Franck TOTO
      Email moi@truc.com
      Expert On
      CallMe On

      Ce que je reçois pour l’instant n’a PAS cette forme
      mais (en html) :

      Form « Contact form » sent on 09/09/2016 at 11:24:05.
      From this page.

      Your Name
      Bert75

      Job Function
      CTO

      Company
      My Company

      Address
      (no data entered)
      City
      PARIS

      Zip code
      75000

      Country
      France

      Email address
      moi@hotmail.com

      Telephone
      0123456789

      Interested by :
      Intellectual Property blocks
      Training Coursess
      Design Services
      Your message
      (no data entered)
      — -

    • RastaPopoulos

      Bah tu surcharges le squelette d’email pour faire autre chose. Il y a un chapitre juste au-dessus qui parle des squelettes d’email en donnant le chemin…

    • Bert75

      Génial !
      Pile ce qu’il me fallait.
      J’en profiterai pour supprimer les champs vides (totalement inutiles).

    • RealET

      Sauf que :
      D’une part, le notifications/formulaire_email.html contient un élément totalement obscur (une boite noire qui donne un résultat :

      1. #VOIR_SAISIES{#ENV*{saisies}, #ENV*{valeurs}}

      Et que d’autre part, le moyen de passer en plain-text le résultat est documenté où ?

    • Bert75

      « pile ce qu’il me fallait » était de l’humour, désolé !

      Et dans les features que j’aurais trouvé intéressantes :
      -  hook d’appel à script à la validation du formulaire
      -  captcha (oui, oui, je sais la religion de spip NOSPAM etc)
      -  insertions de textes custom dans l’email qui en facilite l’exploitation
      -  envoi à destinataire variable en fonction d’un champ
      -  champs conditionnels
      ...mais j’ai peut-être raté d’autres choses dans la doc.

    • RealET

      Dans traiter/email.php j’ai vu qu’il y avait :

      		$corps = array(
			'html' => $html,
			'texte' => $texte,
			'nom_envoyeur' => filtrer_entites($nom_envoyeur),
		);

      En tentant de remplacer par :

      1.         $corps = $texte;

      À ce moment-là, SPIP 3.1 prend le pas et transforme quand même le message en multipart HTML/Txt

      Bref, comment forcer Formidable + SPIP 3.1 à envoyer en text/plain ?

    • RastaPopoulos

      Et dans les features que j’aurais trouvé intéressantes :
      -  hook d’appel à script à la validation du formulaire
      -  captcha (oui, oui, je sais la religion de spip NOSPAM etc)
      -  insertions de textes custom dans l’email qui en facilite l’exploitation
      -  envoi à destinataire variable en fonction d’un champ
      -  champs conditionnels
      ...mais j’ai peut-être raté d’autres choses dans la doc.

      Il y a déjà des champs conditionnels. Le captcha tu le codes si ça t’amuse, mais personne n’a envie de ça, la religion du respect des utilisateurices oui on peut dire ça, c’est plutôt une fierté.

      Il n’y a pas de système de choix de destinataires suivant des tests sur d’autres champs arbitraires, par contre il y a déjà une saisie Destinataires qui permet de choisir un ou plusieurs parmi les comptes utilisateurs (s’il s’agit d’autres gens qui ne sont pas déjà dedans, il suffit de créer des comptes sans login, même en statut visiteur peu importe).

      Pour le reste oui tu as oublié des choses dans la doc : tu as oublié la doc générale de l’API CVT de SPIP. Comme déjà dit précédemment. Si tu ne connais pas ça, je vois mal comment tu pourrais espérer modifier des choses complexes dans Formidable spécifiquement ou n’importe quel autre formulaire de SPIP. Il y a déjà tous les points d’entrées qu’il faut, et il y a déjà des sous-plugins qui modifient ou augmentent de manière conséquente Formidable, donc il n’y a à priori aucun problème majeur.

      @RealET, avec Facteur TOUS les emails sont envoyés avec une variante HTML par défaut, et avec une variante texte ensuite, qui dérive de la variante HTML. On pourrait imaginer que la variante texte vienne d’un squelette si il existe et sinon le générer à partir du HTML. Mais dans tous les cas il y aura la variante HTML (et ça vaut pour absolument tous les emails dès qu’on a Facteur). Mais quel est le but final d’absolument vouloir avoir des emails text/plain uniquement ?

    • Bert75

      Pour faire court : SPIP est visiblement complexe, c’est pour ça que je n’ai décidé de l’adopter qu’en m’appuyant entièrement sur RealET pour tout ce qui l’est pas le contenu et l’exploitation du site. Donc ce n’est pas à moi d’apprendre la doc SPIP ni de programmer dans son langage, mais j’essaie quand même d’en comprendre le fonctionnement et de voir si j’ai vraiment besoin pour quelque chose d’apparemment simple (que je faisais moi-même avant) de faire appel à un ou plusieurs spécialistes.
      Il me semblait aussi que la présentation par défaut des emails de soumission (les forms remplis) n’était franchement pas conviviale, ni optimisée (champs vides, interlignes inutiles...), ni facile à exploiter (je ne parle pas de les regarder sur un smartphone !).
      D’où ma question sur ce forum. Ca me semble une amélioration nécessaire. En tous cas SPIP+Formidable -je ne sais pas qui est le coupable original- représente de ce fait une régression pour moi.
      J’espère que RealET va trouver une solution.

    • RastaPopoulos

      Bééé, si c’est apparemment si simple d’avoir un système de téléformulaire où on peut construire un form à la souris et pouvoir le modifier quand on veut sans rien coder… c’est super ! :D Go go

      Pour ce qui est de réellement exploiter les résultats, de manière carrée et pérenne, on préférera quand même clairement enregistrer en base et pouvoir exploiter les tables (qui ont même déjà un export CSV dans l’admin…), que des emails qui sont là juste pour notifier, pour des humains.

    • RealET

      L’affichage compact du mail est intégré : http://zone.spip.org/trac/spip-zone/changeset/99576

      C’est donc désactivé par défaut, et activable via mes_options.php :
      Ajout d’une option pour avoir un affichage compacte et sans les réponses vides (admin & mails de confirmation).
      Dans mes_options.php, rajouter :

      if (!defined('_SAISIES_AFFICHAGE_COMPACT'))
	define('_SAISIES_AFFICHAGE_COMPACT', 'oui');
    • DD

      Merci realET
      Ce code pour compacter le contenu des emails est bien utile et m’évite d’avoir à coder une page formulaire_email.html (le client avait la demande pertinente de réduire le nombre de pages d’impression des réponses).

    Répondre à ce message

  • 12
    DD

    Sur un site en 2 langues je n’arrive pas à faire afficher le texte du bouton de validation d’un formulaire :
    Si je mets <multi>[fr]Envoyer[en]Submit</multi> dans la config des options globales il m’affiche
    <multi>[fr]Envoyer[en]Submit</multi> texto sur le site public

    Pour les autres champs du formulaire j’ai bien le bon texte de langue qui s’affiche.

    • Maïeul

      La version 3.37.8 corrige cela.

    • DD

      Merci. Est-ce voulu si le texte du bouton de validation par défaut est « Enregistrer » et non plus « Envoyer » ?

    • Maïeul

      C’était « valider » avant et pas « envoyer ». C’est le passage en multi etape/la réécriture du code pour les options globales qui a provoqué ce chagement de chaîne de langue. Je ne sais pas si c’est volontaire ou pas, mais je trouve ca pas plus mal, perso.

    • RastaPopoulos

      Ah oui désolé, c’est dans ce commit dans ce fichier :
      https://zone.spip.net/trac/spip-zone/changeset/114460/spip-zone/_plugins_/formidable/trunk#file4

      Avec du coup une reprise du code de ce qui était depuis des années dans la génération automatique faite par Saisies (quand on ne déclare qu’en PHP), et qui n’avait jamais été reporté dans Formidable.

    • guilaind

      Question bête : comment utiliser la fonction multi-étapes ?
      J’ai lu avec intérêt la phrase d’explication et coché l’option

      Lorsque cette option est active, chaque groupe de champs de premier niveau est transformé en étape du formulaire.

      Néanmoins, je ne vois pas à quel endroit je peux déterminer le niveau d’un groupe.
      J’ai pourtant créé plusieurs champs (texte/email) dans cet ordre
      -  groupe de champs « page 1 »
      -  champ 1
      -  champ 2
      -  groupe de champs « page 2 »
      -  champ 3
      -  champ 4

      Et tous les groupes & champs s’affichent sur une seule page au lieu de deux

      D’avance merci

    • RastaPopoulos

      Tu as posé ta question dans un fil existant qui n’a pas de rapport, ce n’est pas très pratique.

      Mais ya rien de plus à faire, et en plus si tu vois l’option c’est bien que tu es à jour de Saisies et de Formidable à priori. Tu crées des groupes, tu mets des champs dedans, puis tu coches l’option, et hop c’est tout, le formulaire est alors en étape.

      Après t’es peut-être pas repassé par admin_plugin entre temps pour que ça mette à jour les utilisations de pipelines, après tes mises à jour…

    • guilaind

      Merci pour ta réponse.
      Si mon message apparaît dans un fil c’est indépendant de ma volonté : hier j’allais vraiment répondre à ce fil et avais préparé du texte sans cliquer sur « confirmer l’envoi ». Aujourd’hui je suis revenu sur la page et suis allé sur la case commentaire en bas de page (comme si j’allais débuter un nouveau fil) qui était pré-remplie : j’ai effacé ce texte et remplacé par du nouveau mais mon commentaire s’est inséré au mauvais endroit. Une fois publié je ne peux rien faire, même pas supprimer mon commentaire pour le recréer au bon endroit.
      Je bidouille depuis un temps certain pour comprendre et je pense avoir trouvé en utilisant « position du champ ». La fonctionnalité est super, néanmoins sa mise en oeuvre est laborieuse...

    • RastaPopoulos

      Déjà 1) le champ position sert juste quand t’as pas JS, t’as bien vu que tu pouvais déplacer les champs en drag-n-drop déjà ?

      Et 2) quand tu crées un champ (et donc y compris les groupes de champs) ils sont déjà de base à la racine du formulaire, donc au quoi yorait à jouer avec ça ? Si t’as crées des groupes, ils sont déjà au bon endroit par défaut (ils sont pas à l’intérieur d’un autre groupe quoi, ya pas d’imbrication).

    • guilaind

      ça c’est la théorie. J’ai fait comme d’hab, à savoir créer mes champs & groupes dans le bon ordre et le résultat était que tous les champs était sur la même page au lieu d’être en plusieurs étapes.

      Le drag & drop place un champ sous un autre alors qu’il faut qu’il soit en décalé. Voir la partie gauche de ma copie d’écran. pour la parti droite elle reproduit ce qu’on voit en partie publique

    • RastaPopoulos

      Non non, on peut parfaitement déplacer un champ à l’intérieur d’un groupe de champ en drag-n-drop. Le rectangle cible n’est pas le même et on doit bien voir qu’il est décalé à l’intérieur du groupe.

    • guilaind

      Certes, néanmoins la nuance n’est identifiable que si on le sait.
      Si j’avais le temps j’essaierais d’améliorer le « mode d’emploi ». Un jour...

    Répondre à ce message

  • 1
    AlainF

    Bonjour et bravo pour tout ce boulot,
    J’ai fais un formulaire où il est important (mais ce n’est pas possible de le mettre en obligatoire) d’ajouter une photo de la plaque d’identité du matériel, pour une demande de pièces détachées.

    Pour la présentation du formulaire, je souhaiterais insérer une photo d’exemple avant le champ « Fichier »
    Ne dit-on pas :un petit schéma vaut mieux qu’un long discours !

    Merci de votre intérêt pour ma question, je pense que ça peut servir à d’autres
    Alain

    • AlainF

      En attendant, j’ai simplement inclus dans mon champ explication, de la même façon que dans un article, un doc déjà présents dans ma médiathèque.

      Comme quoi il faut rédiger la question pour y répondre soi-même...

      Mais si il y a une autre solution !!!

    Répondre à ce message

  • 2
    Rpnpif

    Bonjour,

    Je voudrais rendre permanent le fichier csv des réponses et le générer automatiquement, le rendre accessible de l’extérieur afin de géolocaliser les réponses.

    De même je voudrais déplacer les fichiers téléversés vers IMG par exemple.

    J’avoue patauger sur la méthode malgré mes recherches surtout que je suis un débutant en programmation SPIP.

    Auriez-vous une piste ?
    Cordialement.

    • Maïeul

      Concernant le CSV, vous pourriez créer votre squelette qui le générerait.

      Concernant le déplacement vers IMG : c’est une fonction demandée plusieurs fois. Il est clair que pour des raisons de confidentialité, cela restera une option. Il faudrait trouver un peu de temps pour coder cela. Peut être en juin j’en aurait.

    • Rpnpif

      Merci beaucoup. Je vais suivre cette piste.

      Oui une option avec un avertissement sur le risque est la meilleure solution.
      Merci pour la proposition.

    Répondre à ce message

  • 3
    bruno31

    Bonjour

    Sans que je ne touche à quoi ce soit sur le site ou dans la définition du formulaire, soudainement mon formulaire ne veut plus prendre de réponse : Impossible de prendre en compte votre message. Merci de le soumettre à nouveau !

    Répondre à ce message

  • 2
    Jean Christophe Villeneuve

    Bonjour

    Sur un site, une collègue a conçu un formulaire.
    Elle a configuré ce formulaire pour recevoir une notification à chaque réponse et ça fonctionne.
    Elle voudrait aussi que le visiteur qui répond reçoive un message de confirmation par mail (en plus du message de retour qui s’affiche). Il y a bien un champ « adresse mail » obligatoire dans ce formulaire.
    Est-ce possible ? Et si oui, comment ?

    Répondre à ce message

  • 2
    Florence HENRY

    J’ai pu reproduire le problème du non respect de l’unicité quand un auteur tente de modifier une réponse qui n’est pas la sienne (et que l’identification est id_auteur).

    Voilà le formulaire problématique :

    id_formulaire : ’13’
identifiant : test_multi
titre : ’test multi auteurs’
descriptif : ’’
css : ’’
message_retour : ’’
saisies :
  -
    saisie : input
    options :  nom : input_1, label : ’Ligne de texte’, size : 40, sql : ’text DEFAULT ’’’’ NOT NULL’ 
    identifiant : ’@5ce2bc8d3d2c9’
traitements :
  enregistrement :
    moderation : posteriori
    multiple : on
    modifiable : on
    effacement : ’’
    effacement_delai : ’’
    identification : id_auteur
    variable_php : ’’
    unicite : input_1
    message_erreur_unicite : ’’
    anonymiser : ’’
    ip : ’’
    invalider : on
    resume_reponse : ’’
    analyse_exclure_champs : ’’
public : non
statut : publie
maj : ’2019-05-20 17:31:31’
apres : formulaire
url_redirect : ’’
date_creation : ’2019-05-20 16:42:04’

    Voilà comment reproduire le bug :
    -  L’auteur 1 enregistre une réponse « toto » (id 123)
    -  L’auteur 2 affiche le formulaire rempli avec la réponse 123
    -  L’auteur 2 valide le formulaire sans changer la réponse « toto »
    -  Une nouvelle réponse est créée avec « toto » comme réponse, et l’unicité n’est pas respectée

    Alors que si l’auteur 2 affiche un formulaire vierge et indique « toto », le test d’unicité est appliqué et la réponse est bien refusée.

    Voilà aussi le squelette utilisé modeles/testmulti.html :

    [(#REM) on recupere l'identifiant]
#SET{id_form,0}
<BOUCLE_form(FORMULAIRES){identifiant=test_multi}>
#SET{id_form,#ID_FORMULAIRE}
</BOUCLE_form>
 
[(#ENV{id_reponse}|oui)
   #FORMULAIRE_FORMIDABLE{#GET{id_form}, #ARRAY, #ENV{id_reponse}}
]
 
[(#ENV{id_reponse}|non)
   #FORMULAIRE_FORMIDABLE{#GET{id_form}}
]
 
<hr>
 
<B_rep>
<ul>
<BOUCLE_rep(FORMULAIRES_REPONSES){id_formulaire=#GET{id_form}}>
   <li><a href="[(#SELF|parametre_url{id_reponse, #ID_FORMULAIRES_REPONSE})]">#VOIR_REPONSE{input_1, brut}</a></li>
</BOUCLE_rep>
</ul>
</B_rep>
    • Florence HENRY

      Sans regarder le code, je pense comprendre ce qui se passe :
      comme on édite une réponse existante, le test d’unicité est valide.

      C’est seulement ensuite que l’autorisation de modifier la réponse est examinée, et que la décision est prise d’enregistrer une nouvelle réponse au lieu de modifier l’existante.

      On enregistre alors une nouvelle réponse avec un doublon.

    • Maïeul

      bon j’essaie de voir tout cela se week-end

    Répondre à ce message

  • Florence HENRY

    Enfin (et ce sera tout pour ce soir), il y a un bug quand on configure un formulaire avec « Ne pas conserver l’identifiant de la personne connectée. »

    Si on change d’avis (après enregistrement des traitements) et qu’on rend le formulaire « Modifiable » avec id_auteur comme méthode d’identification, le champ « Ne pas conserver l’identifiant de la personne connectée. » est caché, mais il reste coché :

    id_formulaire : ’13’
identifiant : test_multi
titre : ’test multi auteurs’
descriptif : ’’
css : ’’
message_retour : ’’
saisies :
  -
    saisie : input
    options :  nom : input_1, label : ’Ligne de texte’, size : 40, sql : ’text DEFAULT ’’’’ NOT NULL’ 
    identifiant : ’@5ce2bc8d3d2c9’
traitements :
  enregistrement :
    moderation : posteriori
    multiple : on
    modifiable : on
    effacement : ’’
    effacement_delai : ’’
    identification : id_auteur
    variable_php : ’’
    unicite : input_1
    message_erreur_unicite : ’’
    anonymiser : on
    ip : ’’
    invalider : on
    resume_reponse : ’’
    analyse_exclure_champs : ’’
public : non
statut : publie
maj : ’2019-05-20 22:58:31’
apres : formulaire
url_redirect : ’’
date_creation : ’2019-05-20 16:42:04’

    Note :

        modifiable : on
    identification : id_auteur
    anonymiser : on

    Du coup, quand on enregistre une réponse, c’est id_auteur = 0 qui est enregistré.

    Il faudrait juste décocher la case « Ne pas conserver l’identifiant de la personne connectée » quand on la cache.

    Répondre à ce message

  • 4
    Florence HENRY

    Bonjour

    Je rencontre un problème à la modification d’une réponse quand une personne A modifie une réponse d’une personne B.

    Mon formulaire est configuré pour avoir des réponses multiples, et je passe par un modèle pour pouvoir modifier les réponse :

    [(#ENV{id_reponse}|oui)
  #FORMULAIRE_FORMIDABLE{#ENV{id_form}, #ARRAY, #ENV{id_reponse}}
 
  <p>
  <a href="[(#SELF|parametre_url{id_reponse,''})]">retour à la liste des entités</a>
  </p>
]
 
[(#ENV{id_reponse}|non)
  [(#INCLURE{fond=modeles/entites_liste,env,id_form=#ENV{id_form}})]
]

    Quand il y a dans l’URL id_reponse=1234 ça permet de modifier la réponse. Sinon, ça affiche la liste des réponses.

    Tant que c’est la même personne qui entre une valeur par le formulaire et qui modifie, aucun souci.

    Quand « A » modifie une réponse saisie par « B », voilà ce qui se passe :
    -  une nouvelle réponse est enregistrée pour le formulaire
    -  en ne vérifiant pas les clauses d’unicité (j’en ai une sur un input_1)
    -  par la suite, ni « A » ni « B » ne peuvent plus modifier leurs réponses car la clause d’unicité est appliquée

    J’ai tenté de cocher « Ne pas conserver l’identifiant de la personne connectée. » mais ça ne change strictement rien. L’id_auteur est toujours enregistré dans la table spip_formulaires_reponses

    Comment faire pour ignorer l’id_auteur et permettre la modification par un autre auteur ?

    • Maïeul

      Hum, je ne reproduis pas ce bug. Si j’ai dit de ne pas tenir compte de l’identifiant, Est-ce unformulaire qui date d’avant décembre ? Il y a eu une reecriture du code sur cette fonctionnalité là à ce moment, et peut etre qu’un souci dans la migration.

      Par contre, il y dans tous les cas une vérification que l’internaute est bien l’auteur de la réponse : soit par id_auteur, soit par cookie, soit par une autre variable PHP. Je viens d’ajouter dans la version 3.38.0 une option où le passage explicite de l’identifiant de réponse suffit à l’identification.

      Reste juste ta question de l’unicité du champ, mais je ne suis pas sur d’avoir compris le problème.

    • Florence HENRY

      Merci pour ta rapidité !

      Par contre, quand je sélectionne id_formulaires_reponse dans la partie « Configuration des traitements », j’obtiens cette erreur après la validation de la page :

       :Pri:ERREUR : Erreur 1064 de mysql : You have an error in your SQL syntax ; check the manual that corresponds to your MariaDB server version for the right syntax to use near ’ORDER BY date’ at line 6
in /www/spip3/plugins/auto/formidable/v3.38.0/inc/formidable.php L210 [sql_allfetsel(),formidable_verifier_reponse_formulaire(),formidable_trouver_reponse_a_editer(),formulaires_formidable_charger_dist(),call_user_func_array(),formulaire__charger(),balise_FORMULAIRE__contexte(),balise_FORMULAIRE__dyn(),call_user_func_array(),traiter_formulaires_dynamiques()]
SELECT id_formulaires_reponse
FROM `intranet`.spip_formulaires_reponses
WHERE (id_formulaire = 4)
        AND (statut = ’publie’)
        AND                              <--- l’erreur est là
ORDER BY date

      Mais ça n’empêche pas le formulaire de fonctionner.

      Concernant mon problème de double réponse, je vais tenter de reproduire le problème avec un formulaire simple.

      Florence

    • Maïeul

      a oui, la version 3.38.1 corrige cela.

    • Florence HENRY

      Nickel ! Plus de message d’erreur.

    Répondre à ce message

Ajouter un commentaire

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom