Development #65456
Tarification - Revoir le calcul
0%
Description
Parce qu'on n'a plus ni Event, ni Subscription, ni Booking dans lingo
Script envisagé par Thomas:
1/ (interne) construire la liste des agendas ciblés (tarifés)
2/ appel à Chrono : obtenir la liste des enfants concernés (pour tels agendas, de telle à telle date)
3/ appel à Chrono: pour chaque enfant, demander les events et l'état de la réservation éventuelle associée à chaque event trouvé (pour tels agendas, de telle à telle date)
Endpoints à prévoir dans chrono:
1/ (rien)
2/ on sait lister les subscriptions entre 2 dates sur un agenda, mais pas pour une liste d'agendas
=> prévoir un endpoint pour ça, ou lingo itère sur les agendas ?
3/ endpoint à créer: renvoyer tous les events et l'état du "pointage" pour un user_external_id donné sur une liste d'agendas entre 2 dates
pointage = statut de la réservation (peut être not-booked, cancelled, present, absent, present/absent avec un pointage précis)
parce que ça pourrait servir pour l'évaluation des variables, on voudrait aussi le booking serialisé s'il existe
Du coup, modification de l'interface de get_pricing_data:
remplacer l'argument event par:
- event: un dict de l'event serialisé renvoyé par chrono dans 3/
- subscription: un dict de l'inscription renvoyée par chrono dans 2/
- check_status: un dict du pointage/de la réservation renvoyé par chrono dans 3/
- booking: un dict de la réservation peut-être renvoyée par chrono dans 3/ (si elle existe)
On pourra injecter tout ça dans le contexte d'évaluation des variables
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Lauréline Guérin il y a presque 2 ans
dépend de #65459 pour trouver le tarif associé à un type de pointage
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Lié à Development #65459: Tarification - UI pour les types de pointage ajouté
Mis à jour par Lauréline Guérin il y a presque 2 ans
2/ pour le moment, pas de modification dans chrono. On verra si le besoin se fait sentir d'avoir un endpoint pour obtenir toutes les souscriptions d'un coup.
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Lié à Development #65770: API pour lister les events d'une liste d'agendas, pour un user donné, entre 2 dates, avec les infos de pointage ajouté
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Fichier 0001-pricing-compute-pricing-with-data-retrieved-from-chr.patch 0001-pricing-compute-pricing-with-data-retrieved-from-chr.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
se base sur #65770 (pour les dict event, subscription, booking, check_status)
refonte de la signature des méthodes de calcul
Mis à jour par Thomas Noël il y a presque 2 ans
- Statut changé de Solution proposée à Solution validée
Mon interrogation principale porte sur le calcul du QF :
Dans AgendaPricing.get_pricing_context il y a un truc qui devrait être plus évident dans le context généré, c'est la date, nécessaire typiquement pour remonter le QF (qui dépend d'un adulte et d'une date). Il faudra utiliser « data.event.start_datetime » dans le template de la donnée QF, c'est un poil lourd je trouve.
Mais plus que cela, l'appel aux templates, et donc à des cards|truc pour avoir le QF, va être fait sur chaque ligne de facture... Ca va taper sévère dans les webservices de wcs... Après, n'ayant pas encore d'idée de comment gérer cela de façon plus optimale (il faudrait faire un peu de cache, genre), je laisse tomber pour l'instant. Peut-être qu'il faudra rendre l'opération de QF nettement plus explicite, et pas "cachée" au milieu des diverses self.pricing.get_extra_variables...
Je valide donc avec cette remarque "en l'air", pour une autre discussion, ailleurs...
Mis à jour par Lauréline Guérin il y a presque 2 ans
Ca va taper sévère dans les webservices de wcs
Pas forcément, comme dans combo, les appels inter-brique sont cachés (pendant 15 secondes par défaut) - c'est url+params qui sert de clé.
Lorsqu'on récupère un qf via une extra_variable et un filtre de requête, on récupère en fait la fiche complète; si la même fiche (même url, mêmes params) est demandée dans les 15 secondes, on l'a déjà. Si tu fais bien tous tes appels enfant par enfant, on devrait souvent taper dans le cache.
pour une autre discussion, ailleurs...
Fais des tickets si tu veux :)
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit cf75e822eea928d4462b95c6b6677b0621dea738
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date: Thu Jun 2 12:04:45 2022 +0200
pricing: compute pricing with data retrieved from chrono (#65456)
Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
pricing: compute pricing with data retrieved from chrono (#65456)