Project

General

Profile

Development #69120

wf: action de déliaison de l’usager demandeur avec la demande soumise

Added by Paul Marillonnet 3 months ago. Updated 11 days ago.

Status:
Rejeté
Priority:
Normal
Target version:
-
Start date:
15 September 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Cas d’usage Publik Personnes Morales où pour des raisons fonctionnelles, on souhaite que la perte d’une fonction soit accompagnée par la perte de la visibilité de l’usager sur ses demandes.
S’il s’avère que ce n’est pas un cas isolé et que d’autres types de démarches/d’applis gagneraient à avoir ça, je me demande dans quelle mesure on pourrait matérialiser ça par une action supplémentaire.


Files

0001-wf-add-unlink-user-action-69120.patch (5.08 KB) 0001-wf-add-unlink-user-action-69120.patch Paul Marillonnet, 07 November 2022 05:16 PM

Related issues

Related to w.c.s. - Development #71777: wf: ajout d’une option à l’action d’anonymisation pour effectuer la déliaison avec l’usagerSolution proposée28 November 2022

Actions

History

#2

Updated by Frédéric Péters 3 months ago

  • Status changed from Nouveau to Information nécessaire

Elle s'appellerait comment et serait rangée où ?

#3

Updated by Stéphane Laget 3 months ago

Proposition du nom de l'action de Wf.

"Suppression du lien usager/demande"

#4

Updated by Frédéric Péters 3 months ago

Mais si c'est une fiche ?

#5

Updated by Stéphane Laget 3 months ago

oui, le ticket ne parlait que des demandes.

Proposition :
"Suppression du lien avec l'usager"

#6

Updated by Frédéric Péters 3 months ago

serait rangée où ?

#7

Updated by Stéphane Laget 3 months ago

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

serait rangée où ?

proposition : dans la section "Agir sur une demande ou une fiche"

#8

Updated by Paul Marillonnet about 1 month ago

  • Status changed from Information nécessaire to En cours
  • Assignee set to Paul Marillonnet
#9

Updated by Paul Marillonnet about 1 month ago

Voilà, tel que discuté dans le ticket. Notamment de ces discussions j’en déduis que le besoin est de seulement délier l’usager de la demande où la fiche sur laquelle s’exécute le workflow, et non pas de pouvoir préciser des identifiants de demandes ou fiches tierces qui seraient concernées par la déliaison. De cette déduction le code est simple, cela pourrait être quelque chose comme cela.

Côté UI, au paramétrage de cette action minimaliste reste seulement le champ “Condition d’exécution de l’action” dans un unique onglet “Avancé”. On pourrait améliorer cet affichage, par exemple faire disparaître l’unique onglet, mais rien à voir ici, ça doit à mon avis faire l’objet d’un ticket à part.

#10

Updated by Mikaël Ates about 1 month ago

Notamment de ces discussions j’en déduis que le besoin est de seulement délier l’usager de la demande où la fiche sur laquelle s’exécute le workflow, et non pas de pouvoir préciser des identifiants de demandes ou fiches tierces qui seraient concernées par la déliaison.

Je pense que tu peux faire cette hypothèse. Dans le cas d'usage ciblé, l'action prendrait place systèmatiquement dans un statut de début du workflow des demandes concernées. Pour les cas d'usage nécessitant un lancement d'un autre workflow, cela se ferait avec un appel wf externe en listant les demandes concernées dans lesquelles il y aurait l'action globale conduisant à cette action.

#11

Updated by Paul Marillonnet 21 days ago

  • Subject changed from wf: action de déliaison de l’usager demandeur avec la demande soumise(?) to wf: action de déliaison de l’usager demandeur avec la demande soumise

Mikaël Ates a écrit :

Je pense que tu peux faire cette hypothèse. Dans le cas d'usage ciblé, l'action prendrait place systèmatiquement dans un statut de début du workflow des demandes concernées. Pour les cas d'usage nécessitant un lancement d'un autre workflow, cela se ferait avec un appel wf externe en listant les demandes concernées dans lesquelles il y aurait l'action globale conduisant à cette action.

Ok, merci pour la précision.

#15

Updated by Pierre Cros 15 days ago

J'avais raté ce ticket.

Pour moi ce serait beaucoup mieux de ranger l'action dans "Agir sur le demandeur", juste parce qu'il y a presque rien là-dedans et qu'on peut considérer que retirer le demandeur c'est agir sur le demandeur.

Au-delà et pour le futur, il me semble nécessaire de débattre plus longuement avant de créer de nouvelles actions, surtout quand il s'agit d'actions aussi techniques que retirer le demandeur, ou supprimer le code de suivi ou rattacher un utilisateur à une fiche (les derniers ajouts).

Compte tenu de la maturité de Publik, l'ajout d'action devrait plutôt être tourné vers des actions de plus haut niveau, des actions métiers. Et ce type de détail technique devrait, tant que faire ce peut, être intégré aux actions existantes (ou automatisée par exemple pour la suppression du code de suivi) pour éviter la prolifération.

