Produits Entr'ouvert » w.c.s.

Par "statut en cours d'instruction", tu entends quoi ?

"n'importe quel statut, en cours d'instruction" : au CG14 il y a plus de dix statuts traversés au fur et à mesure de l'instruction ; s'il faut avoir un bouton "on annule tout", il faut l'implémenter dans tous ces statuts, c'est pas marrant. C'est ça qu'il faut résoudre, la technique d'avoir des "actions globales" est une possibilité... Dans une certaine mesure, ça pourrait rejoindre l'idée des workflow en parallèle, mais bon, bref, dur.

Ma question elle pointait vers l'idée que "statuts en cours d'instruction" n'était pas forcément "tous les statuts", si ? Et que de toute façon, si ce n'est pas le cas ici, ça pourrait l'être ailleurs, je pense (sur un mode "possibilité à tout moment de supprimer, sauf une fois que la demande a été marquée comme clôturée").

Mon idée initiale était vraiment de permettre des actions globales sans restrictions du type "sauf une fois que la demande a été marquée comme clôturée".

Dans la pratique ces fonctionnalités seraient attribuées à des rôles (un responsable par exemple).
Le gros problème que l'on a actuellement c'est l'impossibilité de "corriger" une erreur de traitement sans l'avoir prévu avant.
On pourrait d'ailleurs imaginer qu'une demande clôturée est finalement ré-ouverte par un responsable qui ne serait pas satisfait d'une réponse on d'un traitement appliqué.

Une idée pourrait être de permettre à des "supermen" de changer le statut d'une demande en dehors de tout workflow. Et quand le statut est changé, on execute les actions de celui-ci... un peu comme un "saut forcé".

C'est "dangereux" car si la personne joue n'importe comment, elle peut se retrouver avec des demandes incohérentes.

Une possibilité serait de ne présenter que certains status, et donc d'ajouter une notion de "role autorisé à me sauter dessus sans prévenir" dans les statuts. Mouais...

Thomas Noël a écrit :

ajouter une notion de "role autorisé à me sauter dessus sans prévenir" dans les statuts

ça me parait pas utile à partir du moment ou le rôle autoriser à agir sur les actions globales est bien paramétré.
exemple : seul de le chef de service peut agir sur certaines actions. Les actions "sans risques" sont laissées à dispo des gestionnaires.

Victor Claudet a écrit :

Thomas Noël a écrit :

ajouter une notion de "role autorisé à me sauter dessus sans prévenir" dans les statuts

ça me parait pas utile à partir du moment ou le rôle autoriser à agir sur les actions globales est bien paramétré.
exemple : seul de le chef de service peut agir sur certaines actions. Les actions "sans risques" sont laissées à dispo des gestionnaires.

C'est parce que tu imagines que les actions globales ne seront utiles que pour des "super user". C'est très limitant, et ça veut dire de rendre configurable.

Ce que je propose moi, c'est d'avoir la possibilité dans un statut de le rendre "accessible directement" (case à cocher), accès limité à "tel et tel rôle" (liste de rôles). Dans le backoffice, les personnes qui ont un des rôles indiqués peuvent alors envoyer n'importe quelle demande dans un de ces statuts.

• un statut "supprimé parce que c'est un spam" accessible aux rôles destinataires
• un statut "supprimé par le demandeur", accessible uniquement au demandeur (statut qui demandera confirmation)

Pour aider à la reflexion, illustration par l'exemple d'une demande client :
"Une secrétaire a fait proposition de plan d'aide alors qu'il ne fallait pas.
Est ce que l'on peut revenir à l'étape précédente (visite du TMS) ?
Si oui est ce que je peux le faire moi-même ?"

Discussion ce jour avec Thomas sur les actions globales: on a utilisé le cas d'usage d'une demande de pièce jointe à tout moment d'une procédure. Dans ce cas on a envie de partir sur un workflow qui contiendrait l'envoie d'un mail à l'usager, l'affichage du formulaire pour la pièce sur sa page de liaison, puis l'acceptation de la pièce jointe par l'agent et enfin le retour au statut dont on est parti. Sans une pile où on stockerait le statut d'où on est parti cela parait difficile, cela donne vie au ticket #4228.

Cette direction n'amène rien de particulier quant à l'idée de ces "actions globales", il resterait en tout point du workflow la nécessité d'ajouter une commande envoyant l'appel au sous-workflow, ou je rate un truc ?

Ça ne change rien à cette demande; ça la rend juste plus utile.

J'explicite: plus utile dans le sens ou si on développe le #4228 avant on peut par exemple extrêmement simplifier le workflow CG14 ou tout autre workflow avec des actions exceptionnelles compliquées sur tous les statuts en combinant actions globales et Appel/Retour.

Étrange, j'aurais au final dit que ça rendait cette demande moins utile, sur l'idée qu'en diminuant le nombre de statuts il y a moins de lourdeur à permettre (statut par statut) la bascule sur une action parallèle.

Je confirme ce que dit Fred, je serai pour nous pencher sur #4228 d'abord.

