Produits Entr'ouvert » w.c.s.

'évaluation du champ form_var_numero_service est en fait l'évaluation d'un attribut service qui n'existe pas du champ form_var_numero.

Ça ne devrait pas être le cas et il y a des tests pour vérifier ce cas :

    formdef.name = 'foobarlazy'
...
    formdef.fields = [
        fields.StringField(id='0', label='string', varname='foo_foo'),
...
        fields.StringField(id='6', label='string2', varname='foo_foo_baz_baz'),
...
        assert context['form_var_foo_foo'] == 'bar'
...
        assert context['form_var_foo_foo_baz_baz'] == 'other'
...

On peut fermer ce ticket où quelqu'un a vraiment constaté ce comportement ?

Même souci signalé dans #38921: variable de formulare form_var_email et variable de workflow form_var_email_destinataire.
Dans la condition d'execution d'une action form_var_email_destinataire est évalué à None.

La différence par rapport au contenu du test mentionné plus haut est qu'une est une variable de formulaire et l'autre de workflow.

J'essaie de réproduire le problème.

Réproduit dans ce test. Je me penche sur un correctif.

Formulaire et worklfow permettant de réproduire le problème.
Dans le statut "Choix du service destinataire", une fois un mail alternatif choisi il doit être affiché dans l'historique lors du passage dans le statut "Transmission de la demande".

Voici le test qui représente le cas qui arrive dans le workflow attaché: la source wcs.fields.ConditionVars rajoute les variables du formulaire dans le contexte comme form_var_email et c'est form_var_email_destinataire qui y est recherché.

Ok. Test avec action en backoffice qui provoque l'échec de calcul de la variable de traitement ayant le même espace de nommage qu'une variable du formulaire.

Mais, pour continuer à essayer de comprendre les éléments en jeu; si je fais ça sur le test :

     formdef.fields = [
-        fields.StringField(id='0', label='Foo', varname='foo')
+        fields.StringField(id='0', label='Foo', varname='whatever')
     ]

toutes les explications passées, de confusion entre le champ du formulaire et la donnée de traitement, me laisseraient penser que ça devrait résoudre l'affaire. Et pourtant le test échoue quand même.

Je continue de déconstruire le test, comprendre les bouts, genre pourquoi donc un firstof, et à force de déconstruire,

-    st2.items.append(jump)
     st2.items.append(setbo)
+    st2.items.append(jump)

que la donnée de traitement soit posée avant le saut, vu que le saut est basé sur la condition.

Et enfin, à ce moment, le test semble rejoindre ce qui est cherché.

De là, répondre que non le firstof n'a pas de rapport,

-    setbo.fields = [{'field_id': 'bo1', 'value': '{% firstof local_var_str2 local_var_str1 %}'}]
+    setbo.fields = [{'field_id': 'bo1', 'value': 'go'}]

et en arriver juste à faire comme à l'édition d'une demande, l'appel à clean_submission_context(),

@@ -216,6 +216,7 @@ class FormWorkflowStatusItem(WorkflowStatusItem):
         if form.get_submit() == 'submit' and not form.has_errors():
             self.evaluate_live_form(form, formdata, user)
             formdata.store()
+        get_publisher().substitutions.unfeed(lambda x: x.__class__.__name__ == 'ConditionVars')

     def get_parameters_view(self):

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

[...]

que la donnée de traitement soit posée avant le saut, vu que le saut est basé sur la condition.

Effectivement je me suis melé les pinceaux dans l'ordre de déclaration des actions. Et le firsof était pour me rapprocher du workflow joint plus haut. Une simple affectation suffisait.

et en arriver juste à faire comme à l'édition d'une demande, l'appel à clean_submission_context(),

Ma première idée fut de trouver une solution au niveau de l'algo de recherche du champ dans le contexte alimenté par toutes les sources.
Mais seule ConditionsVars empêche de remonter jusqu'à form dans le contexte et ta solution me paraît bien.

commit dbe8ba569ca397a6d4d9996b0a3f07631a3ba4db
Author: Serghei Mihai <smihai@entrouvert.com>
Date:   Mon Jan 27 20:10:03 2020 +0100

    workflows: clean context after workflow form action (#39030)