Bonjour à tous,

Voici un petit problème de comportement que je pose (je ne sais pas s'il avait été abordé avant), lors de la collecte des données, avec quelques idées de dev.

2 cas :
1/ En cas d'invitations : je m'étais aperçu sans trop de conséquences qu'une personne, si elle s'amusait à faire des allers-retours sur son questionnaire, apparaissait donc X fois dans les réponses enregistrées (incomplètes) jusqu'à ce qu'elle valide son questionnaire définitivement. Il existe donc ici une petite perte de temps au niveau du rapatriement des données pour checker les doublons... certes facile à repérer lorsque l'on ne met pas de mode anonyme...
>> Je ne sais si c'était prévu dans de futures versions de faire en sorte qu'à chaque connexion au questionnaire il y ait un update des réponses qui soit fait sur sa ligne de réponses directement ou de suppression des précédentes lignes écrites dans la base après du token par exemple ...


2/ En cas d'invitations en mode anonyme / ou en lien unique public ou non :
Mon point numéro 1 pose donc le problème de comment checker les éventuels doublons lorsqu'on administre une enquête selon ces 2 modes ... aucun à part l'adresse ip (mais qui dans certains cas ne s'avère pas suffisant - eg: enquête interne dans une entreprise où tous les utilisateurs passent par un même routeur...)
C'est donc embêtant pour la qualité des données collectées ...

>> Personnellement, j'utilise sur un autre système que j'avais développé (bcp plus rudimentaire que LS) un "unique ID" généré sous forme de cookie lors de la première ouverture du questionnaire et enregistré à chaque nouvelle connexion, ou réponse partielle ou totale.
Cela permet d'être complémentaire au cookie de blocage après une réponse complète, et donc de repérer très rapidement mes éventuels doublons (le seul cas qui est gênant est celui de plusieurs répondants à partir d'un même poste de travail et une session commune... mais bon assez rare ...).
Je m'adresse donc aux pontes de LS (Denis, Niccko, Benitov...etc) savoir si un système comme celui-ci pourrait être intégré. Je peux vous fournir mes JS si vous souhaitez, pour faciliter le travail !*?! Mais cela implique quelques modifications dans la BDD pour intégrer ce paramètre en plus ? du moins j'imagine ..

Voili voilà, en tout cas dispo pour en parler car cela me parait être quelque chose d'assez fondamental ....

A+

Thibault

Salut,

Pour les questionnaires "non anonymes" c'est géré via "Activer la persistance des liens réponses - invitations ?": clair, net précis, non détournable. Mais nécessite que le questionnaire soit non-anonyme comme tu l'indique.

Pour le point 2, le "Activer les cookies pour éviter les participations répétées ?" ne fonctionne pas comme il le faudrait. Je viens de le tester sur la 2.0 : c'est tout cassé. De souvenir sur la version 1.91 cela fonctionnait.

Je pense que ajouter une colonne dans la table est une mauvaise solution. Le principe serait plutot:
- Si la gestion des cookies est sur oui : enregistrer le {SAVEDID} dans le cookies (le SAVEDID est le numéro de la ligne des réponses).
- Si la session n'est pas remplie, la remplir avec le SAVEDID correspondant et les réponses de la ligne des réponses de ce SAVEDID.

Je n'ai jamais bossé sur cette partie, il faudrais vérifier :
1: si cela fonctionne en 1.92
2: si cela fonctionnait en 1.91.

Si c'est OK en 1.91 : ce sera plus facile de reprendre le code.

Par contre, si ton code peut être adapté pour enregistrer le SAVEDID plutot qu'un nouveau paramètre, quitte peut être à le crypter pour empécher les faille de sécurité. Trouver une méthode de cryptage/décryptage ????
Denis

Je viens de tester en local avec la 1.92 (120919) et ça fonctionne très bien; rien à redire.

Ben-

Oui sur la 1.92, les cookies marchent pour éviter les sessions complètes répétées ... mais pas les partielles. Je suis quasiment persuadé que cela n'a jamais existé sur la 1.91 ...

Oui effectivement Denis, c'est une idée un peu plus efficace que la mienne. Aussi, je ne fonctionnais pas avec des bases de données précédemment ce qui simplifie l'écriture d'un petit code comme celui-ci sur LS et j'ai une petite macro pour me trier mes données à partir de cet unique ID.

Cela peut se gérer... pour le cryptage, ce n'est pas mon fort, faut voir ...

Je regardes de mon côté.

Thibault

Salut,

Sinon, il me semble bien que le champ token est toujours créé, il est vide pour les questionnaires sans table d'invitation.

Le problème de rentrer une information dans la base de donnée qui lie le poste et les réponses peut, peut être, être considéré comme une infraction à l'anonymat. Peut être utiliser ce code pour le détournement de cookies que tu propose ?

EN tous cas, je pense que tu peux proposer une feature request, sur le rapport de bug avec ton patch. Améliorer le système de cookies est une très bonne idée. Peut être ajouter une colonne "cookies_link" aux questionnaire avec une option supplémentaire dans le questionnaire avant activation est à faire.

Denis