Projet

Général

Profil

Development #49670

stats nombre de connexions par type d'authent, filtrage par OU

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

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
22 décembre 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

Révision c27792ec (diff)
Ajouté par Valentin Deniaud il y a environ 3 ans

api_views: factorize code for stat decorator (#49670)

Révision dd3ed19a (diff)
Ajouté par Valentin Deniaud il y a environ 3 ans

statistics: allow filtering by users OU (#49670)

Révision 2d803b4a (diff)
Ajouté par Valentin Deniaud il y a environ 3 ans

api_views: only show filtering by OUs if relevant (#49670)

Révision e2fa4ca6 (diff)
Ajouté par Valentin Deniaud il y a environ 3 ans

journal: empty references qs should return no statistics (#49670)

Historique

#1

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.

#2

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.

#3

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).

#4

Mis à jour par Valentin Deniaud il y a environ 3 ans

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 ?

#5

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.

#6

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.

#7

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.

#8

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.

#9

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)
#10

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

Formats disponibles : Atom PDF