• envoyer un mail
• forcer la demande à passer à un statut X (et l'exécuter)
• lancer un appel au statut Y (sous-workflow) et à la fin revenir au statut S -- ce qui est l'objet de l'action imaginée dans #4228

Chaque action générale étant présentée sous forme d'un bouton si l'utilisateur a le rôle nécessaire.

un petit up parce que se serait quand même bien utile.

Le cas d'usage de base serait pour un rôle pré-défini, pouvoir à tout moment supprimer la demande. Pouvoir à tout moment déplacer la demande dans un autre statut du workflow.

Tu peux donner ton cas concret du jour ?

Pour moi des actions comme "supprimer" ou "changer arbitrairement d'état", elles n'ont pas forcément à être réfléchies dans le cadre d'un truc général.

A vrai dire je vois pas bien ce que je peux dire de plus que ma remarque précédente.

Dans la cas du cg14 par exemple, il peut arriver que par erreur une demande soit saisie deux fois par un agent.
Cette demande doit être supprimée. Mais les agents ont parfois commencé à la traitée, elle peut donc être dans n'importe quel statut du workflow. C'est alors un rôle "chef de projet" qui peut venir et supprimer la demande en doublon.

Il y a aussi parfois des cas particuliers dans lesquels il est nécessaire au chef de projet d'intervenir pour déplacer la demande dans une statut antérieur et donc pouvoir à n'importe quel moment choisir un statut à attribuer c'est bien.

ça c'est pour la demande la plus courante. L'idéal serait biensûr d'étendre les possibilité à des actions personnalisables et même un formulaire back-office global...

Pour moi c'est important d'affiner la demande, parce que dans la description initiale il y a « Possibilité "d'attacher" des renseignement à une demande de manière globale «, et ça appellerait pour moi quelque chose de très particulier, pareil plus tard dans le commentaire #9.

Alors que si l'on parle uniquement d'actions "supprimer" / "changer d'état", je perçois quelque chose d'autre.

Aussi, tu fais maintenant intervenir une notion de "chef de projet".

l'intervention d'un "chef de projet" est pas nouvelle si tu lis tous les commentaires au-dessus.

Il me semble assez logique de dire que l'agent gestionnaire de base ne peut pas accéder à une action de suppression globale.
Ce que je dis plus haut aussi c'est que pour bien faire ces actions globales il est possible de leur attribuer un rôle et seul se rôle peut agir.

Maintenant qu'il y ait des différences entre donner la possibilité d'une action globale "joindre une pièce" ou "supprimer la demande" ça me semble logique oui. C'est pas pour autant qu'on a pas besoin des deux. Peut-être que qu'il y a plusieurs choses techniquement différentes derrière la demande initial, je te laisse juge.

Le mieux serait peut-être qu'on en discute autour d'une conf pour éclaircir les choses pour ceux qui le souhaitent.

À revenir à réfléchir sur tout ça, le développement pourrait être l'ajout d'un rôle superviseur / manager à un formulaire, et l'utilisateur qui en disposerait aurait une action en plus, lui permettant de changer le formulaire vers n'importe quel statut. Libre au statut ensuite d'exécuter ou permettre une action particulière (par exemple supprimer).

Cela correspond au commentaire 5 de Thomas. L'autre piste, commentaire 7 de Thomas, c'est de ne pas faire ça en défnissant un superviseur au niveau du formulaire mais en définissant les possibilités de saut arbitraire au niveau des différents statuts (oui/non, et par quels rôles).

Que l'une ou l'autre option soit choisir, il manquera la possibilité de revenir à l'état initial, mais ça pourra être fait en réutilisant la possibilité de changement arbitraire de statut, en attendant une mécanique comme #4228.

(ce commentaire me semble faire synthèse de tout ce qui a été dit plus haut)

Certes.

Juste au-dessus, je reprends deux approches évoquées le long des commentaires :

• avoir un rôle "superviseur" pour un formulaire, qui aurait la possibilité de passer à n'importe quel statut ;
• avoir la possibilité de marquer un statut comme tout le temps accessible.

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

À revenir à réfléchir sur tout ça, le développement pourrait être l'ajout d'un rôle superviseur / manager à un formulaire, et l'utilisateur qui en disposerait aurait une action en plus, lui permettant de changer le formulaire vers n'importe quel statut. Libre au statut ensuite d'exécuter ou permettre une action particulière (par exemple supprimer).

Cette solution me semble simple, claire, efficace.

Pour éviter une fausse manip par quelqu'un qui serait superviseur mais aussi gestionnaire classique au quotidien, j'ajouterai un popup de confirmation dans le cas d'une demande de changement de statut non prévue par le workflow ("attention, vous allez passer directement la demande vers son statut XXX").

Enfin, le rôle "superviseur" n'est pas obligatoire. Par défaut, un formulaire n'en a pas.

Discussion à l'eocamp, ce qu'on aurait c'est simplement pour un workflow une liste (libellé, workflow action), et des boutons pour celles-ci seraient ajoutés sur la page du formdata (peut-être bien dans la barre latérale, même si ça fait qu'on ne pourrait alors pas avoir d'action globale pour l'usager).

Il y a la structure générale pour avoir différents types de déclencheurs pour ces actions globales mais pour le moment seulement le déclenchement manuel (par un bouton) est implémenté.