Project

General

Profile

Development #74723

Donner accès à l'identifiant d'un saut manuel dans les conditions d'exécutions d'action

Added by Emmanuel Cazenave about 1 year ago. Updated 7 months ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
21 February 2023
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Un statut 'foo' avec une action d'envoi de mail. Ce statut est atteignable par deux sauts manuels dont les identifiants sont X et Y.

On voudrait envoyer le mail uniquement si on arrivés dans 'foo' via le saut 'X'

Le contournement actuel consiste à créer un statut intermédiaire 'bar', dans lequel on passera en faisant le saut X avant d'arriver sur 'foo'. Et dans 'bar' d'utiliser une donnée de traitement qui sera utilisable dans la condition d'envoi de mail de 'foo'.

De Steph L dans le chat :

oui grande idée, pas mal de cas d'usage connexe où on passe par des statut intermédiaires qui ne servent à rien, sauf à repérer le saut manuel utilisé


Related issues

Related to w.c.s. - Development #74132: Interdire dans un même statut deux sauts avec le même identifiant. (ValueError: form already has 'button-action-st-annuler' widget)Fermé02 February 2023

Actions

History

#6

Updated by Emmanuel Cazenave about 1 year ago

  • Status changed from Nouveau to Information nécessaire
  • Assignee set to Stéphane Laget

@StephL, d'une discussion orale avec Fred, un truc qui serait utile de savoir dans tes cas d'usages c'est si on est surtout dans des cas simples :

  • un statut A un statut B qui s'atteint par deux manuels différents depuis A, et dans ce statut B le besoin de savoir par quelle saut manuel est passé la demande pour décider de déclencher ou non une action.

Ou est-ce qu'il y a aussi des cas plus complexes :

  • toujours les deux statuts A/B avec deux sauts manuels mais le besoin de savoir par quel saut on est passé ne se présente que plus loin dans le workflow, dans un statut C ?
  • encore des situations plus complexes/différentes ?
#7

Updated by Stéphane Laget about 1 year ago

  • Assignee changed from Stéphane Laget to Emmanuel Cazenave

Emmanuel Cazenave a écrit :

@StephL, d'une discussion orale avec Fred, un truc qui serait utile de savoir dans tes cas d'usages c'est si on est surtout dans des cas simples :

  • un statut A un statut B qui s'atteint par deux manuels différents depuis A, et dans ce statut B le besoin de savoir par quelle saut manuel est passé la demande pour décider de déclencher ou non une action.

Je me dis que c'est le cas le plus courant.
Si dans des cas limite, il était nécessaire de garder cette information au-delà du statut B, pour l'utiliser plus loin dans le workflow, je pourrais alors alimenter une donnée de traitement dans le statut B de manière conditionnelle. Donc la 1ʳᵉ proposition suffirait.

#8

Updated by Pierre Cros about 1 year ago

Comme tu demandes des situation plus complexes, questions que je me pose :

  • le saut manuel "toto" vers X a été exécuté une fois puis on repasse dans X mais via un autre saut que se passe-t-il ? La réponse est différente pour moi selon que l'on utilise le saut comme un indice de passage ou comme une provenance.
    • Parfois on voudra juste savoir que le clic sur le bouton a eu lieu à un moment et il suffira que la condition form_workflow_jump_toto soit vraie, c'est ce qui est décrit dans le ticket jusqu'à maintenant je crois.
    • D'autres fois on voudra savoir qu'on vient d'arriver par ce saut et on voudra que la condition form_workflow_jump_toto_just_clicked (hum) soit vraie
  • Si on va vers ça, est-il envisageable de l'étendre aussi aux sauts automatiques, ça permettrait de ne plus écrire de conditions concernant le nom du statut précédent (ce qui est assez fragile). Si ça doit être un autre ticket, désolé pour le détournement.
