Produits Entr'ouvert » Combo

Version wip, me reste à écrire des tests et prendre en charge les filtres déclarés dans le retour de l'API.

• 0001, réduire les niveaux d'indentation en utilisant des fixtures
• 0002, quitte à pourrir l'historique, autant en profiter pour passer un coup de black

• Data migration pour mettre à jour les cellules existantes. Elle est splittée en 3 fichiers parce que postgres ne tolère pas qu'on change les données et le schéma en même temps (en vrai la migration en un seul fichier passe chez moi en local, mais pas dans le test, dunno why).
• En prévision du patch d'après, les visualisation sont désormais systématiquement préfixées du nom du site. Ça ne va pas rendre génial puisque bijoe s'appelle par défaut « Statistiques », je suis preneur d'idées pour faire mieux.

Et le ticket commence à être traité seulement dans 0004 : un nouveau setting (à poser par hobo ?) indique dans quelles briques aller chercher les stats. Puis prise en charge du nouveau format de l'API, c'est deux lignes mais le diff est un peu gros car je bouge du code en introduisant une séparation entre configuration de graphe, commun à tout le monde, et parsing de la réponse, séparé entre bijoe et les autres.

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

Je serais pour un setting qui soit la liste des URL, plutôt que des identifiants de brique, l'idée étant qu'ainsi on pourra facilement ajouter des statistiques ad hoc, peut-être aussi simplement qu'en posant deux fichiers json sur un serveur statique.

Les identifiants de brique ça a le mérite de bien marcher en cas d'import/export entre recette et prod, peut-être ajouter le support des urls en plus et pas à la place ?

Par contre, ?time_interval=... je ne vois pas ce qui dans l'API listant les statistiques indique que ça existe, et je suis un peu frileux à partir là-dessus dès maintenant, j'aurais préféré que soit listées explicitement comme statistiques "... par mois", "... par année", etc.

Authentic expose déjà 6 visualisations différentes, j'aimerais éviter d'en avoir 18. Dans ton pad tu indiques que les regroupements temporels c'est 75% des stats, je me disais qu'il y avait moyen qu'un champ dédié à ça soit toujours utile.
Mais je suis d'accord que c'est prématuré, et qu'il n'y a aucune raison que ça ne soit pas un filtrage optionnel comme celui sur ou/service, déclaré comme tel dans l'API de listing, je vais plutôt faire comme ça.

Et donc décision de splitter tout ça dans plusieurs tickets, les histoires de db dont je parlais dans mes premiers patches c'est maintenant #49173 (prérequis à ce ticket tout de même), et les filtres ce sera #49175.

ajouter le support des urls en plus

Décision aussi de faire ça dans un prochain ticket.

• 0001 parce que la méthode get_chart de bijoe est bien trop longue, et qu'il faut permettre la réutilisation de certains bouts.
• 0002 le gros du boulot.
• 0003 correction en passant d'un bug déjà là, render_table de pygal crashe si pas de données.

Go.

commit d8fbda7d4241db8e001a4dbf5abba44885c5bd0d
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Mon Dec 7 12:35:56 2020 +0100

    dataviz: avoid crash if no table data (#48865)

commit 18fdd8a8c4f2f8f5e69bf4ca88f29a16bd2ae4a2
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Mon Nov 30 14:10:39 2020 +0100

    dataviz: handle new api to get statistics from elsewhere (#48865)

commit b615b7fa998b907b079c2b76b22692cfcffdbe49
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Wed Dec 16 11:09:55 2020 +0100

    tests: add dataviz null visualization (#48865)

commit 4f878ac96ae31e42c735720d6d49843e40788a1f
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Dec 3 15:08:17 2020 +0100

    dataviz: split get_chart into several methods (#48865)