Produits Entr'ouvert » w.c.s.

• l'accès à toutes les étapes du workflow (comme l'accès par login/passe), et pas seulement celles autorisées ;
• la reprise d'un brouillon (donc avant tout workflow).

... mais c'est donc peut-être un autre système que je décris ici, et les actions de wf ajoutées actuellement gardent leur utilité par ailleurs.

Dans le même cadre, voir s'il y a moyen de faciliter l'écriture d'un handler "beforeunload", qui permettrait d'alerter la personne qui quitte un formulaire entamé. (par exemple en plaçant un attribut data-unsaved sur le <form>).

Frédéric Péters a écrit :

• en mode connecté, dès la première page, bloc "code de suivi"
• en mode déconnecté, sur la première page, bloc "conserver un brouillon de ma demande" (libellé à définir), sur les suivantes, bloc "code de suivi"

Pour moi, on avait conclu sur "faire la même chose pour les deux modes", i.e. toujours comme le mode déconnecté décrit plus haut.
Ca me semble plus simple à expliquer/programmer/documenter... et pas du tout gênant pour les usagers connectés (au contraire, ça permet de vérifier qu'ils veulent bien qu'on enregistre le début de leur demande).

Frédéric Péters a écrit :

Dans le même cadre, voir s'il y a moyen de faciliter l'écriture d'un handler "beforeunload", qui permettrait d'alerter la personne qui quitte un formulaire entamé. (par exemple en plaçant un attribut data-unsaved sur le <form>).

J'ai fait #6116 pour ça.

Thomas Noël a écrit :

Pour moi, on avait conclu sur "faire la même chose pour les deux modes", i.e. toujours comme le mode déconnecté décrit plus haut.
Ca me semble plus simple à expliquer/programmer/documenter... et pas du tout gênant pour les usagers connectés (au contraire, ça permet de vérifier qu'ils veulent bien qu'on enregistre le début de leur demande).

Absolument d'accord avec Thomas en tous points.

Une ébauche de mockup suite aux échanges: https://dev.entrouvert.org/projects/combo/wiki/Mockup_ticket_de_suivi

J'ai créé une branche pour contenir ce travail, http://repos.entrouvert.org/wcs.git/log/?h=wip/tracking-code

Pour le moment ça contient le patch de #6098 mais aussi la sauvegarde automatique des brouillons (i.e. une fois qu'on est sur un brouillon il est sauvegardé automatiquement de manière régulière, mais il n'y a pas de création automatique de brouillon).

Dans wip/tracking-code, sur qommon.forms.js je pense qu'il manque un "last_auto_save = new_auto_save" après que la sauvegarde a réussi.

En effet; je viens de corriger ça.

Aussi, je viens d'ajouter dans la branche un objet TrackingCode (mais pas encore d'interface pour l'utiliser).

Je viens de pousser une mise à jour qui ajoute les éléments d'UI, de manière encore brute, mais ça permet de voir un peu les déroulés.

https://perso.entrouvert.org/~fred/wcs-tracking-code.ogv

Discussion avec Fred sur le fait que le bouton "supprimer le brouillon" est un peu en contradiction avec le côté automatique du truc. Du coup on peut envisager une suppression automatique.