Pour traduire ces 2 points en cas d'usage (même si je pense que c'est évident) :
  • Je fais une demande d'information à l'issue de laquelle je reviens dans le statut initial, certaines actions dans ce statut initial peuvent être conditionnée par le saut, j'ai besoin de savoir que form_workflow_jump_toto_just_clicked est vrai
  • J'ai un statut "validation interne" dans lequel plusieurs services doivent intervenir, on fait souvent "boucler" pour passer par un statut spécifique à chaque service après validation par ce dernier (pour positionner une donnée de traitement), avant de revenir sur le statut initial automatiquement, j'ai besoin de savoir que form_workflow_jump_toto est vrai.
#9

Updated by Anaïs Ecuvillon about 1 year ago

Pierre Cros a écrit :

  • Si on va vers ça, est-il envisageable de l'étendre aussi aux sauts automatiques, ça permettrait de ne plus écrire de conditions concernant le nom du statut précédent (ce qui est assez fragile). Si ça doit être un autre ticket, désolé pour le détournement.

oui très juste, ça me serait utile également

#10

Updated by Emmanuel Cazenave about 1 year ago

Je tente une synthèse, sans aucune notion de la complexité d'implémentation :

  • form_workflow_jumps : une liste qui contient les identifiants des sauts par lesquels la demande est passée successivement, qui permet de faire des contions genre @'xx' in form_workflow_jumps, qui répond à la question du passage
  • form_workflow_last_jump qui donne l'identifiant d'un saut uniquement si la demande est dans un statut qui vient d'être atteint par ce saut, qui permet de faire des conditions genre form_workflow_last_jump == 'XX', qui répond à la question de la provenance.

Noté le besoin que les sauts automatiques soient inclus (ce qui demande un détour par l'ajout de la possibilité d'ajouter un identifiant sur les sauts automatiques, à moins que l'on veuille utiliser l'existant "Identifiant d’appel webservice" que l'on pourrait renommer ?).

#11

Updated by Emmanuel Cazenave about 1 year ago

  • Status changed from Information nécessaire to En cours

Emmanuel Cazenave a écrit :

Je tente une synthèse

Je vais considérer que tout le monde trouve ça super et m'y mettre.

#12

Updated by Pierre Cros about 1 year ago

Sorry, raté ton message d'avant.

Je savais pas qu'il était possible d'utiliser "Identifiant d’appel webservice" pour les sauts auto.

Mais je préférerais de très loin le détour que tu évoques (donner un identifiant aux sauts auto) parce que ça permet d'avoir, du point de vue de l'admin fonctionnel, quelque chose d'homogène pour les deux sauts.

Concernant ta synthèse : pas mieux, cool.

#13

Updated by Emmanuel Cazenave about 1 year ago

Pierre Cros a écrit :

Mais je préférerais de très loin le détour que tu évoques

Oui même avis je pars là dessus.

#14

Updated by Robot Gitea about 1 year ago

Emmanuel Cazenave (ecazenave) a ouvert une pull request sur Gitea concernant cette demande :

#15

Updated by Robot Gitea about 1 year ago

  • Status changed from En cours to Solution proposée
#16

Updated by Robot Gitea about 1 year ago

  • Status changed from Solution proposée to En cours

Benjamin Dauvergne (bdauvergne) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#17

Updated by Robot Gitea about 1 year ago

Benjamin Dauvergne (bdauvergne) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#18

Updated by Emmanuel Cazenave 12 months ago

  • Related to Development #74132: Interdire dans un même statut deux sauts avec le même identifiant. (ValueError: form already has 'button-action-st-annuler' widget) added
#19

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

  • Status changed from En cours to Solution proposée
#20

Updated by Robot Gitea 7 months ago

  • Status changed from Solution proposée to En cours

Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#21

Updated by Emmanuel Cazenave 7 months ago

  • Status changed from En cours to Solution proposée
#22

Updated by Robot Gitea 7 months ago

  • Status changed from Solution proposée to En cours

Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#23

Updated by Emmanuel Cazenave 7 months ago

  • Status changed from En cours to Solution proposée

Also available in: Atom PDF