Development #49670
stats nombre de connexions par type d'authent, filtrage par OU
0%
Description
Je m'attendais à ce que le filtrage par OU corresponde à un filtre sur les utilisateurs associés à cette OU, mais il me semble que non, que ce serait un filtre sur "les service de l'OU choisie", avec twist supplémentaire qu'en cas d'OU liée à aucun service ça retourne les résultats globaux.
J'imaginais ce filtrage pour isoler les connexions d'usagers des connexions d'agents (en les imaginant dans des OU différentes comme dans Toodego), pour voir la part de connexions via FC chez les usagers, pas les agents.
De là je ne sais pas si ça fait sens de modifier le comportement pour correspondre à ce que j'attendais, mais sinon il faut au moins je pense ne pas avoir le twist "résultats globaux" noté dans ma première phrase.
Fichiers
Révisions associées
statistics: allow filtering by users OU (#49670)
api_views: only show filtering by OUs if relevant (#49670)
journal: empty references qs should return no statistics (#49670)
Historique
Mis à jour par Valentin Deniaud il y a plus de 3 ans
Pour info du pourquoi du comment, #47467#note-6 :
Benjamin Dauvergne a écrit :
Le cas par collectivité veut dire par collectivité du service, c'est spécifique à GLC, mais c'est important, c'est le plus gros demandeur de ces stats.
Je laisse Benj se prononcer sur ce ticket donc, après je regarderai pour le twist.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
Le cas d'usage important c'est sur les services, because GLC, mais je n'ai rien contre avoir la même chose sur les usagers, il est peut-être encore temps de renommer les clés en services-ou / users-ou pour couvrir les deux cas explicitement.
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Assigné à mis à Valentin Deniaud
Benjamin Dauvergne a écrit :
Le cas d'usage important c'est sur les services, because GLC, mais je n'ai rien contre avoir la même chose sur les usagers, il est peut-être encore temps de renommer les clés en services-ou / users-ou pour couvrir les deux cas explicitement.
OK, je vais faire ça et en bonus tenter de cacher ces filtres si ils n'ont pas de sens (une seule OU, etc).
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Fichier 0003-api_views-only-show-filtering-by-OUs-if-relevant-496.patch 0003-api_views-only-show-filtering-by-OUs-if-relevant-496.patch ajouté
- Fichier 0001-api_views-factorize-code-for-stat-decorator-49670.patch 0001-api_views-factorize-code-for-stat-decorator-49670.patch ajouté
- Fichier 0002-statistics-allow-filtering-by-users-OU-49670.patch 0002-statistics-allow-filtering-by-users-OU-49670.patch ajouté
- Tracker changé de Support à Development
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Je commence par la fin, 0003 c'est pour ne pas avoir le problème annexe que Fred mentionne, sélectionner une OU qui n'est pas rattachée à un service.
Le gros du ticket c'est 0002, et à mon avis ça va mal marcher : la seule manière de filtrer les évènements sur l'OU des utilisateurs requiert d'évaluer le queryset de tous les utilisateurs de cette OU (dans _which_references). Il y a moyen de faire autrement ?
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
Valentin Deniaud a écrit :
Je commence par la fin, 0003 c'est pour ne pas avoir le problème annexe que Fred mentionne, sélectionner une OU qui n'est pas rattachée à un service.
Il me semble que ta solution ne résoud pas le problème, tu caches simplement les OU pour lesquels ton code ne marcherait pas je suppose à cause de cette ligne :
q = Q(reference_ids__overlap=sql.ArraySubquery(qs_array))
qui je suppose est toujours vrai si qs_array est vide.
À mon avis il faut juste traiter ce cas à part, via un if not service_qs.exists(): event_qs = event_qs.none()
et idem pour les utilisateurs.
Le gros du ticket c'est 0002, et à mon avis ça va mal marcher : la seule manière de filtrer les évènements sur l'OU des utilisateurs requiert d'évaluer le queryset de tous les utilisateurs de cette OU (dans _which_references). Il y a moyen de faire autrement ?
Je dirai de ne pas utiliser _which_reference_query dans le cas des utilisateurs; la Q(uery) retournée est effectivement exhaustive (elle cherche dans Event.user et Event.reference_ids) mais pour le cas des statistiques ça ne me parait pas nécessaire, limitons nous à Event.user et dans ce cas un simple Event.objects.filter(user__ou=...)
sera rapide car entièrement traité en base.
Mis à jour par Valentin Deniaud il y a environ 3 ans
Benjamin Dauvergne a écrit :
Il me semble que ta solution ne résoud pas le problème
Elle le résout en amont, ça me semble nettement mieux. J'ajoute un 0004 sur la branche qui le résout formellement mais c'est presque artificiel du coup.
limitons nous à Event.user et dans ce cas un simple
Event.objects.filter(user__ou=...)
sera rapide car entièrement traité en base.
Oui tout à fait j'avais zappé ce champ, fait sur la branche.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Statut changé de Solution proposée à Solution validée
Valentin Deniaud a écrit :
Benjamin Dauvergne a écrit :
Il me semble que ta solution ne résoud pas le problème
Elle le résout en amont, ça me semble nettement mieux. J'ajoute un 0004 sur la branche qui le résout formellement mais c'est presque artificiel du coup.
Je suis toujours embêté sur le fait qu'une OU qui vient d'être créée n'apparaîtra pas, mais soit si on reste comme ça tu peux virer le 0004 comme tu le dis il ne sert à rien dans ce cas.
limitons nous à Event.user et dans ce cas un simple
Event.objects.filter(user__ou=...)
sera rapide car entièrement traité en base.Oui tout à fait j'avais zappé ce champ, fait sur la branche.
Ok.
Mis à jour par Valentin Deniaud il y a environ 3 ans
Benjamin Dauvergne a écrit :
tu peux virer le 0004 comme tu le dis il ne sert à rien dans ce cas.
Maintenant qu'il est là autant le garder, après tout c'est une ligne.
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 6f0be8fb080e0edad000f76e3c442a84f6397c16 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Mon Mar 1 14:41:01 2021 +0100 journal: empty references qs should return no statistics (#49670) commit 8f6d656dfd5e4429f8255ec51c86b4a152218921 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Feb 25 17:44:58 2021 +0100 api_views: only show filtering by OUs if relevant (#49670) commit fec1b06e2bd5e8f849ecc729613d68eb4cf6cbbf Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Feb 25 15:33:19 2021 +0100 statistics: allow filtering by users OU (#49670) commit 7025066efc91bbdf73d482746a4f5812ab8b10dc Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Feb 25 15:32:01 2021 +0100 api_views: factorize code for stat decorator (#49670)
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api_views: factorize code for stat decorator (#49670)