Development #10778
Publik - Project management #8652: Réaliser l'intégration du BI dans Publik
statistiques: pour les champs items liés à une datasource avoir les choix possibles dans le schéma JSON
0%
Description
Cette demande est un poil complexe, car certains champs item sont en fait utiliser pour permettre à l'utilisateur de choisir une donnée qui le concerne et non une donnée globalement définie (choisir un enfant dans sa famille VS choisir une commune), dans ce cas il est impossible de donner toutes les valeurs (et ça ne voudrait rien dire de toute façon).
Il faudrait déterminer dans quels cas il est permis de récupérer cette liste, peut-être un flag sur la datasource, ou alors simplement essayer de formater l'URL et si on arrive avec des variables de substitution globales c'est que c'est bon.
Fichiers
Historique
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
Premier souci, l'import/export JSON des fichiers et l'export API son communs, donc si j'ajoute un champ items à l'export alors que Field.items est vide, à l'import ça ne va pas le faire, je vais donc exporter ces données dans un champs nommé autrement, ou alors ajouter un paramètre booléen api pour spécialiser l'export mais ça ne me plaît pas des masses.
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
- Fichier 0001-add-options-to-ItemField-JSON-export-if-in_filters-i.patch ajouté
- Patch proposed changé de Non à Oui
L'export des options n'est fait que si ItemField.in_filters is True, il faudrait la même chose pour ItemsField mais il n'y a pas de paramètre in_filters. En lien avec le #10828 on pourra changer la condition en ItemField.anonymise is False plus tard.
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
- Fichier 0001-add-real-options-list-to-ItemField-JSON-export-fixes.patch ajouté
En expérimentant sur la dév alfortville j'ai pu voir que pour les listes à choix qui dépendent de l'utilisateur ça renvoie simplement une liste vide, ça me semble suffisant pour éviter les problèmes de données personnelles, j'ai modifié le patch en conséquence, j'ai aussi éclaté le tuple normalement renvoyé ([value, [descriptions, [key]]]) dans un dico {'value': ..., 'label': ...}, la clé est ignorée, elle n'est utile que pour le widget quixote, la valeur seule étant stocké dans le formdata (coté stat il faudra que je supprime une description en cas d'égalité entre valeurs).
Mis à jour par Frédéric Péters il y a presque 8 ans
Seul le second patch est à considérer, correct ?
Dans le test il y a deux boucles sur les mêmes valeurs, le deuxième bloc pourrait être incorporé dans la première boucle.
Mais la deuxième dans le deuxième patch, elle varie par l'absence du in_filters=True, mais ce second patch, il ne fait pas mention du tout de in_filters. (???)
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
- Fichier 0001-add-real-options-list-to-ItemField-JSON-export-fixes.patch 0001-add-real-options-list-to-ItemField-JSON-export-fixes.patch ajouté
Désolé j'ai changé d'idée en cours de route et je ne me suis pas relu, voilà un patch avec un test qui passe (in_filters n'est plus utilisé).
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
- Fichier
0001-add-options-to-ItemField-JSON-export-if-in_filters-i.patchsupprimé
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
- Fichier
0001-add-real-options-list-to-ItemField-JSON-export-fixes.patchsupprimé
Mis à jour par Benjamin Dauvergne il y a presque 8 ans
- si le GET vers la source foire ça va générer des warning, mais pas de trace, et renvoyer une liste vide, pas très joli,
- si le get_variadic_url() foire (parce que l'URL dépend de variables du formulaire ou de l'utilisateur) là on va avoir une exception EZT.
Dans le cas où c'est l'API qui demande les valeurs possibles d'une datasource il faudrait ne pas logger de warning et intercepter les exceptions EZT
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
Mis à jour par Frédéric Péters il y a 9 mois
- Statut changé de Nouveau à Fermé
- Planning mis à Non