Projet

Général

Profil

Development #56284

Idée : avoir un délai de réservation qui soit en journée horaire et pas calendaire

Ajouté par Benjamin Dauvergne il y a plus de 2 ans. Mis à jour il y a 12 mois.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
20 août 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Actuellement min_booking_datetime est appliqué en jours calendaires, i.e on se place à midi le jour de l'évènement/rdv et on recule de delay-1 jours puis on se recale à 00h00 le matin.

C'est généralement la bonne chose à faire pour des évènements lambda en quantité suffisante par rapport à la demande des usagers ou alors par contrainte légale, pour accès à un service public (mais en fait on devrait se caler sur l'heure d'ouverture des bureaux, mais ce n'est pas le sujet).

Mais pour certains évènements dont on limite volontaire le délai minimal pour éviter que les gens ne réservent tous les créneaux à l'avance ça crée un bouchon temporaire parce que les gens découvrent assez vite qu'il faut venir à minuit.

Ma proposition serait d'avoir un flag pour indiquer que les délais doivent être calculés à l'heure près start_datetime - timedelta(hours=24 * delay) pour éviter cette situation (je pense aux piscines mais ça pourrait être des RdV vaccinations). Ça aurait le mérite de, quasi naturellement, lisser la charge sur la journée.

PS: ça pourrait aussi être un champ minimal_time qui serait à 00h00 par défaut pour les agendas existants et qu'on pourrait soit mettre à vide (calcul exact) soit mettre à une heure quelconque autre (heure d'ouverture des bureaux).


Demandes liées

Lié à Publik - Development #70476: Ouvrir des blocs de réservation paramétrables Fermé19 octobre 2022

Actions
Lié à Chrono - Development #71918: Les soucis de date autour des changements heure d'été/hiver viennent de pytz/djangoFermé01 décembre 2022

Actions
Lié à Chrono - Development #75884: manager, utiliser widgets.TimeWidget pour l'heure de réservation minimaleFermé28 mars 2023

Actions

Historique

#2

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

J'aime toujours beaucoup mon idée, celui qui l'implémentera aura ma reconnaissance éternelle.

#3

Mis à jour par Olivier Renard il y a presque 2 ans

Pour relance ce jour

#4

Mis à jour par Alexis Mathias il y a plus d'un an

Le ticket s'entend pour les calendrier de type rendez vous et event.

