Project

General

Profile

Development #3659

Possibilité de définir des actions globales.

Added by Victor Claudet about 9 years ago. Updated over 6 years ago.

Status:
Fermé
Priority:
Normal
Target version:
Start date:
24 September 2013
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:

Description

Actuellement il faut définir une liste d'actions au sein de chaque statut de workflow. Il serait parfois utile et beaucoup plus rapide de pouvoir définir des actions valables pour la totalité du circuit.

Par exemple donner la possibilité à un agent de rediriger une demande dans n'importe quel statut en cours d'instruction.
Possibilité de supprimer une demande.
Possibilité "d'attacher" des renseignement à une demande de manière globale.


Files

0001-general-add-support-for-global-actions-3659.patch (57.2 KB) 0001-general-add-support-for-global-actions-3659.patch Frédéric Péters (de retour le 10/10), 13 December 2015 04:46 PM

Related issues

Related to w.c.s. - Development #4228: Actions de workflow Appel et RetourFermé17 January 2014

Actions

Associated revisions

Revision 1dd5e103 (diff)
Added by Frédéric Péters (de retour le 10/10) over 6 years ago

general: add support for global actions (#3659)

History

#1

Updated by Frédéric Péters (de retour le 10/10) about 9 years ago

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

#2

Updated by Thomas Noël about 9 years ago

"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.

#3

Updated by Frédéric Péters (de retour le 10/10) about 9 years ago

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").

#4

Updated by Victor Claudet about 9 years ago

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é.

#5

Updated by Thomas Noël about 9 years ago

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...

#6

Updated by Victor Claudet about 9 years ago

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.

#7

Updated by Thomas Noël about 9 years ago

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.

Exemples :
  • 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)
#8

Updated by Victor Claudet almost 9 years ago

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 ?"

#9

Updated by Benjamin Dauvergne over 8 years ago

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.

#10

Updated by Frédéric Péters (de retour le 10/10) over 8 years ago

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 ?

#11

Updated by Benjamin Dauvergne over 8 years ago

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

#12

Updated by Benjamin Dauvergne over 8 years ago

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.

#13

Updated by Frédéric Péters (de retour le 10/10) over 8 years ago

É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.

#14

Updated by Thomas Noël over 8 years ago

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

Ensuite, une fois que l'action appel existera, on revient ici et l'idée est alors (idée floue et encore un peu théorique pour moi) que les "actions générales" seraient une liste d'actions de workflow utilisant le code de celles déjà existantes, genre :
  • 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.

#15

Updated by Victor Claudet over 8 years ago

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.

#16

Updated by Frédéric Péters (de retour le 10/10) over 8 years ago

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.

#17

Updated by Victor Claudet over 8 years ago

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...

#18

Updated by Frédéric Péters (de retour le 10/10) over 8 years ago

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".

#19

Updated by Victor Claudet over 8 years ago

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.

#20

Updated by Frédéric Péters (de retour le 10/10) over 8 years ago

À 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)

#21

Updated by Thomas Noël almost 8 years ago

  • Patch proposed set to No

Pour relance de l'idée, demande cg14 qui pourrait être satisfaite par ce ticket, je pense : "Prévoir un statut de "contournement" pour les demandes dans le cas du décès du bénéficiaire en cours d'instruction. (...)"

#22

Updated by Frédéric Péters (de retour le 10/10) almost 8 years ago

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.
#23

Updated by Thomas Noël almost 8 years ago

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.

#24

Updated by Frédéric Péters (de retour le 10/10) almost 8 years ago

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).

#25

Updated by Frédéric Péters (de retour le 10/10) almost 7 years ago

#26

Updated by Frédéric Péters (de retour le 10/10) almost 7 years ago

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é.

#27

Updated by Thomas Noël over 6 years ago

  • Assignee set to Frédéric Péters (de retour le 10/10)

Ack (en cachant pour l'instant le lien de config, tel que discuté par ailleurs)

#28

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

  • Status changed from En cours to Résolu (à déployer)
commit 1dd5e103ba397266c8b30574509db51ee09c14d2
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Sat Dec 12 10:46:24 2015 +0100

    general: add support for global actions (#3659)
#29

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

  • Target version set to v1.27
#30

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

  • Status changed from Résolu (à déployer) to Fermé

Also available in: Atom PDF