(PC-32268)[API] feat: Return individual or collective statistics only if offerer is concerned - V2

[pcharlet-pass]

But de la pull request

Ticket Jira (ou description si BSR) : https://passculture.atlassian.net/browse/PC-32268

Deuxième version utilisant des modèle pydantic différent suivant les cas rencontré plutôt que de mettre à jour les résultat de la requête clickhouse et utiliser un modèle pydantic unique plus permissif

Vérifications

• J'ai écrit les tests nécessaires
• J'ai mis à jour le fichier des plans de tests du portail pro si nécessaire
• J'ai mis à jour la liste des routes et des titres de pages du portail pro si j'en ai rajouté/modifié ou supprimé une.
• J'ai relu attentivement les migrations, en particulier pour éviter les locks, et je préviens les équipes Shérif et Data
• J'ai ajouté des screenshots pour d'éventuels changements graphiques

[github-actions]

Visit the preview URL for this PR (updated for commit 29fe92e):

https://pc-pro-testing--pr14992-pcharlet-pc-32268-st-rnp58l9c.web.app

_{(expires Fri, 15 Nov 2024 16:10:03 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 032d233ee67e1c50d6af12e29c936c7076770eb1}

[ogeber-pass]

Top, c'est mieux comme ça !

Et c'est validé côté data, les tables yearly_aggregated_venue_individual_revenue et yearly_aggregated_venue_collective_revenue ne sont pas vouées à changer au niveau du schéma (seulement la façon dont elles sont agrégées)

[damien-ramelet]

Je vois que tu as fait une seconde PR pour le même ticket, du coup je me permet de remettre ici le warning concernant cette fonction que j’ai soulevé dans la première

[dramelet-pass]

On aurait pu faire un peu plus efficace mais à priori un count sur venue ne posera pas de soucis en production

Ce qu’on cherche à faire c’est, est-ce que pour un user donné, la liste des venue_ids demandées sont toutes bien liées aux structures auquel appartient notre utilisateur ?
Dis autrement, est-ce que venue_ids est bien un subset des id de toutes les venues de toutes les structures de notre utilisateur, ce qui peut ce traduire comme ceci en SQL:

(données de sanbox)

pass_culture>
 SELECT ('{13, 14, 15}' <@ ARRAY_AGG(venue.id)) as has_all_venues FROM venue
 JOIN offerer ON offerer.id = venue."managingOffererId"
 JOIN user_offerer ON user_offerer."offererId" = offerer.id
 WHERE user_offerer."userId"=1
 GROUP BY user_offerer."userId";
+----------------+
| has_all_venues |
|----------------|
| True           |
+----------------+
SELECT 1
Time: 0.084s
pass_culture>
 SELECT ('{1, 13, 14, 15}' <@ ARRAY_AGG(venue.id)) as has_all_venues FROM venue
 JOIN offerer ON offerer.id = venue."managingOffererId"
 JOIN user_offerer ON user_offerer."offererId" = offerer.id
 WHERE user_offerer."userId"=1
 GROUP BY user_offerer."userId";
+----------------+
| has_all_venues |
|----------------|
| False          |
+----------------+
SELECT 1
Time: 0.008s

check_user_has_access_to_venues pourrait donc être modifiée comme ceci:

return db.session.execute(
    sa.select(
        sa.cast(postgresql.array(venue_ids), postgresql.ARRAY(postgresql.BIGINT)).contained_by(
            sa.func.array_agg(Venue.id)
        )
    )
    .select_from(Venue)
    .join(Offerer)
    .join(UserOfferer)
    .where(UserOfferer.userId == current_user)
    .group_by(UserOfferer.userId)
).scalar()

[pcharlet-pass]

Je me pose la question, est-ce qu'on a besoin de filtrer sur les offerers_models.UserOfferer.isValidated ? Tu l'as supprimé de la requête ci-dessus.