Produits Entr'ouvert » w.c.s.

Cela concerne les pages de listings où il y a trop de statuts difficilement compréhensibles, ou les agents ont des problèmes ailleurs aussi ?

Les pages de listing, mais aussi le journal de la demande elle-même.

+ 1 du coup

Pour tournai ce serait utile sur une démarche complexe où il y a des A/R multiple vers un statut "technique" (dans lequel aucun message ne s'affiche, aucune action n'est à disposition). Ça permettrait de ne pas allonger trop l'historique.

Pour avancer, périmètre à délimiter :

• cacher les éléments de l'historique / ne pas afficher ces noms de statuts dans les listings (prendre le dernier statut "intelligible")
• faire ça par rapport à des rôles précis / par rapport à seulement l'admin.

De loin, je dirais que c'est très compliqué d'avoir une incidence sur les listings (et que c'est ça qui a laissé ce ticket inactif).

Pour le deuxième point je dirais que le soucis est avant tout un point d'UI, remplacer la case à cocher "Cacher ce statut au demandeur" par une liste de rôles/fonctions "Limiter l'affichage à ces rôles". Et là comme c'est une nouvelle fonctionnalité je dirais qu'on pourrait faire "Limiter l'affichage à ces fonctions" avec une liste de cases à cocher, vu qu'on a bien moins de rôles que de fonctions. (mais si on veut limiter à tout le monde sauf la personne qui crée le workflow il faut définir une fonction pour celle-ci).

Pour mon besoin, "Cacher aux agents" sans plus de précisions suffit. Mais limiter aux fonctions c'est très bien. On crée déjà souvent une fonction "testeur", ceux qui veulent que seul le créateur voit le bousin, il lui colleront le rôle lié à cette fonction.

L'affichage dans les listings c'est pas un sujet dans mon usage, il s'agit toujours de statuts transitoires, dans lesquels une demande ne reste jamais.

J'ai exactement le même besoin. Ce qui est important c'est le fait que ces statuts techniques "polluent" l'historique pour les agents traitants.
Pour les listing ce n'est pas un pb pour moi, ces statuts étant souvent que des points de passage.

Je note ici que la demande n'est pas vraiment de cacher un statut : si une demande est dans un statut "chose", elle apparaitra bien comme ayant ce statut, dans les listing comme au niveau de l'affichage de la demande elle-même (colonne de droite).

Ce qui est en fait demandé, c'est "juste" de ne pas polluer l'historique, de ne pas afficher ces statuts dedans. C'est donc pas tout à fait la même que ce qu'on fait quand on cache un statut au demandeur (où le demandeur a l'impression que la demande est restée dans le dernier statut visible). Et c'est sans doute plus simple à atteindre techniquement.

C'est effectivement le besoin.
En fait, ces statuts polluant sont des statuts qui ne contiennent aucun "saut manuel" ou "saut à la soumission" mais uniquement des "sauts automatiques", bref qui ne requièrent pas l'intervention d'un agent ou d'un usager.
Pour ma part, il n'y a pas de pb majeur à afficher ces statuts dans les listings ou dans la colonne de droite, c'est effectivement juste un pb dans l'historique.

À ce compte-là, on pourrait même de manière automatique ne pas afficher les passages en statut qui ne sont pas marqués "waitpoint" ou "endpoint" (et qui n'ont rien à afficher). Non ?

absolument, du coup tu diminues largement les erreurs de paramétrage, et cela évite de reprendre les WF existants, tout en répondant au besoin.

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

À ce compte-là, on pourrait même de manière automatique ne pas afficher les passages en statut qui ne sont pas marqués "waitpoint" ou "endpoint" (et qui n'ont rien à afficher). Non ?

Il me semble que ça serait déjà pas mal. Peut-être imaginer un bouton "full" pour tout afficher quand même, histoire de voir par où la demande est passée (très important lors du support, quand même).

Un bouton discret alors... ou alors un paramètre à passer en url sur le détail de la demande comme http//urldelademande/94/?full pour rester sur une interface simple

Autre cas d'usage fréquent :
on passe par un statut pour afficher à l'agent un formulaire de wf spécifique (pour sélectionner un service par exemple).
L'information saisie est utilisée sur le statut suivant, mais le statut où le formulaire est utilisé est présent dans l'historique et vient alourdir l'historique inutilement.

Ce n'est pas juste un statut technique non interactif, mais un statut qu'on ne veut plus voir afficher dans l'historique une fois qu'on est sorti du statut.

Pour affiner, ce serait donc une option : ne pas afficher le statut dans l'historique (avec un comportement automatique : sauf si la demande est positionnée sur ce statut).

Stéphane Laget a écrit :

Ce n'est pas juste un statut technique non interactif, mais un statut qu'on ne veut plus voir afficher dans l'historique une fois qu'on est sorti du statut.

Pour affiner, ce serait donc une option : ne pas afficher le statut dans l'historique (avec un comportement automatique : sauf si la demande est positionnée sur ce statut).

Pas fan du tout de cette nouveauté conceptuelle qui complique la compréhension d'une part, le traçage d'autre part.

Je pense vraiment préférable de rester sur un truc facile à comprendre du type "cacher aux agents|fonctions"

en fait cela revient au même : c'est bien "cacher aux agents/fonctions" (avec un comportement automatique qui affiche le statut si la demande est positionnée sur ce statut. Ce qui facilitera également le support)

Pour moi ça ne revient pas au même du tout, ça nécessite un effort supplémentaire pour comprendre pourquoi un statut qui devrait être caché n'est en fait pas caché, c'est ce que j'appelle un nouveau concept et dont je ne suis pas fan.

Pas envie de devoir faire de la doc et du support là-dessus (ce qui sera inévitable) alors que rajouter des fonctions concernant à qui on cache/affiche le statut ne nécessitera aucune explication.

Si tu as besoin que le statut soit visible, ne le cache pas, c'est simple.

Pour situer, la question elle est au niveau de l'effet, "caché dans l'historique" vs "caché tout le temps", c'est-à-dire que "caché dans l'historique" est juste une notion d'affichage quand on consulte une demande, alors que "caché tout le temps" c'est aussi ne pas reprendre ce statut dans la colonne "statut" d'un tableau de traitement, faire en sorte que le filtrage sur statut propose uniquement à la sélection les statuts "visibles", faire en sorte que filtré sur un statut le tableau de traitement affiche également les demandes qui sont dans un statut caché qui a suivi ?

On a eu #41973 qui précisait "dans l'historique" ("Pouvoir configurer certains statuts comme n'étant pas visibles dans l'historique.") mais dans ce ticket ça semble alterner, parfois on précise "dans l'historique" et parfois pas.

(pour le "caché à l'usager" on n'a pas ces questions vu qu'il n'y a pas de tableau de traitement et filtrage possible).

Et je n'aime pas trop cette nouvelle distinction "caché dans l'historique" vs "caché tout le temps" qui complique la compréhension des choses pour un gain que je trouve mineur.

Dans mon idée, si je repasse souvent par un statut où il y a une action à faire par l'agent au point que ça pollue l'historique du WF, c'est que mon process de traitement est mauvais.

Ok, j'entends les arguments sur la complexité de compréhension et sur les impacts un peu partout sur les listings. restons donc sur l'idée première.

Pour donner le point de vue technique, c'est beaucoup plus facile d'uniquement se préoccuper de l'historique; traiter le sujet partout amène justement ces questions annexes, tableau de traitement et filtrage (si je fais une vue personnalisée sur un statut, pour moi elle va afficher uniquement les demandes dans ce statut, pour un autre agent il y aura éventuellement d'autres demandes, qui sont dans un statut suivant mais caché), et les devs pour suivre ça sont très galères (basiquement on doit faire porter sur chaque demande un statut par fonction/rôle).

Pour revenir plus haut, un commentaire de Thomas :

Je note ici que la demande n'est pas vraiment de cacher un statut : si une demande est dans un statut "chose", elle apparaitra bien comme ayant ce statut, dans les listing comme au niveau de l'affichage de la demande elle-même (colonne de droite).

Ce qui est en fait demandé, c'est "juste" de ne pas polluer l'historique, de ne pas afficher ces statuts dedans. C'est donc pas tout à fait la même que ce qu'on fait quand on cache un statut au demandeur (où le demandeur a l'impression que la demande est restée dans le dernier statut visible). Et c'est sans doute plus simple à atteindre techniquement.

Comme c'était il y a trois ans le "plus simple à atteindre techniquement" est peut-être moins crédible mais c'est clairement vrai.

_~~

Aussi, l'autre part de variation dans les interprétations de ce ticket, c'est entre "caché à certains rôles/fonctions" ou juste "caché aux agents au sens large", si on prend juste "au sens large", ça fait que côté technique on n'arrive pas à un statut par rôle/fonction mais juste un statut "agent".

Alors il ne faut plus parler de statuts cachés/visibles mais affichés ou pas dans l'historique (même si on perd la facilité de compréhension du caché/visible par l'usager) :

Affichage du statut dans l'historique :
x Affiché à tous
o Affiché uniquement aux agents (statut interne)
o Pas affiché (statut technique/transitoire)

Ça boucle sur #7110#note-10 où je séparais déjà :

• cacher les éléments de l'historique / ne pas afficher ces noms de statuts dans les listings (prendre le dernier statut "intelligible")
• faire ça par rapport à des rôles précis / par rapport à seulement l'admin.

et ta réponse derrière :

Pour mon besoin, "Cacher aux agents" sans plus de précisions suffit. Mais limiter aux fonctions c'est très bien. On crée déjà souvent une fonction "testeur", ceux qui veulent que seul le créateur voit le bousin, il lui colleront le rôle lié à cette fonction.
L'affichage dans les listings c'est pas un sujet dans mon usage, il s'agit toujours de statuts transitoires, dans lesquels une demande ne reste jamais.

ou celle de Stéphane :

Ce qui est important c'est le fait que ces statuts techniques "polluent" l'historique pour les agents traitants.
Pour les listing ce n'est pas un pb pour moi, ces statuts étant souvent que des points de passage.

_~~

Si tout le monde s'accorde là-dessus, je pense que ça va pouvoir être développé. (quand je me le suis assigné c'était sur cette idée, pas sur l'idée de relancer la discussion sur le spectre).

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

Si tout le monde s'accorde là-dessus

impec

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

Ça boucle sur #7110#note-10 où je séparais déjà 

Cette nécessité de revenir sur l'historique pour dire "je le disais déjà" c'est puéril. Je ne suis pas d'accord tu ne le disais pas, peu importe.

Ce avec quoi je suis d'accord c'est :

Affichage du statut dans l'historique :
x Affiché à tous
o Affiché uniquement aux agents (statut interne)
o Pas affiché (statut technique/transitoire)

Si ça correspond à ce que tu as toujours voulu faire depuis le début sans arriver à l'exprimer de façon compréhensible pour moi c'est super.

Ce avec quoi je suis d'accord c'est :

Affichage du statut dans l'historique :
x Affiché à tous
o Affiché uniquement aux agents (statut interne)
o Pas affiché (statut technique/transitoire)

Si ça correspond à ce que tu as toujours voulu faire depuis le début sans arriver à l'exprimer de façon compréhensible pour moi c'est super.

Je n'ai jamais voulu dans ce ticket exprimer un changement de comportement pour l'usager, le comportement actuel resterait (i.e. ça concernerait également l'info "statut actuel", pas uniquement l'historique).

Maintenant, est-ce que c'est un détail à passer sous silence, à garder malgré le nouvel intitulé "dans l'historique", ou est-ce quelque chose d'importance ?

Si je comprends correctement, je vote pour "détail à passer sous silence, à garder malgré le nouvel intitulé".

Ce que je comprends c'est que, dans une demande, l'usager continue de voir comme statut en cours le dernier statut affichable dans l'historique.

Automatic expiration