#18

Updated by Frédéric Péters 15 days ago

Un bout d’API

Vraiment très opposé à l'idée des appels de wcs à wcs qui compliquent tout traçage.

~~

On a ailleurs (#71520) du bricolage pour éviter une saisie en étant connecté.

Il me semble que ce serait la même chose ici, c'est-à-dire qu'on pourrait avoir une option sur la démarche pour dire qu'elle ne doit pas être liée à l'usager. (plutôt que la laisser se lier et commencer le workflow par la délier).

#19

Updated by Pierre Cros 15 days ago

Option sur la démarche oui mais côté workflow plutôt que côté formulaire (où il y a en déjà trop d'options).

Le formulaire c'est le truc simple, le compliqué c'est pour le workflow et donc avoir cette option (et pas une action) côté WF c'est mieux.

#20

Updated by Mikaël Ates 15 days ago

On a ailleurs (#71520) du bricolage pour éviter une saisie en étant connecté.

Il me semble que ce serait la même chose ici, c'est-à-dire qu'on pourrait avoir une option sur la démarche pour dire qu'elle ne doit pas être liée à l'usager. (plutôt que la laisser se lier et commencer le workflow par la délier).

Pas sûr, il faut tout de même que sur le formulaire on puisse s'assurer que l'usager soit connecté et que le form_user soit disponible tout au long du formulaire pour faire par exemple des requêtes avec du |current_user. Et niveau workflow, on veut éventuellement pouvoir en début de workflow faire quelques actions sur le form_user avant de l'effacer.

#21

Updated by Paul Marillonnet 15 days ago

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

(plutôt que la laisser se lier et commencer le workflow par la délier).

Les CPFs me contrediront si je dis n’importe quoi, mais il me semble que le cas d’usage relatif à cette déliaison est l’usager qui perd un mandat en cours pour une personne morale donnée. Il me semble que dans ce cas précis cela passe par un appel WF externe sur des demandes en cours et des fiches existantes. Une simple option "ne pas lier à l’usager" ne suffirait pas ici, je crois.

#24

Updated by Frédéric Péters 15 days ago

Pour autant, on a quand même besoin sur le formulaire ou "en début" de workflow de connaître le form_user

Sur le formulaire l'usager qui fait la saisie est disponible dans session_user. En première étape de workflow aussi.

~~

Sur la proposition que cette action de déliaison "usager" intègre l'action générale "Liaison fonction/rôle", plutôt que constituer une nouvelle action, (si j'ai bien compris), ça pourrait peut-être le faire en bridant lors de la sélection de la fonction "demandeur", qu'il ne soit alors plus possible qu'une assignation "simple" / rien choisir dans rôle / mode opératoire "retirer". (ça fait peut-être bizarre)

#25

Updated by Mikaël Ates 14 days ago

Pour autant, on a quand même besoin sur le formulaire ou "en début" de workflow de connaître le form_user

Sur le formulaire l'usager qui fait la saisie est disponible dans session_user. En première étape de workflow aussi.

Qui irait ici de paire avec le besoin d'un usager connecté. Ça me semble invalider la piste « On a ailleurs (#71520) du bricolage pour éviter une saisie en étant connecté. Il me semble que ce serait la même chose ici, c'est-à-dire qu'on pourrait avoir une option sur la démarche pour dire qu'elle ne doit pas être liée à l'usager. (plutôt que la laisser se lier et commencer le workflow par la délier). »

Sur la proposition que cette action de déliaison "usager" intègre l'action générale "Liaison fonction/rôle", plutôt que constituer une nouvelle action, (si j'ai bien compris), ça pourrait peut-être le faire en bridant lors de la sélection de la fonction "demandeur", qu'il ne soit alors plus possible qu'une assignation "simple" / rien choisir dans rôle / mode opératoire "retirer". (ça fait peut-être bizarre)

Il me semble manquer un mot. L'idée ce serait que l'on désignerai l'usager (« Usager » comme sur l'action courriel par exemple), c'est à dire le demandeur (form_user), avec l'action liaison fonction-rôle et en ne mettant rien en valeur ça effacerait le form_user ?

#26

Updated by Frédéric Péters 11 days ago

  • Status changed from Solution proposée to En cours

Discussion en réunion pour aboutir à l'idée de faire ça sous forme d'une option sur l'action d'anonymisation.

#27

Updated by Paul Marillonnet 11 days ago

  • Status changed from En cours to Rejeté

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

Discussion en réunion pour aboutir à l'idée de faire ça sous forme d'une option sur l'action d'anonymisation.

(Franchement d’avis de rejeter ce ticket et de repartir sur un nouveau suite à ce revirement complet de situation.)

#28

Updated by Paul Marillonnet 11 days ago

  • Related to Development #71777: wf: ajout d’une option à l’action d’anonymisation pour effectuer la déliaison avec l’usager added

Also available in: Atom PDF