(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 ee1de0f):

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

_{(expires Sat, 16 Nov 2024 09:47:20 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.

[damien-ramelet]

Oui je n'ai pas repris totalement le contenu de la requête, c'était juste un exemple. Mais oui on doit s'assurer que le rattachement de l'utilisateur à la structure a été validé, on ne souhaite pas que n'importe qui demande un rattachement et puisse ensuite interoger les revenus de ladite structure. Donc oui ça me paraît pertinent de filtrer sur UserOfferer.isValidated : )

[damien-ramelet]

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) 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";
+----------+
| ?column? |
|----------|
| True     |
+----------+
SELECT 1
Time: 0.084s
pass_culture>
 SELECT '{1, 13, 14, 15}' <@ ARRAY_AGG(venue.id) 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";
+----------+
| ?column? |
|----------|
| False    |
+----------+
SELECT 1
Time: 0.008s

check_user_has_access_to_venues pourrait donc être modifiée comme ceci:

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

[damien-ramelet]

Oui je n'ai pas repris totalement le contenu de la requête, c'était juste un exemple. Mais oui on doit s'assurer que le rattachement de l'utilisateur à la structure a été validé, on ne souhaite pas que n'importe qui demande un rattachement et puisse ensuite interoger les revenus de ladite structure. Donc oui ça me paraît pertinent de filtrer sur UserOfferer.isValidated : )

[ogeber-pass]

Suggested change

	def test_get_statistics_with_unvalidated_offereruser_should_fail(self, client):
	def test_get_statistics_with_unvalidated_userofferer_should_fail(self, client):

[ogeber-pass]

✅ LGTM