Lier les événements à la présence

Il y a une séparation nette dans GCM entre ce qui est au calendrier et qui s'est présenté. Le calendrier contient des événements — des dates avec des titres, des heures, des lieux. Les listes de présence référencent des réunions — des modèles récurrents qui décrivent un type de rassemblement. Le lien entre eux est intentionnel, indirect, et mérite d'être compris avant de commencer à configurer l'un ou l'autre.

La présence ne pointe jamais vers un événement

Regardez la table attendances et vous ne trouverez pas de colonne event_id :

attendances(
  id, member_id, meeting_id, attendance_date,
  organization_id, org_unit_id,
  ministry_id, school_id,
  created_at, updated_at, deleted_at
)

La ligne de la liste pointe vers une réunion et une date de présence. C'est tout. Le fait qu'un événement de calendrier existe aussi à cette date est sans rapport pour la base de données — la présence vit dans son propre monde, jointe par date et type de réunion, pas par une clé étrangère vers events.

C'est un choix de conception délibéré. Si la présence pointait vers les événements, chaque service récurrent créerait des milliers de lignes d'événements « d'occurrence » dans la base de données pour donner à la présence quelque chose vers quoi pointer. Au lieu de cela, les événements récurrents restent une seule ligne avec une RRULE, et les réunions sont réutilisées sur des centaines de dates. Le coût : un événement de Service du dimanche sur le calendrier et une réunion de Service du dimanche dans les paramètres de présence n'ont aucun lien automatique. Ils partagent un nom et une ambiance ; le système ne sait pas qu'ils sont connectés.

Deux scénarios pour la présence

En pratique, la présence est enregistrée de deux façons, et les deux passent par les réunions :

Services récurrents — utiliser uniquement des réunions

Pour votre Service du dimanche, prière du mercredi, cellule hebdomadaire — tout ce qui se passe à un rythme régulier — vous n'avez pas besoin d'événement de calendrier du tout. Configurez une réunion, puis enregistrez la présence contre elle depuis le flux de présence unique, l'écran de présence en masse, ou la station de check-in. Chaque ligne de présence reçoit meeting_id = <Service du dimanche> et attendance_date = <ce dimanche>.

Le calendrier n'a pas besoin de faire apparaître ces dates, parce que le rassemblement est implicite dans la réunion. Les membres et opérateurs savent que le Service du dimanche est à 10h le dimanche — ils n'ont pas besoin d'un point sur le calendrier pour cela.

Dates spéciales — événement de calendrier + réunion ad hoc facultative

Pour les événements uniques contre lesquels vous voulez aussi suivre la présence — une retraite de leaders, une soirée avec un orateur invité, une campagne d'évangélisation — créez l'événement de calendrier pour la visibilité, puis soit :

• Réutilisez une réunion existante. Si la retraite compte comme une réunion de leadership, enregistrez la présence contre votre réunion Leadership existante à la date de la retraite. La liste atterrit proprement.
• Créez une réunion temporaire. Si l'événement ne correspond à aucun type de réunion existant, ajoutez une réunion comme Événements spéciaux, donnez-lui une portée appropriée et enregistrez la présence contre elle. Étiquetez la date dans vos notes si le nom de la réunion est trop générique pour l'identifier plus tard.

Dans les deux cas, l'événement de calendrier alimente les rappels et la planification visuelle ; la réunion alimente la liste.

Pourquoi pas la présence directement contre l'événement ?

La réponse pragmatique : les événements et les réunions ont des cycles de vie différents. Un événement est un plan de date — il peut être annulé, reprogrammé via une exception, ou déplacé entièrement. Une liste est un enregistrement historique — une fois les personnes pointées, la ligne ne devrait pas bouger juste parce que les données de planification ont changé.

Si la présence pointait vers les événements :

• Supprimer un événement de calendrier orphelinerait les listes ou les supprimerait en cascade.
• Modifier la date de l'événement re-daterait chaque liste, ce qui est faux pour un journal d'audit.
• Les événements récurrents devraient matérialiser chaque occurrence en une vraie ligne avant que la présence puisse la référencer.

Pointer vers les réunions évite tout cela. Les réunions changent rarement (et quand elles le font, les changements de portée sont délibérés). Les événements changent souvent, et cette volatilité est contenue à la surface du calendrier où elle appartient.

Règles de déduplication

Quelques règles maintiennent les listes propres face aux ré-importations, doubles check-ins et doubles sauvegardes accidentelles :

1. Une ligne par (member_id, meeting_id, attendance_date) par org. Un index unique l'impose. Sauvegarder la même présence deux fois — même membre, même réunion, même date — fait silencieusement un no-op sur la seconde sauvegarde.
2. Suppression douce uniquement. Supprimer une ligne de liste définit deleted_at plutôt que de la retirer. L'index unique traite les lignes supprimées en douceur comme non conflictuelles, donc une ligne supprimée-puis-réajoutée fonctionne comme prévu.
3. Les lignes is_sample = true sont exclues des rapports. Les présences de démo amorcées portent le drapeau pour qu'elles ne polluent pas les vrais chiffres quand vous passez en production.
4. Les colonnes org et org-unit sont marquées au moment de l'insertion. Elles ne se recalculent pas si vous déplacez le membre vers une autre branche plus tard — l'enregistrement historique reste précis au moment du check-in.

La station de check-in et la présence en masse comptent toutes deux sur ces règles pour être idempotentes : appuyez sur envoyer deux fois, scannez le même QR code deux fois, re-téléchargez le même CSV — le nombre de lignes reste correct.

Et la présence des ministères et des écoles ?

La table attendances porte des colonnes facultatives ministry_id et school_id pour les listes qui appartiennent à une réunion spécifique de ministère ou à une session d'école. Celles-ci sont définies quand le linked_entity_type de la réunion est ministry ou school, et elles permettent au module de rapports de diviser les totaux par ministère ou par école.

Pour une répétition de l'équipe de louange qui compte à la fois comme une réunion de ministère et comme une réunion régulière, choisissez-en une. Ne double-enregistrez pas sur deux lignes de réunion — vous gonflerez les totaux. Le modèle le plus propre est une seule réunion liée au ministère, et des rapports qui agrègent par ministry_id.

Quand calendrier et présence divergent

Si le calendrier montre un événement et qu'aucune présence n'est jamais enregistrée, c'est bien — la plupart des événements sont informatifs. Si la présence existe pour une date sans événement de calendrier correspondant, c'est aussi bien — les réunions récurrentes n'ont pas besoin de points sur le calendrier.

Le cas à surveiller est que les deux existent et décrivent des choses légèrement différentes. Un événement de calendrier intitulé « Service du dimanche @ 10h » et une réunion intitulée « Service du matin » se réfèrent au même rassemblement, mais les rapports et les rappels les traitent comme indépendants. Choisissez une convention de nommage cohérente et tenez-vous-y sur les deux surfaces — votre futur vous-même faisant un audit de présence vous remerciera.