Pour les event qui présente une tension. Cas d'usage : place en crèche et activités périscolaires.
L'ouverture des créneaux de place en place en crèche, activité périscolaire etc peuvent être tendus.
Les services peuvent décider d'ouvrir les créneaux à partir d'une heure précise (le matin à 8h00 et non pas à minuit (valeur par défaut) parce qu'ils souhaitent maîtriser l'heure de mise à disposition des créneaux.

#5

Mis à jour par Chloé Girard il y a plus d'un an

#6

Mis à jour par Olivier Renard il y a environ un an

+1 pour relance. (ou communiquer un chiffrage pour le faire financer)

#10

Mis à jour par Benjamin Dauvergne il y a environ un an

  • Lié à Development #71918: Les soucis de date autour des changements heure d'été/hiver viennent de pytz/django ajouté
#11

Mis à jour par Benjamin Dauvergne il y a environ un an

  • Assigné à mis à Benjamin Dauvergne
#12

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Nouveau à En cours

Benjamin Dauvergne (bdauvergne) a ouvert une pull request sur Gitea concernant cette demande :

#13

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de En cours à Solution proposée
#14

Mis à jour par Benjamin Dauvergne il y a environ un an

Voilà, le code est tout de suite plus simple avec des objets datetime qui fonctionnent correctement.

Quelques commentaires :
  • ajout d'un champ Agenda.min_booking_time par défaut à 00:00:00 pour garder le comportement actuel sur les agendas existants,
  • adaptation aux formulaires, serializers et autres templates pour tenir compte de ce nouveau champ, je n'ai pas cherché à valider qu'il n'était pas utilisé si min/max_booking_delay sont vides, à voir,
  • j'ai appliqué le même comportement à min et max_booking_time ça pourrait être discutable, j'ai trouvé que ça donnait une durée fixe entre les deux (modulo les changements d'heure),
  • les tests de l'API agenda en création était buggés car utilisant .post() au lieu de .post() (payload application/x-www-form-urlencoded au lieu de JSON), ça ne se voyait pas car on envoyait que des chaînes mais là avec min_booking_time qui peut être à None ça ne passait plus, j'ai corrigé,
  • les tests sur min/max_booking_datetime sont plus complets qu'avant, ça teste aussi quand la date on est en plein milieu du changement d'heure.
#15

Mis à jour par Emmanuel Cazenave il y a environ un an

Benjamin Dauvergne a écrit :

indiquer que les délais doivent être calculés à l'heure près start_datetime - timedelta(hours=24 * delay) pour éviter cette situation (je pense aux piscines mais ça pourrait être des RdV vaccinations). Ça aurait le mérite de, quasi naturellement, lisser la charge sur la journée.

Je serais pour que le comportement par défaut (y compris sur les agendas existants) soit cela. Parce que j'imagine que ça conviendra dans la très grande majorité des cas, ce lissage.

Si je ne me trompe pas, ce comportement est laissé de coté par tes patchs, c'est minuit ou une autre heure précise mais pas de lissage possible.

#17

Mis à jour par Benjamin Dauvergne il y a environ un an

Emmanuel Cazenave a écrit :

Si je ne me trompe pas, ce comportement est laissé de coté par tes patchs, c'est minuit ou une autre heure précise mais pas de lissage possible.

Non non je gère le "lissage", il suffit de laisser le champ vide. Peut-être que les tests ne le montrent pas, je vais refaire un tour sur les tests.

Emmanuel Cazenave a écrit :

Je serais pour que le comportement par défaut (y compris sur les agendas existants) soit cela. Parce que j'imagine que ça conviendra dans la très grande majorité des cas, ce lissage.

Je veux bien un deuxième avis parce que c'est un changement important du comportement par défaut, et les gens jouent avec les agendas tous les jours.

#18

Mis à jour par Benjamin Dauvergne il y a environ un an

Je confirme, c'est visible dans le test test_agenda_minimal_booking_delay_no_minimal_booking_time, à mesure que l'heure courante avance, la date minimale de réservation aussi.

#19

Mis à jour par Olivier Renard il y a environ un an

Je pense que ce comportement par défaut conviendrait. Je ne connais pas de cas d'usage qui ne conviendrait pas.

#20

Mis à jour par Emmanuel Cazenave il y a environ un an

Benjamin Dauvergne a écrit :

Non non je gère le "lissage", il suffit de laisser le champ vide

Ok, my bad.

Coté interface, pour activer ça, il faut vider le champ et là il y a l'indication "If left empty, current time will be used.". Perso j'ai tout de suite pensé que ça allait insérer dans ce champ les heures/secondes du moment où je clique, confusion.

Mais là comme ça je trouve pas de proposition évidente, un truc qui évoqué le fait que ça va glisser/lisser ?

Benjamin Dauvergne a écrit :

Je veux bien un deuxième avis parce que c'est un changement important du comportement par défaut, et les gens jouent avec les agendas tous les jours.

Sinon, garder ça pour l'existant et glissant pour les agendas nouvellement créés ?

#21

Mis à jour par Emmanuel Cazenave il y a environ un an

Emmanuel Cazenave a écrit :

Sinon, garder ça pour l'existant

Garder le comportement actuel pour l'existant je veux dire.

#22

Mis à jour par Benjamin Dauvergne il y a environ un an

Emmanuel Cazenave a écrit :

Mais là comme ça je trouve pas de proposition évidente, un truc qui évoqué le fait que ça va glisser/lisser ?

Je n'ai rien trouvé de simple alors j'ai fait une phrase :

Ex.: 08:00:00. Si ce champ est laissé vide alors les évènements ou rendez-vous disponibles à la réservation sont ceux dont le début est plus tard que l'heure courante, en prenant en compte les délais minimaux et maximaux de réservation en jours

Benjamin Dauvergne a écrit :
Sinon, garder ça pour l'existant et glissant pour les agendas nouvellement créés ?

Même pour ça je suis inquiet, si on fait ça il faudra mettre en <blink> la description du nouveau comportement dans les prochaines notes de mise à jour. Je vais le mettre à l'ordre du jour pour lundi.

#23

Mis à jour par Benjamin Dauvergne il y a environ un an

J'ai vérifier l'effet sur publication_datetime il n'y en a pas, ça se serait vu dans les tests, par ailleurs publication_datetime ne peut que réduire la période de réservation pas l'augmenter (les deux seuils se combinant dans get_open_events()).

#26

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Solution proposée à Solution validée

Emmanuel Cazenave (ecazenave) a approuvé une pull request sur Gitea concernant cette demande :

#27

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Solution validée à Résolu (à déployer)

Benjamin Dauvergne (bdauvergne) a mergé une pull request sur Gitea concernant cette demande :

#29

Mis à jour par Valentin Deniaud il y a environ un an

  • Lié à Development #75884: manager, utiliser widgets.TimeWidget pour l'heure de réservation minimale ajouté
#30

Mis à jour par Transition automatique il y a 12 mois

  • Statut changé de Résolu (à déployer) à Solution déployée
#31

Mis à jour par Transition automatique il y a 10 mois

Automatic expiration

Formats disponibles : Atom PDF