Development #77302
backoffice: tableau de traitement & filtre, ne pas se baser sur les valeurs trouvées dans la table pour les champs item branchés sur un modèle de fiche
0%
Description
Un model de fiche A, avec des fiches,
Un model de fiche B, avec un champ item a qui pointe sur A, pas de fiches, table vide.
Aller sur le tableau de traitement, ajouter un filtre sur la colonne a, dans le select il n'y a aucune valeur, parce qu'on se base sur les valeurs trouvées dans la table b:
options = self.formdef.data_class().select_distinct( [sql.get_field_id(filter_field), '%s_display' % sql.get_field_id(filter_field)], clause=options_criterias, )
On pourrait, dans ce cas, renvoyer toutes les fiches A, peu importe ce qu'on trouve dans la table b.
(Peut-être seulement dans le mode autocomplete, pour éviter de surcharger la page avec 15000 options dans un select ?)
Demandes liées
Révisions associées
backoffice: custom view datasource, return all options (#77302)
backoffice: fix display value of autocomplete item criteria (#77302)
Historique
Mis à jour par Lauréline Guérin il y a 11 mois
Je suppose qu'à l'époque de l'introduction des tableaux de traitement et des filtres sur ceux-ci, il était pratique d'avoir dans les select les valeurs possibles, trouvées dans la table, pour éviter d'être tenté de filtrer sur une valeur inutilisées, ce qui aurait donné un tableau de traitement vide.
Mais avec l'apparition des vues personnalisées, et leur utilisation en tant que source de données, il devient impossible de créer une vue personnalisée avec une valeur qui existe dans la liste des items, mais qui n'est pas encore utilisée et donc non trouvée dans la table.
Or, on veut pouvoir définir des vues personnalisées en tout début de projet, alors que la table est vide.
Je pense qu'il n'est plus pertinent de se restreindre aux valeurs trouvées dans la table, encore plus avec l'apparition des opérateurs.
Exemple: on a les valeurs 1, 2, 3 utilisées, mais on veut un filtre != 4; impossible à définir, 4 n'étant pas utilisé.
Proposition:
1/ pour les champs item/items, toujours renvoyer l'ensemble des valeurs, quelle que soit leur utilisation (que le champ soit branché sur un modèle de fiche ou non)
2/ ne plus se baser sur le paramétrage du field autocomplete/liste pour avoir un select2 ou pas, mais à la place:
a/ si moins de 15 valeurs, select
b/ si plus de 15 valeurs, select2 (qui renvoie un max de 15 valeurs)
ceci pour éviter de surcharger la page avec un select contenant 15000 options.
Mis à jour par Frédéric Péters il y a 11 mois
1/ pour les champs item/items, toujours renvoyer l'ensemble des valeurs, quelle que soit leur utilisation (que le champ soit branché sur un modèle de fiche ou non)
Pour revenir à l'historique de pourquoi taper dans la base plutôt que prendre les options de la source de données, c'est #35703, "par exemple une source chrono avec des événements qui ne sont plus disponibles"; je pense qu'il faut garder une différence de comportement entre ce qui est fiches et source de données générique.
Mais avec l'apparition des vues personnalisées, et leur utilisation en tant que source de données, il devient impossible de créer une vue personnalisée avec une valeur qui existe dans la liste des items, mais qui n'est pas encore utilisée et donc non trouvée dans la table.
Il y a en fait un problème par le mélange de la même vue qui peut servir pour l'agent à filtrer à la volée (où il y a une utilité à voir uniquement les choix possibles) et qui doit servir à la conception de vues personnalisées. Sans résoudre toutes les situations on pourrait au moins résoudre le cas particuler de l'utilisation en source de données, qui est un cas où la vue est clairement identifiée comme telle. ?
Mis à jour par Lauréline Guérin il y a 11 mois
résoudre le cas particuler de l'utilisation en source de données
Ok, je fais ça pour ce cas seulement
Mis à jour par Robot Gitea il y a 11 mois
- Statut changé de Nouveau à En cours
- Assigné à mis à Lauréline Guérin
Lauréline Guérin (lguerin) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/wcs/pulls/320
- Titre : WIP: backoffice: custom view datasource, return all options (#77302)
- Modifications : https://git.entrouvert.org/entrouvert/wcs/pulls/320/files
Mis à jour par Robot Gitea il y a 10 mois
- Statut changé de Solution proposée à Solution validée
Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 10 mois
- Statut changé de Solution validée à Résolu (à déployer)
Lauréline Guérin (lguerin) a mergé une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/wcs/pulls/320
- Titre : backoffice: custom view datasource, return all options (#77302)
- Modifications : https://git.entrouvert.org/entrouvert/wcs/pulls/320/files
Mis à jour par Transition automatique il y a 10 mois
- Statut changé de Résolu (à déployer) à Solution déployée
Mis à jour par Lauréline Guérin il y a 10 mois
- Lié à Bug #78441: backoffice: tableau de traitement custom view avec template & select2 ajouté
backoffice: remove obsolete code (#77302)