Et puis la suppression manuelle se ferait dans la liste des brouillons (qui n'existe actuellement nulle part mais qui pourrait pour moi apparaître automatiquement sous les demandes en cours, y en aura jamais 12 des brouillons).

Dans la vidéo on voit bien l'enregistrement manuel. est-ce qu'on garde l'idée que dans le cas des formulaires multipages, le brouillon est enregistré automatiquement à la validation de la première page ?

Pierre Cros a écrit :

Discussion avec Fred sur le fait que le bouton "supprimer le brouillon" est un peu en contradiction avec le côté automatique du truc. Du coup on peut envisager une suppression automatique.

Et puis la suppression manuelle se ferait dans la liste des brouillons (qui n'existe actuellement nulle part mais qui pourrait pour moi apparaître automatiquement sous les demandes en cours, y en aura jamais 12 des brouillons).

Ça me va. Ou alors le bouton de suppression devrait plutôt se trouver dans le bloc au même endroit que l'enregistrement du brouillon.

Victor Claudet a écrit :

Dans la vidéo on voit bien l'enregistrement manuel. est-ce qu'on garde l'idée que dans le cas des formulaires multipages, le brouillon est enregistré automatiquement à la validation de la première page ?

Oui, ce n'est pas sur la vidéo mais c'est le cas; https://perso.entrouvert.org/~fred/wcs-tracking-code-2.ogv

Il me reste une question sur la manière dont ça doit pouvoir s'activer dans l'admin, pour le moment c'est dirigé par l'option de conservation de brouillons mais ça devrait peut-être être divisé en une option d'activation de "suivi par code de suivi" et une autre, pour la possibilité pour l'usager de conserver des demandes en cours de rédaction (l'actuelle option brouillon, qui activerait d'office le code de suivi)

L'option de Pierre c'est d'activer le code de suivi, point. (il me corrigera si je résume trop).

Victor notait que ça pouvait peut-être poser des soucis avec certaines intégrations; pour cela on a la plateforme de recette (ou de dev) dans laquelle on peut charger les différents thèmes pour vérifier. Il y aurait d'autres problèmes à activer par défaut le code de suivi ?

Par ailleurs je pense que ça reste nécessaire au cas par cas de pouvoir le désactiver, pour des formulaires un peu technique comme on peut avoir "relier mon compte famille".

Le lundi 26 janvier 2015 à 15:40 +0100, redmine@entrouvert.com a écrit :

L'option de Pierre c'est d'activer le code de suivi, point. (il me
corrigera si je résume trop).

En tout cas tant que code de suivi et brouillon sont indissociables. Si
on se retrouve avec des clients qui ne veulent pas du code de suivi, se
posera à mon sens la question de la dissociation.

Quelques remarques sur la relecture de la branche :

• Code de suivi en consonnes majuscules seulement, sans chiffre, c'est pas très "CNIL" qui préfère un peu plus d'entropie, faudrait éventuellement que ça soit paramétrable (bof), ou par défaut ajouter au moins 23456789 (sans 1 et 0 qui peuvent être confondu avec des lettres)
• J'aurai ajouté un mini CRC final pour que l'agent puisse dire "désolé ce code est invalide" au lieu de "il n'est pas dans la liste" en cas de mauvaise dictée (+ petite protection gratuite contre les attaques)
• placeholder="ex: RPQDFVC" : plutôt "RPQDFVC" tout court, ou bien une possibilité de traduction de "ex: RPQDFVC"
• dans backoffice/root.py et forms/backoffice.py: l'affichage du trackingcode dans les listings backoffice : je suis contre (a priori inutile, et "dangereux" par ailleurs, c'est un peu un mot de passe, autant éviter de l'afficher au maximum). Fred aussi, en fait.
• c'est gênant d'afficher le code de suivi en clair et en permanence sur l'écran (lecture par dessus l'épaule...). Dans les nouvelles interfaces que je croise, on voit souvent un œil à coté des champs mot de passe, sur lequel on peut cliquer pour dire "afficher le mot de passe" (et on reclique sur l’œil pour le cacher à nouveau). Idée à reprendre ?
• TrackingCode::get_new_id : j'aurais quand même fait un test de non existence de l'id généré

C'est tout pour l'instant

Thomas Noël a écrit :

• Code de suivi en consonnes majuscules seulement, sans chiffre, c'est pas très "CNIL" qui préfère un peu plus d'entropie, faudrait éventuellement que ça soit paramétrable (bof), ou par défaut ajouter au moins 23456789 (sans 1 et 0 qui peuvent être confondu avec des lettres)

Juste une remarque là-dessus pour avoir lu la demande dans l'AO Meaux : un code composé uniquement de chiffres permet une saisie sur clavier téléphonique dans l'éventualité (un jour) d'un suivi de la demande via robot vocal.

EDIT : mais on est d'accord que c'est pas top niveau CNIL

Thomas Noël a écrit :

• Code de suivi en consonnes majuscules seulement, sans chiffre, c'est pas très "CNIL" qui préfère un peu plus d'entropie, faudrait éventuellement que ça soit paramétrable (bof), ou par défaut ajouter au moins 23456789 (sans 1 et 0 qui peuvent être confondu avec des lettres)

