Utilisateurs et Rôles

Chaque action dans GCM est régie par une permission. Enregistrer un don, supprimer un membre, envoyer une diffusion WhatsApp, exporter un rapport — chacune vérifie les rôles de l'utilisateur connecté par rapport au catalogue de permissions avant que la base de données, la edge function ou l'interface ne l'autorise. Ce module est l'endroit où vous décidez qui détient quelle clé.

Utilisateurs vs membres

GCM maintient ces deux concepts strictement séparés :

• Un utilisateur est une personne qui peut se connecter à GCM. Il a un e-mail, un mot de passe et un ou plusieurs rôles.
• Un membre est une personne de votre congrégation. Il a un profil, un historique de présence, des dons — mais la plupart d'entre eux ne se connecteront jamais.

Les deux se chevauchent (un pasteur est les deux), mais les modules ne partagent pas d'identifiants. Inviter quelqu'un en tant qu'utilisateur ne l'ajoute pas à votre liste de membres ; enregistrer un membre ne lui crée pas de compte de connexion. C'est intentionnel : vous pouvez inviter un auditeur externe sans polluer le décompte de votre congrégation, et vous pouvez suivre un enfant en tant que membre sans jamais lui délivrer d'identifiants.

Rôles vs permissions

Le modèle comporte trois couches :

1. Permissions — petits verbes fixes comme members.create, giving.record, reports.approve. Il y en a 68, fournis par la plateforme. Vous ne pouvez ni les ajouter ni les renommer.
2. Rôles — paquets de permissions. Admin, Shepherd, Leader, Member sont fournis comme rôles système ; vous pouvez en créer des personnalisés (Trésorier, Responsable de louange, Accueillant des visiteurs) et basculer les permissions accordées par chacun.
3. Attributions — qui détient quel rôle, éventuellement limité à une partie de votre structure organisationnelle.

Quand quelqu'un tente une action, la plateforme demande : l'un de ses rôles inclut-il cette permission, et son périmètre d'attribution inclut-il cette ligne ? Les deux doivent passer.

Deux saveurs d'admin

Il existe trois concepts d'administrateur, faciles à confondre :

Type d'admin	Portée	À qui c'est destiné
Org admin	Votre église uniquement	Pasteur principal, administrateur exécutif — gère votre espace de travail
Platform admin	Toutes les églises de la plateforme	L'équipe GCM — traite les escalades de support
Superadmin	Toutes les églises + peut gérer les autres platform admins	Les fondateurs de GCM — gère les platform admins eux-mêmes

Seul le premier est attribuable depuis ce module. Les deux autres sont initialisés par l'équipe GCM et protégés par un trigger de base de données qui empêche la rétrogradation du dernier superadmin. Si vous voyez un badge Platform Admin dans la boîte de dialogue des rôles, cet utilisateur est un membre de notre équipe en train d'apporter son aide — pas un admin ordinaire.

Où trouver chaque outil

La page Utilisateurs et Rôles comporte deux onglets :

• Utilisateurs — la liste des utilisateurs connectables dans votre espace de travail. Inviter, modifier, suspendre, supprimer ; basculer les rôles de chaque utilisateur ; les attribuer à des unités organisationnelles.
• Rôles et Permissions — le catalogue de rôles et la grande matrice des permissions. Seuls les org admins voient cet onglet.

Les articles de cette section vous guident à travers chaque tâche, à peu près dans l'ordre où vous les ferez lors de la configuration :

1. Inviter un utilisateur — faire entrer quelqu'un dans l'espace de travail
2. Rôles par défaut expliqués — comprendre ce que Admin, Shepherd, Leader, Member signifient réellement
3. Créer un rôle personnalisé — quand les valeurs par défaut ne conviennent pas
4. Accorder des permissions — la matrice à 68 clés et comment l'ajuster
5. Permissions limitées — restreindre un responsable à une seule branche
6. Journal d'audit des changements de rôle — qui a promu qui, et quand
7. Récupérer un utilisateur verrouillé — que faire quand quelqu'un ne peut pas se connecter

TIP

Pour le démarrage ultra-rapide — inviter trois coéquipiers et choisir les rôles en deux minutes — voir Invitez votre équipe sous Premiers pas. Cette section est la référence approfondie.

Le frontend, les edge functions et la base de données vérifient tous

Une vérification de permission s'exécute à trois endroits :

1. L'interface masque les boutons et éléments de la barre latérale que vous ne pouvez pas utiliser, pour que l'espace de travail ne paraisse pas cassé.
2. Les edge functions affirment la permission avec assertPermission(ctx, "members.write") avant toute opération sensible.
3. Row-Level Security dans Postgres revérifie chaque lecture et écriture par rapport à has_permission() pour qu'une requête client forgée soit rejetée.

Vous n'avez pas à vous en soucier. Mais c'est pour cela qu'un rôle mal configuré ne peut jamais accidentellement laisser fuiter des données — il y a deux couches de défense sous l'écran.