Event et Day

Synthèse Générale

  C'est un framework très complet qui gère :
   * Un cycle de vie complet pour un événement (préparation, inscriptions, en cours, terminé).
   * Plusieurs modes d'inscription (ouvert, sur validation, manuel).
   * Des notifications par email pour les participants et les organisateurs.
   * L'intégration avec les agendas externes via la génération de fichiers .ics (iCalendar).

1. @overlays/event.php - Le Framework d'Événements

  C'est la pièce maîtresse, une classe de base extrêmement complète pour tout ce qui est événementiel. On peut le voir comme un mini-framework.

* Rôle : Définir la structure, le comportement et le cycle de vie d'un événement complexe.
* Cycle de vie (State Machine) : L'overlay gère un état (status) qui évolue dans le temps :
       1. created (par défaut) : L'événement est en préparation.
       2. open : Les inscriptions sont ouvertes.
       3. lobby : L'événement est sur le point de commencer (salle d'attente virtuelle).
       4. started : L'événement est en cours.
       5. stopped : L'événement est terminé.
      Les transitions entre ces états peuvent être automatiques (basées sur l'heure) ou manuelles (déclenchées par le propriétaire).

* Fonctionnalités Clés :
       * Gestion des inscriptions (`with_enrolment`) : Propose 3 modes :
           * none : Inscription ouverte à tous.
           * validate : Les utilisateurs postulent et le propriétaire doit valider.
           * manual : Le propriétaire inscrit les participants manuellement.
       * Interface d'édition (`get_tabs`) : Ajoute un onglet "Management" très complet lors de l'édition de la page, permettant de configurer tous les messages du cycle
         de vie (message d'accueil, de bienvenue, de suivi, etc.) et le mode d'inscription.
       * Affichage dynamique (`get_view_text`) : C'est une grosse méthode qui agit comme une machine à états. En fonction du status actuel de l'événement, elle affiche
         les informations, les messages et les boutons d'action appropriés ("S'inscrire", "Rejoindre", "Gérer les inscriptions", etc.).
       * Intégration Calendrier (`get_ics`, `get_invite_attachments`) : Génère un fichier .ics standard que les utilisateurs peuvent importer dans leur agenda (Google,
         Outlook, etc.). Ce fichier est automatiquement attaché aux emails d'invitation ou de confirmation.
       * Notifications (`remember`, `invite`) : S'intègre profondément au système de YACS pour envoyer des emails lors de la création, la mise à jour, l'annulation, ou
         l'inscription à un événement.
       * URLs d'action (`get_url`) : Centralise la création des URLs pour toutes les actions possibles (apply, enroll, join, start, stop...), pointant vers les scripts
         du dossier events/.

event.php est un moteur très puissant conçu pour être la base de tout type d'événement en ligne ou physique.

2. @overlays/day.php - L'Événement Simplifié (Journée)

  Cette classe hérite de Event (class Day extends Event). Son but est de simplifier radicalement l'interface pour des cas d'usage plus simples.

* Rôle : Gérer des événements qui durent toute une journée et ne nécessitent pas de gestion complexe (ex: jour férié, anniversaire, date limite d'un projet).

* Simplifications (ce qu'il change par rapport à `Event`) :
       * Formulaire simplifié (`get_fields`) : Il ne demande que la date (date_stamp). L'heure est forcée à "12:00" et la durée à "1440" minutes (24h) via des champs
         cachés.
       * Pas d'inscription (`with_enrolment`) : Il désactive complètement le système d'inscription en retournant false.
       * Pas de gestion (`get_tabs`) : Il supprime l'onglet "Management", cachant ainsi toute la complexité des messages de cycle de vie.
       * Pas d'action "Rejoindre" (`get_join_url`) : Il retourne NULL, car on ne "rejoint" pas un "jour".

  C'est un excellent exemple d'utilisation de l'héritage pour spécialiser et simplifier une classe complexe pour un besoin spécifique, offrant une bien meilleure expérience utilisateur.

  3. @overlays/events/** - Les Contrôleurs d'Action

  Ce dossier contient une série de petits scripts PHP qui ont chacun une seule et unique responsabilité : exécuter une action sur un événement. Ils sont les "points  d'entrée" pour toutes les interactions de l'utilisateur avec le cycle de vie de l'événement.
 * Pattern commun à tous les scripts :
       1. Récupérer l'ID de l'objet (l'ancre).
       2. Charger l'objet Anchors::get($id).
       3. Charger son overlay Overlay::load(...).
       4. Vérifier les permissions (est-ce le propriétaire ? l'utilisateur a-t-il le droit de voir la page ?).
       5. Appeler la méthode correspondante sur l'objet $overlay (ex: $overlay->start_meeting()).
       6. Rediriger l'utilisateur vers la page de l'événement.
 * Rôle de chaque script :
       * apply.php : Gère la demande d'inscription d'un utilisateur.
       * enroll.php : Fournit au propriétaire l'interface pour valider ou refuser les inscriptions.
       * fetch_ics.php : Script spécial qui ne fait que générer et servir le fichier .ics pour le téléchargement.
       * join.php : Redirige l'utilisateur vers l'URL de la réunion en ligne (ex: lien Zoom/Teams/BBB).
       * open.php, start.php, stop.php : Permettent au propriétaire de forcer manuellement les transitions d'état de l'événement.

  Conclusion et Vision d'Ensemble

  Le système fonctionne comme suit :
   1. Un administrateur crée une page avec un overlay event ou day.
   2. La page d'événement (get_view_text) affiche des boutons ("S'inscrire", "Démarrer l'événement"...) dont les liens pointent vers les scripts du dossier events/.
   3. Quand un utilisateur clique, le script correspondant est exécuté.
   4. Le script charge l'overlay et lui délègue l'exécution de la logique métier (inscrire l'utilisateur, changer le statut, envoyer un email...).
   5. L'utilisateur est redirigé vers la page de l'événement, qui affiche maintenant le nouvel état.
   6. En arrière-plan, le système gère les notifications, les emails, et la synchronisation avec les calendriers externes.

  C'est une architecture très robuste, modulaire et extensible qui sépare bien les responsabilités :
   - `event.php` : La logique métier et l'état (le "Modèle").
   - `get_view_text()` dans `event.php` : La logique d'affichage (la "Vue").
   - Le dossier `events/` : La gestion des actions utilisateur (les "Contrôleurs").