Projet

Général

Profil

Development #69120

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

Ajouté par Paul Marillonnet il y a plus d'un an. Mis à jour il y a plus d'un an.

Statut:
Rejeté
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
15 septembre 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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.


Fichiers


Demandes liées

Lié à w.c.s. - Development #71777: wf: ajout d’une option à l’action d’anonymisation pour effectuer la déliaison avec l’usagerFermé28 novembre 2022

Actions

Historique

#2

Mis à jour par Frédéric Péters il y a plus d'un an

  • Statut changé de Nouveau à Information nécessaire

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

#3

Mis à jour par Stéphane Laget il y a plus d'un an

Proposition du nom de l'action de Wf.

"Suppression du lien usager/demande"

#4

Mis à jour par Frédéric Péters il y a plus d'un an

Mais si c'est une fiche ?

#5

Mis à jour par Stéphane Laget il y a plus d'un an

oui, le ticket ne parlait que des demandes.

Proposition :
"Suppression du lien avec l'usager"

#6

Mis à jour par Frédéric Péters il y a plus d'un an

serait rangée où ?

#7

Mis à jour par Stéphane Laget il y a plus d'un an

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

serait rangée où ?

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

#8

Mis à jour par Paul Marillonnet il y a plus d'un an

  • Statut changé de Information nécessaire à En cours
  • Assigné à mis à Paul Marillonnet
#9

Mis à jour par Paul Marillonnet il y a plus d'un an

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

Mis à jour par Mikaël Ates il y a plus d'un an

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

Mis à jour par Paul Marillonnet il y a plus d'un an

  • Sujet changé de wf: action de déliaison de l’usager demandeur avec la demande soumise(?) à 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

Mis à jour par Pierre Cros il y a plus d'un an

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

Mis à jour par Frédéric Péters il y a plus d'un an

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

Mis à jour par Pierre Cros il y a plus d'un an

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

Mis à jour par Mikaël Ates il y a plus d'un an

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

Mis à jour par Paul Marillonnet il y a plus d'un an

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

Mis à jour par Frédéric Péters il y a plus d'un an

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

Mis à jour par Mikaël Ates il y a plus d'un an

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

Mis à jour par Frédéric Péters il y a plus d'un an

  • Statut changé de Solution proposée à 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

Mis à jour par Paul Marillonnet il y a plus d'un an

  • Statut changé de En cours à 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

Mis à jour par Paul Marillonnet il y a plus d'un an

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

Formats disponibles : Atom PDF