Produits Entr'ouvert » w.c.s.

Et en absence de champ email ? Ou si celui-ci n'est pas attaché à l'utilisateur (i.e. pas défini comme prérempli) ? On affiche juste "utilisateur inconnu", ou rien du tout, ou… ?

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

Et en absence de champ email ? Ou si celui-ci n'est pas attaché à l'utilisateur (i.e. pas défini comme prérempli) ? On affiche juste "utilisateur inconnu", ou rien du tout, ou… ?

Oui, dans ce cas, "utilisateur inconnu", ça m'irait. Ou peut-être "anonyme" plutôt qu'inconnu ?

redmine@entrouvert.com écrivait:

La demande #1213 a été mise à jour par Thomas Noël.

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

Et en absence de champ email ? Ou si celui-ci n'est pas attaché
à l'utilisateur (i.e. pas défini comme prérempli) ? On affiche juste
"utilisateur inconnu", ou rien du tout, ou… ?

Oui, dans ce cas, "utilisateur inconnu", ça m'irait. Ou peut-être
"anonyme" plutôt qu'inconnu ?

Ça me gène un peu ces « inconnu » et « anonyme » dans la mesure ou
souvent il y aura d'autres champs permettant d'identifier l'utilisateur
dans le formulaire (nom, prénoms, etc...). Je mettrai plutôt
'utilisateur non-connecté' ou 'non authentifié'. Et dans le cas ou
l'email affiché l'est par extraction, je mettrai peut-être un renvoi
« ¡ », ou alors une couleur, avec une légende « ¡ email du requérant
» ou un truc dans le genre.

Benjamin Dauvergne a écrit :

Ça me gène un peu ces « inconnu » et « anonyme » dans la mesure ou
souvent il y aura d'autres champs permettant d'identifier l'utilisateur
dans le formulaire (nom, prénoms, etc...). Je mettrai plutôt
'utilisateur non-connecté' ou 'non authentifié'.

Attention, il peut avoir été connecté, mais on ne le sait pas (user_hash)...
On peut aussi choisir de ne rien mettre (afficher juste la date et l'heure
de la demande, ainsi que son numéro et, éventuellement, la date de sa
dernière modification).

Et dans le cas ou
l'email affiché l'est par extraction, je mettrai peut-être un renvoi
« ¡ », ou alors une couleur, avec une légende « ¡ email du requérant
» ou un truc dans le genre.

oui, si le mail est affiché, même s'il a été "deviné", ça risque de faire finalement un peu bizarre avec cette notion de user_hash qui veut que le user ne soit pas remonté...

ne rien afficher est peut-être encore la bonne technique ; quoique pas très pratique pour l'agent qui est contacté par un usager et qui doit retrouver la demande...? je sais pas trop... à voir avec Victor pour décision ;)

redmine@entrouvert.com écrivait:

Attention, il peut avoir été connecté, mais on ne le sait pas
(user_hash)...
On peut aussi choisir de ne rien mettre (afficher juste la date et l'heure
de la demande, ainsi que son numéro et, éventuellement, la date de sa
dernière modification).

Le top ce serait d'avoir un résumé ad-hoc de la demande, via un champ
texte ou niveau de la définition du formulaire permettant de donner un
petit texte pouvant contenir des variables de substitution qui sera
repris en page de listing, mais pour ce seul ticket ça fait un peu trop
:)

L'autre possibilité ce serait d'avoir une case à cocher pour tous les
types de champ « Utiliser comme colonne dans la liste des formulaires ».

Et dans le cas ou
l'email affiché l'est par extraction, je mettrai peut-être un renvoi
« ¡ », ou alors une couleur, avec une légende « ¡ email du requérant
» ou un truc dans le genre.

oui, si le mail est affiché, même s'il a été "deviné", ça risque de
faire finalement un peu bizarre avec cette notion de user_hash qui
veut que le user ne soit pas remonté...

On ne doit pas assigner arbitrairement d'identifiant unique aux
utilisateurs, mais si dans la procédure ils nous transmettent un
identifiant, typiquement de contact (et donc non-unique dans le temps
généralement), en rapport avec la procédure, ça parait justifier de
l'afficher.

ne rien afficher est peut-être encore la bonne technique ; quoique pas
très pratique pour l'agent qui est contacté par un usager et qui doit
retrouver la demande...? je sais pas trop... à voir avec Victor pour
décision ;)

L'idéal dans ce cas ce serait d'avoir coté agent un outil de recherche
par jeton (encore plus idéalement la recherche serait full-text, en
commençant par tester l'index des jetons), comme ça le jeton transmis
à l'utilisateur (puisque qu'on part vers une généralisation de celui-ci)
est aussi utilisable par l'agent pour sa recherche. Pareil si vous jugez
ça utile, il faudrait ouvrir un autre ticket.