Produits Entr'ouvert » w.c.s.

Si la description parle bien de pouvoir définir un gabarit comme filtre d'un champ liste à choix multiple, je pense que ce ticket résoudrait #59745.

Ça accepte une liste simple "1,2,3", une liste venant d'un template "{{ "1,2" }}" (c'est moche mais ça simule le cas "{% for x in truc }{{ x.id }},{ endfor %}") et une liste directe du style "{{ form_var_items_raw }}"), ça fait un ".strip()" sur chaque élément histoire de ne pas avoir des erreurs dans les templates dues à un simple espace perdu. Si un autre séparateur a été évoqué/prévu, c'est à changer.

La demande c'est l'équivalent à #46989, c'est-à-dire qu'il y a aussi à gérer l'affichage/mise à jour sur une même page.

Ça ne gère pas le cas où on passe une liste de item['text'] (typiquement si on passe un form_var_blah où blah est un ItemsField vers une DS, et pas une liste simple) mais ce n'est pas géré non plus pour un ItemField. Si on va vers ça je pense que ça demanderait un peu de factorisation dans une méthode pour évaluer un template contenant des id ou text et obtenir la liste des ids en retour d'un seul coup (sachant que ça peut être intéressant pour un ItemField aussi de matcher une liste, en modifiant le Equal en Contains au passage, si on peut gérer les deux sans rien changer à l'interface ce sera pratique).

Suite au dernier commentaire sur #59745 je regarde le tout et en fait ça n'est pas lié à ce ticket, qui est d'avoir une "liste à choix multiples dynamique", i.e. un champ liste à choix multiples, sur un formulaire, dont le contenu varie. Alors que dans #59745 le formulaire ça reste un champ liste simple dessus, c'est le critère qui porte sur une liste à choix multiples. (ça explique totalement pourquoi je ne voyais que des trucs manquants dans le patch par rapport à ce ticket).

1 formulaire de test ici :
https://demarches-slaget.test.entrouvert.org/zz_ressources-parametrage/inscriptions-multiples-pour-test/

Qui n'existe plus; donc compliqué ce ticket :/

Bref comme c'est parti sur ma suggestion en lien avec #59745, je serais pour en faire la nouvelle interprétation, et laisser les champs sélection multiple dynamiques dans un formulaire à nouveau ticket que je créerai.

Je regarde donc enfin le code, je ne suis pas fan de la forme dans le with publisher.complex_data():, je préférais qu'on y aie un minimum, comme vu ailleurs,

+                        with publisher.complex_data():
+                            value = WorkflowStatusItem.compute(expression, allow_complex=True)
+                            value = publisher.get_cached_complex_data(value)

et ne pas introduire de gestion de valeurs multiples (qu'on n'a pas sur l'interprétation que fait /api/autocomplete/), donc dans la suite simplement,

+                        if isinstance(value, list):
+                            criteria.value = value
+                        elif isinstance(value, str):
+                            criteria.value = [value.strip()]
+                        else:
+                            criteria.value = None

En vérifiant le comportement de Intersects() avec None comme valeur, pour que ça corresponde à ce que fait l'absence de valeur sur l'autocomplete (i.e. ignorer le critère). (ça demande peut-être de retirer le critère que passer None).

pour que ça corresponde à ce que fait (…) sur l'autocomplete

À continuer à réfléchir, je pense que cette correspondance doit être centrale et que ça amène qu'on ne doit pas gérer les données complexes ici. (sauf à également vouloir se lancer dans leur prise en charge dans l'autocomplete).

Testé vite fait (pour #60423) et juste pour info, je récupère bien les valeurs dans la liste à choix multiple, mais uniquement sur une page suivante (pas en live).

Testé vite fait (pour #60423)

Oui ça n'a plus de rapport j'ai lié le bon ticket.