Installation

Installer @fraza-pro/module-booking, créer les tables, poser l'horaire d'ouverture et prendre un premier rendez-vous.

Cette page couvre l'installation de @fraza-pro/module-booking dans un projet déjà structuré par @fraza/start. Le module n'est jamais déclaré à la main : il est découvert au boot par scan des dépendances, comme décrit dans Cycle de vie d'un module.

Ce module est distribué sous la licence Fraza Pro : son utilisation en production demande une licence par projet, renouvelée chaque année, qui comprend les mises à jour, la conformité et le support. Voir Licence et propriété.

Prérequis

  • Un projet généré par npx @fraza/start, avec @fraza/core installé.
  • NEXT_PUBLIC_URL renseignée, sinon toute réservation en ligne est rejetée par la vérification d'origine du core.
  • La configuration courriel du core, Resend ou SMTP, pour les confirmations et les rappels.
  • La ligne @fraza-pro:registry=https://registry.fraza.ca/ et le token du registre dans le .npmrc du projet, sans lesquels npm i échoue. npx @fraza/start écrit déjà la ligne de portée. Le token s'obtient avec npm login --registry=https://registry.fraza.ca/, puis npx fraza-key le reprend dans le projet. Voir fraza-key.

Installer

npm i @fraza-pro/module-booking

Ajouter la variable d'activation au .env :

#------ MODULE - BOOKING ------#
FRAZA_MODULE_BOOKING=true

Sans ce drapeau, le module est ignoré : aucune table, aucune route, aucune entrée d'admin.

Régénérer les manifestes puis créer les tables :

npx fraza-modules sync    # déclenché automatiquement au postinstall
npx fraza-db init         # crée les onze tables fraza_booking_*

Sur une base existante, npx fraza-db migrate suffit.

Version de core exigée

Le module réclame @fraza/core 0.1.14 ou plus, la première version qui reconnaît la portée @fraza-pro. npm refuse de l'installer à côté d'un core plus ancien (peerDependencies). Un core plus ancien ne dériverait pas FRAZA_MODULE_BOOKING du nom du paquet : le module y resterait désactivé, sans erreur. Le plancher couvre aussi trois briques :

  • le composant Calendar, sans lequel la vue calendrier ne se rend pas ;
  • registerAdminIcons, qui enregistre les icônes de la section et de ses items, et sans lequel le point d'entrée client du module échoue au chargement ;
  • les fonctions de fuseau horaire de shared/dates, sans lesquelles les créneaux glissent d'une heure deux fois par an.

Aucune de ces absences ne lève d'erreur claire à l'usage, d'où le plancher explicite.

Premier réglage, dans l'ordre

Les trois premières étapes se font dans la page Options, un onglet chacune. L'ordre compte : un type de rendez-vous sans intervenant n'est pas réservable, et un intervenant sans horaire n'offre aucun créneau.

  1. Un intervenant. /admin/booking/options/intervenants. Le courriel est facultatif mais c'est lui qui reçoit les avis.
  2. L'horaire d'ouverture. /admin/booking/options/horaires. Sept jours, autant de plages que nécessaire par jour. Une pause du midi est le trou entre deux plages, pas un réglage.
  3. Un type de rendez-vous. /admin/booking/options/types. Durée, lieu, et au moins un intervenant autorisé.
  4. Un rendez-vous. /admin/booking/agenda, bouton « Nouveau rendez-vous ». Les créneaux proposés sont exactement ceux qu'un visiteur verrait.

Ouvrir la prise de rendez-vous en ligne

Elle est fermée par défaut. Deux gestes :

FRAZA_MODULE_BOOKING_ONLINE=true

puis un lien de réservation dans /admin/booking/options/liens. La page de ce lien affiche son adresse publique et le code d'intégration en iframe.

Tant que la variable est à false, un lien parfaitement configuré répond 404, et rien sur le lien lui-même ne le dirait : l'admin affiche un bandeau d'avertissement sur la liste des liens pour cette raison.

Vérifier

npx fraza-doctor

Le doctor connaît toutes les variables du module par son manifeste : une variable FRAZA_MODULE_BOOKING_* inconnue du .env est dénoncée, et le plancher de version est vérifié.

Sur cette page