Produits Entr'ouvert » Chrono

Le préblocage a lieu via le passage d'un paramètre "lock_code" contenant un chaîne quelconque non vide, les espaces en fin et début sont retirés pour éviter les bugs idiots de template.

Ce paramètre est disponible sur les vues datetimes et fillslot pour les rendez-vous et les évènements.

Lors d'une réservation (fillslot) avec lock_code est créé un modèle Lease plus des modèles Event/Booking habituels. Le Lease est en relation 1-1 avec le Booking créé. Le Lease dispose d'une date d'expiration (contrôlé via le setting CHRONO_LOCK_DEFAULT_DURATION mais par ailleurs contrôlable via un autre paramètre lock_duration durant le fill_slot) et d'un champ lock_code qui reprendre la valeur passée.

lock_duration est par ailleurs limité par les settings CHRONO_LOCK_MIN_DURATION/CHRONO_LOCK_MAX_DURATION.

chrono/settings.py:CHRONO_LOCK_MIN_DURATION = 5 * 60
chrono/settings.py:CHRONO_LOCK_DEFAULT_DURATION = 10 * 60
chrono/settings.py:CHRONO_LOCK_MAX_DURATION = 20 * 60

Régulièrement et sur différentes vues (datetimes et fillslot) sont appelés les fonctions clean_meeting_events_with_expired_lease()/clean_bookings_with_expired_lease qui suppriment les Booking (et Event dans le cas des rendez-vous) dont l'objet Lease a expiré, ça évite d'avoir une tâche de fond pour faire cela, c'est fait au fil de l'eau et notamment lors des appels fillslot/datetimes, on a donc une vue toujours à jour des créneaux/évènements disponibles.

Dans w.c.s:
L'appel avec lock_code doit être en sortie de page où le choix du rendez-vous est fait en utilisant les condition de sortie de page. Cet appel doit être en définissant un appel de web-service. Ex.:

Définition du web-service :
  Slug: rdv_fillslot_preblocage
  Méthode: POST
  URL: {{ form_var_rendez_vous_fillslot_url }}
  Paramètre POST: 
    lock_code={{ session_hash_id }}

Condition de sortie de page:
  webservice.rdv_fill_slot_preblocage.err == 0

Si cet appel fillslot a réussi alors le rendez-vous/inscription est pré-bloqué, et on peut passer à la page suivante.cet appel peut-être sur toutes les sorties des pages suivantes il est idempotent (si le lease existe avec le même lock_code il, le rendez-vous/l'inscription est supprimée et recréé à chaque fois, voir dans les blocs transaction.atomic() où se passent la réservation effective). À chaque appel fillslot, l'expiration du lease est prolongée, si l'appel est bien fait en sortie de la page finale ça évite que le fillslot définitif dans le workflow n'échoue.

Pour valider définitivement le rendez-vous/l'inscription, on ajoute à l'appel fillslot (celui qui est typiquement fait en début de workflow après réception de la demande) le lock_code et un autre paramètre "confirm_after_lock" à la valeur true; la présence de ce paramètre permettra le fillslot comme avant mais ne recréera pas le Lease, on se retrouve avec un rendez-vous/une inscription classique.

Appel webservice de réservation définitive:

  Méthode: POST
  URL: {{ form_var_rendez_vous_fillslot_url }}
  Paramètre POST: 
    lock_code={{ session_hash_id }}
    confirm_after_lock=true

Autre commentaire:
Des bidouilles sont faites pour les endpoints datetimes:

• pour les évènements au niveau d'accesseur de Event et de api/views:get_events_from_slots pour avoir une vue des places disponibles des évènements excluant ou pas les inscriptions pré-bloquées
• pour les rendez-vous dans Agenda.get_all_slots() (exclusion de certains évènements en fonction de la présence du paramètre lock_code, sur les agendas concernés, sur les ressources et sur les évènements agrégés en fonction du user_external_id)

Coté w.c.s on peut utiliser les sources de données datetimes automatiques mais elle ne passent pas de paramètre lock_code et donc l'expérience n'est pas optimale, par exemple si on revient sur la page de sélection du créneau le slot en cours de préblocage ne sera pas disponible. Pour pallier à cela il faut créer une source de donnée manuelle qui passera le paramètre lock_code={{ session_hash_id }}.