Project

General

Profile

Bug #32326

Cheminement trop profond dans un workflow si deux trigger ont le même nom

Added by Emmanuel Cazenave 4 days ago. Updated 3 days ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
Start date:
15 Apr 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Dans https://demarches-venissieux-test.demarches.sitiv.fr/backoffice/workflows/24/, deux paiements successifs (une caution, un paiement normal), et donc nécessairement deux triggers 'paid'.

Une demande dans le statut 'Attente paiement caution', dont le statut suivant s'atteint par un trigger 'paid', puis deux statuts plus loin (par des sauts automatiques), un statut 'Attente paiement salle', sur lequel le deuxième trigger 'paid'.

Lorsque le trigger 'paid' est appelé, l'avancement des statuts ne s'arrête pas à 'Attente paiement salle', ça se poursuit au delà.

0001-workflows-jump-on-trigger-only-once-32326.patch View (3.4 KB) Thomas Noël, 15 Apr 2019 05:27 PM

Associated revisions

Revision e3a4f928 (diff)
Added by Thomas Noël 3 days ago

workflows: jump on trigger only once (#32326)

History

#1 Updated by Thomas Noël 4 days ago

Analyse : c'est parce que l'appel à l'URL jump/trigger/xxx fait un «get_request().trigger_name = xxx» qui continue d'exister lors du parcours des must_jump des sauts suivants.

#2 Updated by Thomas Noël 4 days ago

... et à vue de nez ce trigger_name ne sert en réalité à rien (on a déjà testé «component == item.trigger» quand on lance le jump_and_perform) ?

diff --git a/wcs/wf/jump.py b/wcs/wf/jump.py
index 476b1899..aad84119 100644
--- a/wcs/wf/jump.py
+++ b/wcs/wf/jump.py
@@ -79,7 +79,6 @@ class TriggerDirectory(Directory):
                     pass
                 elif not item.check_auth(self.formdata, user):
                     raise errors.AccessForbiddenError()
-                get_request().trigger_name = component
                 if item.must_jump(self.formdata):
                     workflow_data = None
                     if hasattr(get_request(), 'json'):
@@ -232,11 +231,6 @@ class JumpWorkflowStatusItem(WorkflowStatusJumpItem):
             except RuntimeError:
                 must_jump = False

-        if self.trigger:
-            triggered = (hasattr(get_request(), 'trigger_name') and
-                         get_request().trigger_name == self.trigger)
-            must_jump = must_jump and triggered
-
         if self.timeout:
             timeout = int(self.compute(self.timeout))
             last = formdata.last_update_time

#3 Updated by Thomas Noël 4 days ago

(je veux bien une très rapide review avant de me lancer dans l'écriture d'un test ; sachant que les tests actuels sur trigger semblent ok avec ce patch)

#4 Updated by Thomas Noël 4 days ago

  • Status changed from Nouveau to En cours
  • Assignee set to Thomas Noël

#5 Updated by Benjamin Dauvergne 4 days ago

L'analyse m'a l'air ok, comme on fait déjà le jump_and_perform() dans le TriggerDirectory on n'a effectivement pas besoin de gérer les trigger dans perform().

#6 Updated by Thomas Noël 4 days ago

Et en fait il faut garder le "if self.trigger" dans le must.jump pour que les sauts qui imposent un trigger ne soient pas exécutés. Voici donc une autre proposition de correction.

#7 Updated by Frédéric Péters 3 days ago

  • Status changed from Solution proposée to Solution validée

En imaginant que personne n'a jamais profité de cette situation pour que s'enchainent automatiquement plusieurs sauts à partir d'un même appel trigger.

#8 Updated by Thomas Noël 3 days ago

  • Status changed from Solution validée to Résolu (à déployer)

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

En imaginant que personne n'a jamais profité de cette situation pour que s'enchainent automatiquement plusieurs sauts à partir d'un même appel trigger.

La première personne que j'ai vu le faire a ouvert ce ticket :)

commit e3a4f9281700243675bc93749966c31a7c630b6a
Author: Thomas NOEL <tnoel@entrouvert.com>
Date:   Mon Apr 15 17:24:47 2019 +0200

    workflows: jump on trigger only once (#32326)

#9 Updated by Frédéric Péters 3 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

#10 Updated by Emmanuel Cazenave 3 days ago

Ça marche nickel, je remercie solennellement l'ensemble des intervenants.

Also available in: Atom PDF