Projet

Général

Profil

Bug #47715

Le filtre getlist + sum ne fonctionne pas dans les conditions de sortie de page

Ajouté par Marie Kuntz il y a plus de 3 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
15 octobre 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Sur un formulaire utilisant un bloc de champs, en utilisant les filtres getlist et sum pour une condition de sortie de page, la condition est toujours fausse.
Pour reproduire : https://demarches-mkuntz.test.entrouvert.org/aide-aux-commerces-de-proximite/ en mettant un nombre dans Montant total HT puis en utilisant Montant HT pour atteindre ce nombre.
La condition de sortie de page est :

form_var_reglements|getlist:"montant"|sum == form_var_montant_facture|decimal

https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/169/fields/
Bloc de champs : https://demarches-mkuntz.test.entrouvert.org/backoffice/forms/blocks/4/

Dans un commentaire sous les champs, la somme se fait bien. Dans l'inspect, la condition retourne vrai.

Testé également avec la condition

form_var_reglements|getlist:"montant"|sum == 800

en mettant des nombre de manière à atteindre 800 dans les champs


Fichiers

Révisions associées

Révision d0fd141f (diff)
Ajouté par Nicolas Roche il y a plus de 3 ans

tests: check post-condition using |getlist on block (#47715)

Révision b525483e (diff)
Ajouté par Frédéric Péters il y a plus de 3 ans

general: update formdata in context for lazy evaluation (#47715)

Historique

#3

Mis à jour par Nicolas Roche il y a plus de 3 ans

Quand on arrive dans le filtre getlist (wcs/qommon/templatetags/qommon.py::getlist) :
  • depuis l'inspecteur on a un LazyFieldVarBlock
    pdb> mapping
    <wcs.variables.LazyFieldVarBlock object at 0x7fbad4858d00>
    
  • mais en sortie de page on a une chaîne :
    pdb> mapping
    'test, test'
    

Voici un test qui permet de reproduire ce second point.
(je n'ai pas trouvé comment corriger)

#4

Mis à jour par Thomas Noël il y a plus de 3 ans

Certainement parce que les conditions de sortie ne sont pas évaluées en mode lazy.

#5

Mis à jour par Frédéric Péters il y a plus de 3 ans

  • Patch proposed changé de Oui à Non
#6

Mis à jour par Nicolas Roche il y a plus de 3 ans

Je n'ai pas réussi à faire fonctionner le test fourni (avec la condition en première page) : dans wcs/fields.py:PageCondition:get_data, l'instruction

data = super(PageCondition, self).get_data()

ne renseigne pas data['form']['var']._data qui permettrai sinon de récupérer une variable lazy pour le block.
Ie: si l'on met la condition sur la première page, alors l'attribut data de l'objet FormData est {} ; je n'ai pas compris comment est chargé cet attribut.

J'ai réécrit le test en déplaçant la condition de sortie sur une seconde page.
Dans ce cas passer le test, il suffit de supprimer la valeur "non lazy" du contexte django :

diff --git a/wcs/fields.py b/wcs/fields.py
index ca9cc9ec..4a7829ec 100644
--- a/wcs/fields.py
+++ b/wcs/fields.py
@@ -1958,2 +1958,3 @@ class PageCondition(Condition):
             data.update(form_live_data)
+        data.pop('form_var_blockfoo')
         return data

Ci-joint un patch qui tente de corriger le problème observé, mais uniquement en seconde page,
et pour information seulement car je pense qu'une correction partielle du problème risque d’amener encore plus de confusion.

#7

Mis à jour par Frédéric Péters il y a plus de 3 ans

Non, je ne pense pas que retirer une par une les variables statiques soit la solution; on doit pouvoir je pense aujourd'hui assurer que sur du rendu de gabarit, seules les parties "lazy" soient utilisées.

#8

Mis à jour par Frédéric Péters il y a plus de 3 ans

  • Assigné à mis à Frédéric Péters

Ça pourrait être compliqué, je m'en occuperai.

#11

Mis à jour par Frédéric Péters il y a plus de 3 ans

Dans la branche 0001 qui est le test produit par Nicolas, 0002 qui est le test produit dans #48950 (accès à l'attribut live après des conditions) (uniquemenent le test, pas la correction); et 0003 est le patch qui corrige le tout, en laissant la partie "ConditionVars" à l'évaluation statique uniquement, en modifiant plutôt le FormData disponible dans le contexte, pour lui ajouter les nouvelles données des champs.

#12

Mis à jour par Thomas Noël il y a plus de 3 ans

  • Statut changé de Solution proposée à Solution validée

... en groupant tout ça en un seul commit ; ou pas.

#13

Mis à jour par Frédéric Péters il y a plus de 3 ans

  • Statut changé de Solution validée à Résolu (à déployer)

Deux commits pour garder l'attribution à Nicolas,

commit b525483e36a216f783d68a9c4fbf47dd168eb671
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Sat Nov 28 18:47:55 2020 +0100

    general: update formdata in context for lazy evaluation (#47715)

commit d0fd141fb18a6471cc8cc3439040278302697418
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Wed Nov 4 18:12:39 2020 +0100

    tests: check post-condition using |getlist on block (#47715)
#14

Mis à jour par Frédéric Péters il y a plus de 3 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF