workflows: store trigger data in structured objects (#64818) #835

Merged
fpeters merged 1 commits from wip/64818-trigger-data-part into main 2023-11-15 19:07:04 +01:00
Owner
No description provided.
tnoel reviewed 2023-11-14 09:19:01 +01:00
@ -58,6 +59,10 @@ class HookDirectory(Directory):
if hasattr(get_request(), '_json'):
workflow_data = {self.trigger.identifier: get_request().json}
self.formdata.update_workflow_data(workflow_data)
if get_request().json:
Owner

Je serai pour toujours enregistrer, même si on a reçu du vide, pour que l'interrogation de form_trigger_xxx renvoie bien le dernier appel reçu.

Je serai pour toujours enregistrer, même si on a reçu du vide, pour que l'interrogation de form_trigger_xxx renvoie bien le dernier appel reçu.
fpeters marked this conversation as resolved
tnoel reviewed 2023-11-14 09:30:00 +01:00
wcs/variables.py Outdated
@ -1002,0 +1006,4 @@
# (index can be "latest")
from .wf.jump import LazyFormDataWorkflowTriggers
return LazyFormDataWorkflowTriggers(self._formdata)
Owner

(commentaire posé ici mais c'est un peu général)

L'idée d'avoir un seul type de Part pour les appels sur les actions globales ou les sauts, et donc que form_trigger_xxx renvoie le dernier "xxx" reçu quelque soit le type d'appel, c'est voulu ? Note que ça me va très bien, c'est juste la question de savoir si c'est bien une feature :)

Je me demande quand même dans quelle mesure on ne pourrait pas stocker dans WorkflowTriggeredEvolutionPart l'origine de l'appel (global ou jump, et une référence vers l'action ou le saut). Peut-être sans l'exposer au départ, mais à terme je verrais bien :

  • les données : form_trigger_paid_var_XXX
  • le type de provenance : form_trigger_paid_kind (type d'appel, 'global' ou 'jump')
  • le moment de la réception : form_trigger_paid_datetime
  • la reférence : form_trigger_paid_global_action ? form_trigger_paid_jump ? (là je sèche un peu, mais bon, stocker l'affaire, déjà)
  • le user qui a fait l'appel : form_trigger_paid_user

l'idée étant que dans un workflow, quand on va faire référence à form_trigger_paid_xxx on pourra savoir d'où les données viennent, quand elles sont arrivée, qui, etc.

(commentaire posé ici mais c'est un peu général) L'idée d'avoir un seul type de Part pour les appels sur les actions globales ou les sauts, et donc que form_trigger_xxx renvoie le dernier "xxx" reçu quelque soit le type d'appel, c'est voulu ? Note que ça me va très bien, c'est juste la question de savoir si c'est bien une feature :) Je me demande quand même dans quelle mesure on ne pourrait pas stocker dans WorkflowTriggeredEvolutionPart l'origine de l'appel (global ou jump, et une référence vers l'action ou le saut). Peut-être sans l'exposer au départ, mais à terme je verrais bien : * les données : form_trigger_paid_var_XXX * le type de provenance : form_trigger_paid_kind (type d'appel, 'global' ou 'jump') * le moment de la réception : form_trigger_paid_datetime * la reférence : form_trigger_paid_global_action ? form_trigger_paid_jump ? (là je sèche un peu, mais bon, stocker l'affaire, déjà) * le user qui a fait l'appel : form_trigger_paid_user l'idée étant que dans un workflow, quand on va faire référence à form_trigger_paid_xxx on pourra savoir d'où les données viennent, quand elles sont arrivée, qui, etc.
Author
Owner

J'ai :

  • les données : form_trigger_paid_content_…
  • le type de provenance : form_trigger_paid_kind (global ou jump)
  • le moment de la réception : form_trigger_paid_datetime

mais pas encore les deux autres, que je garderais bien pour plus tard (via le WorkflowTrace qui s'écrit en même temps on doit déjà pouvoir retrouver l'origine, je me demande dans quelle mesure les deux objets pourraient être liés, mais je préfère ne pas m'avancer là-dedans pour le moment).

J'ai : * les données : form_trigger_paid_content_… * le type de provenance : form_trigger_paid_kind (global ou jump) * le moment de la réception : form_trigger_paid_datetime mais pas encore les deux autres, que je garderais bien pour plus tard (via le WorkflowTrace qui s'écrit en même temps on doit déjà pouvoir retrouver l'origine, je me demande dans quelle mesure les deux objets pourraient être liés, mais je préfère ne pas m'avancer là-dedans pour le moment).
tnoel marked this conversation as resolved
fpeters force-pushed wip/64818-trigger-data-part from d5133f5794 to f291888f4b 2023-11-14 09:42:56 +01:00 Compare
fpeters force-pushed wip/64818-trigger-data-part from f291888f4b to aee7a76488 2023-11-14 11:40:12 +01:00 Compare
fpeters force-pushed wip/64818-trigger-data-part from aee7a76488 to 8a3c045620 2023-11-14 11:50:07 +01:00 Compare
fpeters force-pushed wip/64818-trigger-data-part from 8a3c045620 to ca6fe5ab00 2023-11-14 12:14:19 +01:00 Compare
fpeters force-pushed wip/64818-trigger-data-part from ca6fe5ab00 to 67ac4bd7e6 2023-11-14 13:16:00 +01:00 Compare
fpeters force-pushed wip/64818-trigger-data-part from 67ac4bd7e6 to a781a7325f 2023-11-14 13:18:56 +01:00 Compare
fpeters force-pushed wip/64818-trigger-data-part from a781a7325f to 7938b23849 2023-11-14 13:32:30 +01:00 Compare
fpeters changed title from WIP: workflows: store trigger data in structured objects (#64818) to workflows: store trigger data in structured objects (#64818) 2023-11-14 14:16:39 +01:00
tnoel approved these changes 2023-11-14 17:00:04 +01:00
tnoel left a comment
Owner

Éventuellement un petit truc à ajouter dans les tests, sinon c'est tout OK selon moi.

Éventuellement un petit truc à ajouter dans les tests, sinon c'est tout OK selon moi.
@ -533,0 +560,4 @@
assert formdata.workflow_data == {'plop': {'test': 'BAR'}}
substvars = CompatibilityNamesDict()
substvars.update(formdata.get_substitution_variables())
assert substvars['form_trigger_plop_content_test'] == 'BAR'
Owner

Ajouter un
assert substvars['form_trigger_plop_kind'] == 'global'
et ça sera bien complet.

Ajouter un `assert substvars['form_trigger_plop_kind'] == 'global'` et ça sera bien complet.
fpeters marked this conversation as resolved
fpeters force-pushed wip/64818-trigger-data-part from 7938b23849 to 0955e37a8c 2023-11-14 17:57:12 +01:00 Compare
fpeters merged commit 0955e37a8c into main 2023-11-15 19:07:04 +01:00
fpeters deleted branch wip/64818-trigger-data-part 2023-11-15 19:07:04 +01:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/wcs#835
No description provided.