Doublon de réponses à un questionnaire : Bonjour, j’ai construit une table avec des listes de choix de réponses pour chaque question, ainsi qu’un formulaire d’enquête lié à la table. Lorsque je teste mon formulaire une première fois, puis une seconde fois, deux lignes de réponses vont s’afficher dans ma table. Comment limité le remplissage de l’enquête qu’une fois, pour éviter les doublons ? Du fait du contexte d’anonymat, je ne souhaite pas ajouter une clé d’utilisateur unique, sauf si je n’ai pas le choix.
Bonjour et bienvenue sur le forum !
Pour bien comprendre votre question, comment définissez-vous un doublon dans cet exemple ? Est-ce que vous voulez que chaque option ne puisse être choisie qu’une seule fois ? Ou que chaque combinaison d’options ne puisse être choisie qu’une seule fois ? Etc.
N’hésitez pas à joindre des captures pour qu’on ait le maximum de contexte 
Pour bien comprendre, le plus simple est de vous envoyer des images :
- La table avec mes réponses sur deux lignes, après avoir renseigné et enregistré l’enquête de satisfaction une première fois, puis une seconde fois…
- Le formulaire destiné aux sondeurs
Quelles propositions simples me proposeriez vous pour qu’une fois le questionnaire renseigné, si jamais je décide de le remplir de nouveau et de le valider, j’ai en retour un message qui m’informe que l’enquête a déjà été renseigné, pour éviter qu’une seconde ligne de réponses s’affiche, comme dans la table de l’image, sans forcément ajouter une nouvelle table des noms des enquêteurs, pour respecter l’anonymat ?
Je crois avoir compris ! Vous souhaitez qu’une personne ne puisse pas répondre deux fois à l’enquête, c’est ça ? Tout en permettant à plusieurs personnes de répondre (auquel cas plusieurs lignes vont se créer dans votre table de données, c’est la logique intrinsèque de Grist)…
Je pense à une solution qui ne respecterait pas tout à fait l’anonymat mais ne collecterait pas plus de données à caractère personnel : si vous avez une liste email des personnes qui doivent remplir l’enquête, vous pouvez vous débrouiller pour ajouter un identifiant unique dans chaque lien de formulaire et identifier ainsi les répondants. Ensuite, il vous suffit d’une permission avancée pour bloquer la réponse d’une personne ayant déjà répondu une fois (en vérifiant à l’aide d’une formule si l’identifiant unique existe déjà dans la table).
Qu’en pensez-vous ?
vous pouvez prévenir vos répondants que seule la dernière réponse reçue sera retenue, et vous nettoyez vos bdd à la fin de la campagne
Merci. Si je comprends j’importe une table comprenant la liste email de l’ensemble des enquêteurs et j’y rajoute un identifiant unique. Ensuite je la lie à l’autre table des réponses qui contient également le même identifiant unique ? Pour ajouter un ID unique, quelle est la formule ?
Comment je procède pour obtenir une permission avancée pour bloquer la réponse d’une personne ayant déjà répondu ?
Merci d’avance et passez une agréable journée, Didier
Pas simple d’être reconnu tout en restant anonyme !
Assumons que le répondant est avant tout un utilisateur connecté.
Une manière de procéder serait :
- Passer le tableau en édition publique + les droits qui vont bien pour limiter à la seule création de nouvelle ligne.
- Définir une formule d’initialisation basée sur une fonction de hashage pour convertir user.Email en un hash non réversible avant stockage. Ce sera le même pour lui à chacune de ses visites tout en garantissant “raisonnablement” que son identité ne sera pas simple à retrouver.
- Utiliser le widget formulaire interne, ou une classique vue en fiche comme formulaire
- Par formule, détecter dans la table un doublon sur le hash et bloquer les saisies suivantes par droit + un widget Markdown pour afficher un message (colonne formule sur la ligne pour afficher ce message)
J’explique les étapes correspondant à ce modèle que je mets à disposition :
1. Préparer le formulaire
Créer une table Réponses ayant au moins une colonne Répondant et créer une vue formulaire ayant les propriétés suivantes pour le champ Répondant :
N.B. : La table Répondants n’existe pas encore, elle arrive juste après.
Copier l’URL du formulaire publié, valeur qui devra remplacer URL_DU_FORMULAIRE dans la suite.
2. Préparer la liste d’envoi
Créer une table Répondants avec au moins quatre colonnes :
| Adresse email | Hash | Lien de formulaire | Compte |
|---|---|---|---|
| Type texte | Formule donnée tout en bas de cette page | Formule f"URL_DU_FORMULAIRE?Repondant={$Hash}" |
Formule len(Reponses.lookupRecords(Repondant=$Repondant)) |
3. Bloquer les doubles réponses dans les permissions avancées
Dans les permissions de la table Réponses, ajouter une ligne newRec.Compte > 1 avec les permissions U barré et C barré.
A partit du moment où la réponse s’effectue dans le tableau et non dans un formulaire public, on peut même s’affranchir de cette étape de préparation via une table utilisateurs et de la gestion de liens personnalisés.
Concrètement, vous ne diffusez qu’un seul lien (celui de la vue contenant le formulaire intra ou la fiche servant de formulaire). L’utilisateur devra nécessairement être connecté pour y répondre.
Dans la table des réponses, il faudra ajouter 1 colonne de type texte, avec la formule d’initialisation suivante :
import hmac
import hashlib
# Etape de salage, on introduit un ID du tableau
secret = (str($_table).split('at ')[1])[:7]
valeur_a_hasher = user.Email
hmac_result = hmac.new(
secret.encode('utf-8'),
valeur_a_hasher.encode('utf-8'),
hashlib.sha256
).hexdigest()
hmac_result
Cette formule utilise un hash mixant un identifiant utilisateur (ici son adresse mail) avec un identifiant propre au tableau (visible dans les formules, mais pas facilement d’un visiteur).
De la sorte, on obtient une empreinte unique pour l’utilisateur x ce tableau.
Cela signifie que la même méthode pour le même utilisateur dans un autre tableau aboutira à un autre hash, donc rendra impossible toute de croisement des utilisateurs entre tableaux différents.
Note : le hash est une opération non-inversible (i.e. on ne peut pas appliquer sa fonction inverse pour retrouver le texte original en clair), mais elle n’est pas à toute épreuve. Dès lors qu’un tiers a accès au carnet d’entreprise + la méthode de hash + connaît l’ID tableau, il peut fabriquer une table de correspondance en recalculant tous les hash, puis les comparer aux réponses pour en déduire les auteurs.
Néanmoins on peut considérer cette pseudonymisation comme raisonnablement suffisante pour empêcher les tentative basiques de désanonymisation/croisement.
P.S. pour les experts de Grist : d’après les vérifications sommaires que j’ai pu effectuer, cet ID de tableau est en réalité un ID pour la table. Cette valeur semble volatile entre session, à l’exception des 7 premiers caractères. Ceux-là paraissent stable pour un même tableau, a priori aussi entre sessions, et changent pour les copies du tableau, mais ça demande à être confirmé (je crains qu’il soit en partie lié à un état interne du serveur susceptible de changer en cas de redémarrage ou upgrade). Si vous avez connaissance d’un ID interne de meilleure qualité, je suis preneur.