J'allais dire bof et m'appliquer mais je n'ai rien trouvé de concluant sur le site de la CNIL sur le sujet; donc je dis juste " bof".

• J'aurai ajouté un mini CRC final pour que l'agent puisse dire "désolé ce code est invalide" au lieu de "il n'est pas dans la liste" en cas de mauvaise dictée (+ petite protection gratuite contre les attaques)

Ça roule. (1)

• placeholder="ex: RPQDFVC" : plutôt "RPQDFVC" tout court, ou bien une possibilité de traduction de "ex: RPQDFVC"

Ok pour l'appel à gettext. (2)

• dans backoffice/root.py et forms/backoffice.py: l'affichage du trackingcode dans les listings backoffice : je suis contre (a priori inutile, et "dangereux" par ailleurs, c'est un peu un mot de passe, autant éviter de l'afficher au maximum). Fred aussi, en fait.

Ouaip, supprimé. (3)

• c'est gênant d'afficher le code de suivi en clair et en permanence sur l'écran (lecture par dessus l'épaule...). Dans les nouvelles interfaces que je croise, on voit souvent un œil à coté des champs mot de passe, sur lequel on peut cliquer pour dire "afficher le mot de passe" (et on reclique sur l’œil pour le cacher à nouveau). Idée à reprendre ?

Ça me chiffonne un peu, tu aurais des URL à me montrer ?

• TrackingCode::get_new_id : j'aurais quand même fait un test de non existence de l'id généré

Il y a tests au moment du stockage.

_~~

J'ai poussé les modifications (1, 2, 3) dans wip/tracking-code.

Frédéric Péters a écrit :

• J'aurai ajouté un mini CRC final pour que l'agent puisse dire "désolé ce code est invalide" au lieu de "il n'est pas dans la liste" en cas de mauvaise dictée (+ petite protection gratuite contre les attaques)

Ça roule. (1)

Je suis en train de me dire que, bon, finalement, c'est un peu débile (y'a pas de secret ajouté, et en ajouter un sera pénible), et que ça va nous embêter le jour où on voudra rentre possible le changement des caractères possibles dans le code. J'entends ton soupir Fred, désolé...

• c'est gênant d'afficher le code de suivi en clair et en permanence sur l'écran (lecture par dessus l'épaule...). Dans les nouvelles interfaces que je croise, on voit souvent un œil à coté des champs mot de passe, sur lequel on peut cliquer pour dire "afficher le mot de passe" (et on reclique sur l’œil pour le cacher à nouveau). Idée à reprendre ?

Ça me chiffonne un peu, tu aurais des URL à me montrer ?

Dans ma mémoire c'était sur des applis mobiles.

• TrackingCode::get_new_id : j'aurais quand même fait un test de non existence de l'id généré

Il y a tests au moment du stockage.

Arf, j'avais raté ça, désolé.

Frédéric Péters a écrit :

Thomas Noël a écrit :

• Code de suivi en consonnes majuscules seulement, sans chiffre, c'est pas très "CNIL" qui préfère un peu plus d'entropie, faudrait éventuellement que ça soit paramétrable (bof), ou par défaut ajouter au moins 23456789 (sans 1 et 0 qui peuvent être confondu avec des lettres)

J'allais dire bof et m'appliquer mais je n'ai rien trouvé de concluant sur le site de la CNIL sur le sujet; donc je dis juste " bof".

Je me basais sur les textes CNIL relatifs aux mots de passe (page 2 de http://www.cnil.fr/fileadmin/documents/Guides_pratiques/Guide_securite-VD.pdf ou page 50 de http://www.cnil.fr/fileadmin/documents/Guides_pratiques/CNIL_Guide_CollLocales.pdf, souvenirs de cg14 via Victor).

Gardons les consonnes majuscules uniquement pour l'instant, mais Victor demande qu'il y en ait 8 ;)

Gardons les consonnes majuscules uniquement pour l'instant, mais Victor demande qu'il y en ait 8 ;)

Avec le code de vérification on arrivait à huit :/

Je viens de repousser une branche avec la suppression de la somme de contrôle, et le nombre de caractères passés à 8.

Et puis aussi la modification pour remplacer l'option "autoriser les brouillons" par une option "Prise en charge du code de suivi", active par défaut.