Produits Entr'ouvert » w.c.s.

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.

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

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

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

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.

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.

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

• URL : https://git.entrouvert.org/entrouvert/wcs/pulls/161
• Titre : WIP: workflows : add an identifier to automatic and on submit jumps (#74723)
• Modifications : https://git.entrouvert.org/entrouvert/wcs/pulls/161/files

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

• URL : https://git.entrouvert.org/entrouvert/wcs/pulls/161