Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

On part vers la production d'une API interne (pour exploitation soit en BO soit en API, on va pas traiter ça pour l'instant).

Un peu trop théorique pour que j'arrive à bien avancer. J'ai écrit une méthode qui est capable de renvoyer les stats attendues par la description, je veux bien des pointeurs vers où aller ensuite.

Tu réponds en partie à la demande, il faudrait à partir de ton code produire les données pour les cas listés: connexion par mode de connexion, connexion par services et modes de connexion, idem pour création de compte. Ce serait bien si ça sortait directement les bons labels pour les modes de connexion qu'on ait pas à maintenir ça ailleurs. 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.

et pour les stats à plusieurs dimensions (méthode + service/ou), j'invente un truc dont je ne sais pas ce qu'il vaut (cf test).

Je ne vois pas dans les tests la situation, que je ne suis pas sûr de comprendre.

Dans le pad, j'ai ajouté tout à l'heure une section sur l'API pour lister les visualisations disponibles (pour exposer ces séries de statistiques).

Côté x_labels ils doivent pour moi correspondre à ce qui sera affiché à l'usager, i.e. pour l'année, "2020" et pas "2020-01-01T00:00:00+01:00". (ou alors on part tout de suite sur des métadonnées supplémentaires pour décrire le x_labels, genre "x_datatype": "time:years").

Truc aussi, pour ces événements qui sont liés au temps, il ne faudrait pas que l'absence de données sur une période fasse sauter celle-ci, concrètement si 5 personnes de logguent en février, 0 en mars, 10 en avril, je ne voudrais pas que mars soit zappé des données. (ou alors on part pareil à se dire qu'il y aura métadonnées et que combo saura que c'est une série chronologique et aura en responsabilité de compléter, ça me va).

Frédéric Péters a écrit :

Truc aussi, pour ces événements qui sont liés au temps, il ne faudrait pas que l'absence de données sur une période fasse sauter celle-ci, concrètement si 5 personnes de logguent en février, 0 en mars, 10 en avril, je ne voudrais pas que mars soit zappé des données. (ou alors on part pareil à se dire qu'il y aura métadonnées et que combo saura que c'est une série chronologique et aura en responsabilité de compléter, ça me va).

Autant c'est simple pour l'axe temporel X autant ce sera vraiment plus compliqué pour combo pour les Y même si ça a moins de chance d'arriver. « aucun évènement sur la période pour le service X par exemple » ce serait dommage de voir le service disparaître des statistiques dans ce cas, même s'il n'y a rien à en dire, c'est perturbant. Dans bijoe je m'assure d'avoir soit la totalité des valeurs dans la requête (pour l'axe temporel) soit je génère l'axe hors requête et je complète au moment de générer les résultats.

Je ne suis néanmoins pas gêné que le problème ne soit pas traité à ce stade si on en a conscience.

La situation c'est un peu genre les loop_labels que peut renvoyer bijoe j'ai l'impression

Mais c'est un truc qui génère plusieurs graphes, qui peuvent avoir des libellés différents sur leurs axes (et du coup pas repris dans combo qui affiche un seul graphe). Je n'ai pas vraiment l'impression que dans tes exemples tu tapes vraiment sur ce qui me pose problème, mais la description du ticket laisse ça discrètement hors des exemples.

Tu représenterais ça comment dans l'API, et avec quoi comme représentation dans un graphe unique, avec quel code pygal ?

Ma réponse à ça est d'ignorer la question et de laisser à l'agent qui configure le portail de configurer plusieurs graphes s'il le souhaite, parce que dans la liste des données possibles fournies par Authentic il y aura "méthodes de connexion, par mois", "méthodes de connexion, par mois (collectivité par défaut)", "méthodes de connexion, par mois (une autre collectivité)", etc.

Frédéric Péters a écrit :

La situation c'est un peu genre les loop_labels que peut renvoyer bijoe j'ai l'impression

Tu représenterais ça comment dans l'API, et avec quoi comme représentation dans un graphe unique, avec quel code pygal ?

Ce genre de tableau n'est pas représentable en graphique, par contre pour une seule collectivité/un seul service on peut empiler les chiffres par mode d'authentification ou bien utiliser plusieurs lignes.

• oublier ce tableau, virer le code qui permet de le produire
• rajouter du code pour avoir les données des méthodes d'authentification pour un service/ou fixé
• rajouter du code pour avoir le nombre total d'authentification pour chaque service/ou, toutes méthodes confondues

Et plutôt partir sur des x_labels affichables tels quels, ou sur l'idée qu'il y aura des métadonnées et que ce sera à combo de le faire ?

Et plutôt partir sur des x_labels affichables tels quels, ou sur l'idée qu'il y aura des métadonnées et que ce sera à combo de le faire ?

À un moment passer la main à combo avec des donnés qualifiées, genre "x_labels_type": "time:month"; soit dès maintenant, soit plus tard (mais alors avoir des libellés directement intelligibles). (et je pense que 2020-11 même si pas idéal est intelligible, serait ok dès maintenant, même sans prise en charge d'un x_labels_type côté combo).

rajouter du code pour avoir les données des méthodes d'authentification pour un service/ou fixé

Dans l'immédiat oui, plus loin j'imaginerais que dans les métadonnées fournies par le graphe "nombre de connexions" il y ait une info genre

  filters: [{"id": "ou", "label": "Collectivités", "option": [{"id": "", "label": "Toutes"}, {"id": "ou-1": "label": ...}...]}

Et le choix se ferait lors de la configuration de la cellule, sur base de ces filtres, plutôt que sur base d'une liste de données reprenant toutes les variations d'OU ou de services.