Development #41453
toulouse-axel: modifier clae_booking_activity_possible_days et clae_booking_activity_prefill sur une période arbitraire
0%
Description
Actuellement on envoie à ces deux endpoint une "booking_date" et ça renvoie les infos de la semaine concernée. Il faut changer cela : on va envoyer une date de début et une date de fin de période, booking_start_date et booking_end_date.
En retour, pour l'enfant et le type d'activité choisi, renvoyer :
- clae_booking_activity_possible_days : la liste des jours possibles, sous forme id+text, avec dans l'id toutes les informations nécessaires :
[ { "id": <idpersonne>-<idactivite>-<yyyy-mm-dd>, "text": "mercredi 8 avril 2019", "disabled": True / False, "prefill": True / False, "details": {...} }, ...
- clae_booking_activity_prefill : ['idpersonne-idactivite-date1', 'idpersonne-idactivite-date2', ...] c'est-à-dire les id de la liste ci-dessus, pour chaque jour réservé actuellement
Note 1 : vérifier qu'avoir une liste de « idpersonne-idactivite-date1 » suffira pour construire le POST ReservationPeriode, sinon modifier l'id pour y ajouter "ce qu'il faut".
Note 2 : les deux appels vont avoir lieu lors de l'affichage de la page, comme ça fait en définitive appel au même WS dans Axel il faudrait sans doute prévoir de faire du cache pour ne pas se retrouver à interroger deux fois Axel.
Note 3 : pour simplifier l'usage :- la date de début devra être repoussée à j+8 si besoin
- la date de fin sera repoussée au vendredi de la semaine concernée (exemple si c'est le mercredi 8 avril en renverra la liste jusqu'au vendredi 10 inclus)
Fichiers
Révisions associées
Historique
Mis à jour par Lauréline Guérin il y a environ 4 ans
la date de début devra être repoussée à j+8 si besoin
Et commencer un lundi du coup ?
vérifier qu'avoir une liste de « idpersonne-idactivite-date1 » suffira pour construire le POST ReservationPeriode, sinon modifier l'id pour y ajouter "ce qu'il faut".
Je laisse activity_type dans l'id, au cas où j'en ai besoin dans le POST (je ne pense pas mais ça mange pas de pain)
Mis à jour par Thomas Noël il y a environ 4 ans
Lauréline Guerin a écrit :
la date de début devra être repoussée à j+8 si besoin
Et commencer un lundi du coup ?
Nope, comme on avait dit l'autre jour, c'est vraiment j+8, il peut y avoir de la semaine partielle... En revanche il faut bien aller jusqu'au vendredi de la dernière semaine : si on s'arrêtait au jeudi par exemple, on ne saurait pas quelle information envoyer pour le vendredi.
vérifier qu'avoir une liste de « idpersonne-idactivite-date1 » suffira pour construire le POST ReservationPeriode, sinon modifier l'id pour y ajouter "ce qu'il faut".
Je laisse activity_type dans l'id, au cas où j'en ai besoin dans le POST (je ne pense pas mais ça mange pas de pain)
Ca roule.
Mis à jour par Lauréline Guérin il y a environ 4 ans
Ha non pardon je me suis mal exprimée :)
Si la date de début demandée tombe un week-end (après avoir appliqué la règle + 8 jours), alors on saute au lundi qui suit ?
Mis à jour par Lauréline Guérin il y a environ 4 ans
et si la date de fin tombe un week-end, je saute en vendredi précédent ?
(dis oui stp, j'ai déjà codé cette règle :) )
Mis à jour par Thomas Noël il y a environ 4 ans
Lauréline Guerin a écrit :
Ha non pardon je me suis mal exprimée :)
Si la date de début demandée tombe un week-end (après avoir appliqué la règle + 8 jours), alors on saute au lundi qui suit ?
Oui, si on est vendredi 10, le j+8 c'est le lundi 20, effectivement.
et si la date de fin tombe un week-end, je saute en vendredi précédent ?
(dis oui stp, j'ai déjà codé cette règle :) )
"oui stp".
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Fichier 0002-toulouse_axel-possible-days-and-prefill-for-a-period.patch 0002-toulouse_axel-possible-days-and-prefill-for-a-period.patch ajouté
- Fichier 0001-misc-remove-deprecation-warning.patch 0001-misc-remove-deprecation-warning.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Lauréline Guérin il y a environ 4 ans
Mis à jour par Thomas Noël il y a environ 4 ans
cache.set(cache_key, child_activities, 3600) # 1 hour
Une heure c'est trop : lorsque le parent aura modifié ses reservations et reviendra sur le portail il faut qu'on affiche les nouvelles valeurs. Donc mettre plutôt 30 secondes, juste le temps que les différents appels soient faits sur la page du formulaire qui présente les résas.
Tout petit détail auquel je n'avais pas pensé, le format des ID va donner 3535-MAT-A19P1M1-2020-01-20 ce qui ne va pas rendre le découpage simple, on pourrait penser à 3535:MAT:A19P1M1:2020-01-20
En dehors de ça, rien à dire. Je acke donc mais n'oublie pas de changer au moins le délai de cache à 30 secondes.
Mis à jour par Thomas Noël il y a environ 4 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 555aa3c49d2404bdf91fde84ee71d0d9b021f4fa
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date: Thu Apr 9 11:48:39 2020 +0200
toulouse_axel: possible days and prefill for a period (#41453)
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
toulouse_axel: possible days and prefill for a period (#41453)