Courriels
Confirmation, rappel, annulation, avis internes, fichier .ics et registre d'idempotence.
Le module envoie quatre messages, par @lrvo/core/email. Il n'ajoute aucune dépendance : le fournisseur, l'expéditeur et le gabarit de base appartiennent au core.
Les messages
| Message | Destinataire | Déclencheur |
|---|---|---|
| Confirmation | Le client | Rendez-vous créé et confirmé. |
| Demande reçue | Le client | Rendez-vous créé en attente d'approbation. |
| Confirmé | Le client | Approbation d'une demande. |
| Déplacé | Le client | Déplacement, par lui ou par l'administration. |
| Rappel | Le client | Tâche planifiée, si la case a été cochée. |
| Annulé | Le client | Annulation, par lui ou par l'administration. |
| Avis | L'administration | Création, annulation, déplacement. |
| Avis | L'intervenant | Les mêmes, s'il a un courriel. |
L'avis interne porte ce que le message au client laisse volontairement de côté : le téléphone, l'adresse courriel et la note interne.
Le fichier .ics
Joint aux messages du client quand LRVO_MODULE_BOOKING_ICS est à true.
Son identifiant est dérivé du jeton du rendez-vous et ne change jamais. C'est ce qui fait qu'un déplacement met à jour l'événement déjà présent dans l'agenda du client au lieu d'en créer un second, et qu'une annulation le retire.
Les heures y sont écrites en UTC : aucun bloc de fuseau à maintenir dans le module, et aucune règle d'heure avancée à tenir à jour.
Rappels
LRVO_MODULE_BOOKING_REMINDER_HOURS accepte plusieurs valeurs : 48,24,2 envoie trois rappels. Vide, aucun.
La tâche booking-reminders tourne toutes les heures et cherche les rendez-vous confirmés dont le client a coché la case et dont le début tombe dans la fenêtre visée. Le calcul est de l'arithmétique d'instants : « 24 h avant » est une durée, pas une heure de la journée, et le calculer en heure locale décalerait le rappel d'une heure deux fois par an.
Un rendez-vous déplacé perd ses lignes de rappel : sans cela, le registre considérerait le rappel comme déjà envoyé et la nouvelle date n'en recevrait aucun.
Le registre
Chaque envoi réserve sa place dans lrvo_booking_notification avant de partir.
- Un envoi réussi ne se répète jamais.
- Un échec marque la ligne en erreur, ce qui libère la place pour un nouvel essai.
- Une panne entre la réservation et l'envoi coûte un rappel manquant, jamais un doublon. Manquer une fois est la meilleure des deux erreurs.
Aucune fonction d'envoi ne lève. Un courriel qui ne part pas ne fait jamais échouer le rendez-vous qui l'a provoqué : le rendez-vous existe, et le registre réessaiera.
Adresse de réponse
LRVO_MODULE_BOOKING_CONTACT_EMAIL, à défaut LRVO_MODULE_BOOKING_ADMIN_EMAIL, devient l'adresse de réponse de tous les messages du client. Répondre à une confirmation atteint ainsi les gens qui tiennent l'agenda, et non l'adresse d'envoi du site.
Le nom de l'expéditeur, lui, reste celui du site. Un module possède le contenu de ses messages, jamais l'identité du site qui les envoie : un client qui reçoit une confirmation signée autrement que la réinitialisation de mot de passe de la veille a de bonnes raisons de douter de l'une des deux.