Exceptions d'événement

Les événements récurrents se répètent selon une règle. La vraie vie, non. Noël tombe un dimanche et fait glisser le service du matin habituel vers le soir ; un jour férié ferme le bâtiment et vous annulez la réunion de prière d'un mercredi ; un prédicateur invité signifie un changement de titre pour une semaine. Les exceptions sont la façon dont GCM gère ces modifications sans réécrire la RRULE sous-jacente.

Deux mécanismes, un seul but

GCM offre deux façons de faire en sorte qu'une date donnée se comporte différemment du reste d'une série :

1. events.exception_dates — une colonne date[] sur l'événement lui-même. Ajoutez une date ici et cette occurrence disparaît du calendrier. Aucune jointure de table, aucune ligne supplémentaire.
2. Table event_exceptions — une ligne par remplacement, avec des champs pour annuler, renommer, replanifier ou déplacer une occurrence.

La première est pour le cas simple (« ignorer cette date »). La seconde est pour tout le reste.

event_exceptions(
  id, event_id, exception_date,
  is_cancelled, override_title,
  override_start_time, override_end_time,
  override_location, created_at
)

L'exception_date est la date à laquelle l'événement parent serait tombé, avant que le remplacement ne prenne effet. Tous les autres champs sont facultatifs — tout ce que vous laissez null retombe sur la valeur de l'événement parent.

Annuler une occurrence

Le cas le plus courant : un service du dimanche régulier est suspendu parce que le bâtiment est en train d'être repeint, ou une réunion de prière hebdomadaire est ignorée pour un jour férié.

Deux façons équivalentes de le faire :

• Voie rapide — ajoutez la date à events.exception_dates. L'occurrence disparaît du calendrier.
• Voie traçable — insérez une ligne event_exceptions avec is_cancelled = true. L'occurrence disparaît aussi, mais vous avez maintenant une trace du pourquoi elle a été annulée (visible aux administrateurs quand ils ouvrent la date).

Pour les sauts occasionnels, la voie rapide suffit. Pour les annulations que vous pourriez avoir à expliquer plus tard (litiges de remboursement, disputes de présence), la voie traçable laisse une trace.

Déplacer une occurrence

Quand l'occurrence a quand même lieu mais à une autre heure ou à un autre endroit, utilisez la ligne event_exceptions pour remplacer juste les champs qui changent. Le reste se cascade depuis l'événement parent :

INSERT INTO event_exceptions (event_id, exception_date, is_cancelled,
                              override_start_time, override_location)
VALUES ('<id>', '2026-12-24', false,
        '19:00', 'Sanctuary — candlelight setup');

Le 24 décembre, le calendrier affiche toujours l'événement, mais l'étiquette d'heure indique 19h00 et le lieu indique « Sanctuary — candlelight setup ». La série continue à se répéter sur son rythme habituel du dimanche matin par la suite.

Champs de remplacement disponibles :

• override_title — remplace le titre pour cette seule date. « Service du dimanche » devient « Service de la veille de Noël ».
• override_start_time / override_end_time — décale les heures. Utilisez les deux si la durée change aussi.
• override_location — orientez les participants ailleurs pour la journée.

Si vous avez besoin de remplacer des champs que la table d'exception ne porte pas — couleur, description, branche — le remplacement n'est pas assez expressif. Vous devrez bifurquer : supprimez l'occurrence avec une exception, puis créez un événement ponctuel séparé pour la date modifiée.

Exceptions vs mises à jour de RRULE

Une question fréquente : dois-je modifier la règle de récurrence ou ajouter une exception ? La règle générale :

• Une ou deux dates changent → ajoutez des exceptions. La règle continue de décrire le motif normal, et les exceptions décrivent les écarts.
• Le motif lui-même change à l'avenir → modifiez la RRULE. Nouvelle date de fin, nouveau jour de la semaine, nouveau mode mensuel. La règle doit toujours décrire ce qui est normal, pas ce qui était normal.
• Passer d'hebdomadaire à bimensuel en milieu d'année → terminez la règle actuelle avec UNTIL=<switchover>, puis créez un nouvel événement avec la nouvelle règle commençant après cette date. N'essayez pas d'encoder la transition à l'intérieur d'une seule RRULE — les changements d'INTERVAL au milieu d'une série ne sont pas représentables.

Le mauvais mouvement est de supprimer l'événement récurrent quand quelque chose change, parce que la suppression retire en douceur chaque occurrence, y compris les anciennes liées à la présence et aux rapports. Le bon mouvement est presque toujours : ajoutez une exception, ou terminez la série actuelle et démarrez-en une nouvelle.

Comment les exceptions s'affichent

Dans les vues mois et à venir, la logique d'exception s'exécute côté client dans le cadre de l'expansion de la RRULE :

1. Le navigateur demande à l'événement parent « sur quelles dates tomberais-tu dans cette fenêtre ? »
2. Il filtre toute date dans events.exception_dates.
3. Il filtre toute date où event_exceptions.is_cancelled = true.
4. Pour les dates qui survivent, il superpose les champs de remplacement de toute ligne event_exceptions non annulée par-dessus les valeurs par défaut de l'événement parent.

Cela signifie qu'une exception avec is_cancelled = false plus override_title = 'Christmas Eve Service' apparaît sur la grille avec le nouveau titre mais l'heure, le lieu et la couleur du parent — sauf si ceux-ci sont aussi remplacés.

Quand penser autrement

Si vous vous retrouvez à ajouter beaucoup d'exceptions à un événement, le motif est faux. Un service du dimanche qui se voit renommer six fois par an pour des services spéciaux est le signe que vous devriez garder « Service du dimanche » ennuyeux et ajouter des événements ponctuels séparés pour les dates spéciales — veille de Noël, Pâques, etc. Les exceptions sont mieux comme la correction rare, pas le mode normal.

Pour les règles qui régissent le motif normal, voir Motifs récurrents. Pour les dates ponctuelles qui ne sont pas liées à une série récurrente du tout, créez simplement un nouvel événement.