Accorder des permissions
Les permissions sont les petits verbes que la plateforme vérifie réellement. Cet utilisateur peut-il enregistrer un don ? Peut-il supprimer un membre ? Peut-il approuver un rapport ? Chaque verbe a une clé comme giving.record ou members.delete, et la réponse est oui si l'un des rôles de l'utilisateur a cette clé activée dans role_permissions_v2.
Il y a 68 clés. Elles sont livrées avec la plateforme — vous ne pouvez pas en ajouter, vous ne pouvez pas renommer celles qui existent, et elles ne changent pas d'une église à l'autre. Ce que vous contrôlez, c'est le câblage : quels rôles accordent quelles clés. Ce câblage vit dans la matrice de permissions.
Ouvrir la matrice
Depuis Utilisateurs et Rôles, cliquez sur l'onglet Rôles et Permissions. La matrice apparaît sous la liste des rôles, avec une ligne par permission et une colonne par rôle. La boîte de filtre en haut à gauche réduit les lignes visibles par ressource, action, clé ou description — tapez giving pour ne voir que les sept clés de dons, ou delete pour voir chaque permission destructive de tous les modules à la fois.
Comment la matrice est organisée
Les permissions sont regroupées par ressource — members, giving, reports, events, etc. Au sein de chaque groupe, elles sont triées par action (view avant edit avant delete). Le regroupement est purement visuel ; sous le capot, chaque permission est une clé plate. La taxonomie complète :
| Ressource | Actions visibles |
|---|---|
dashboard | view |
members | view, create, edit, delete, merge |
attendance | view, mark |
giving | view, record, manage, donate |
reports | view, view_all, submit, manage, delete, export, approve, unlock |
org_units | view, create, edit, delete, manage |
schools | view, manage |
demographics | view |
map | view, manage |
ministries | view, manage |
groups | view, manage |
events | view, create, edit |
messaging | view, send |
notifications | view, send |
users | manage |
custom_fields | view, manage |
config | manage |
billing | manage |
website | manage, publish, blog, sermons |
podcast | manage |
workflows | view, manage, execute, enroll |
forms | submit, manage, view_submissions |
zapier | view, manage |
Cela fait 68 au total. La liste canonique vit dans src/shared/lib/access-policy.ts côté frontend et supabase/functions/_shared/access-policy.ts côté backend — les deux fichiers sont maintenus synchronisés.
Basculer une permission
Trouvez la ligne (la permission) et la colonne (le rôle), puis basculez l'interrupteur. Le changement est écrit dans role_permissions_v2 immédiatement — pas de bouton d'enregistrement, pas d'étape de confirmation. Les utilisateurs ayant ce rôle adoptent le nouveau comportement à la prochaine navigation de page ou refetch React Query (typiquement en quelques secondes).
L'interrupteur est symétrique : le désactiver supprime la ligne de role_permissions_v2 ; l'activer l'insère. Les deux actions sont écrites dans le journal d'audit avec l'e-mail de l'acteur et l'horodatage, vous pouvez donc toujours reconstituer qui a changé quoi.
Combinaisons courantes
Les rôles les plus utiles regroupent quelques clés ensemble. Une référence pour les motifs que nous voyons le plus souvent :
Lire + écrire une ressource
members.view + members.edit — la paire la plus courante. Permet à quelqu'un de mettre à jour les numéros de téléphone et les adresses sans pouvoir ajouter ou supprimer qui que ce soit. Bon pour un membre de l'équipe qualité des données.
giving.view + giving.record — enregistrer des dons et voir l'historique. La forme classique du Trésorier. Ajoutez giving.manage s'il crée aussi des fonds ; laissez-le désactivé si vous voulez un gestionnaire de fonds séparé.
attendance.view + attendance.mark — exactement ce dont le bénévole de check-in a besoin. Associez-le aux permissions limitées pour le restreindre à un seul culte ou campus.
Créer + modifier mais pas supprimer
members.create + members.edit (sans members.delete). Courant pour les responsables de ministère — ils peuvent ajouter des visiteurs et mettre à jour les enregistrements existants mais ne peuvent supprimer personne. Les suppressions nécessitent généralement un admin.
events.create + events.edit (sans delete) — même forme pour le travail de calendrier. Permet à un responsable de louange d'ajouter la série de répétitions sans pouvoir supprimer les archives de l'année dernière.
Lecture seule sur l'ensemble
Chaque clé view sans rien d'autre est le rôle Viewer. Utile pour les membres du conseil, les auditeurs et le personnel en période d'essai. Il y a un dashboard.view dédié pour qu'un Viewer puisse atterrir quelque part de significatif.
Manage vs verbes inférieurs
Pour certaines ressources, manage est un sur-ensemble qui implique les verbes inférieurs. giving.manage inclut la capacité d'enregistrer et de voir dans l'interface mais les permissions explicites giving.record et giving.view doivent toujours être activées pour que les edge functions et RLS autorisent les opérations. Accordez toujours les verbes inférieurs en plus de manage — la matrice ne les accorde pas automatiquement.
config.manage est la seule grande exception : c'est un unique interrupteur qui contrôle chaque page de paramètres (channels, modules, PWA, configuration des visiteurs, journaux de données). Il n'y a pas de clés lecture/écriture séparées pour celles-là.
Où la vérification s'exécute réellement
Une permission n'est pas vérifiée une seule fois — elle est vérifiée à trois endroits, dans cet ordre :
- L'interface utilise
usePermissions().has("giving.record")pour masquer les boutons. C'est purement cosmétique ; une requête client forgée peut toujours appeler l'API. - La edge function appelle
assertPermission(ctx, "giving.record")depuis_shared/caller-context.ts. Si l'utilisateur n'a pas la clé, la fonction renvoie 403 avant de toucher la base de données. - Row-Level Security dans Postgres revérifie via le helper SQL
has_permission()pour la couche finale de défense.
Cette vérification à trois couches signifie qu'un rôle mal configuré ne peut jamais accidentellement laisser fuiter des données — même si l'interface se désynchronise de la base de données, la edge function et RLS rejetteront la requête.
Filtrer la matrice
Pour les églises avec beaucoup de rôles personnalisés, la matrice peut être large. Le champ de filtre la rétrécit en tapant :
giving— uniquement la section dons.delete— chaque action destructive de la plateforme.members.merge— trouver une clé spécifique.report— correspond aussi à reports.
Le filtre vérifie ressource, action, clé et description — celui qui correspond en premier gagne.
Pour aller plus loin
- Permissions limitées — associer un octroi de permission à une limite d'unité organisationnelle.
- Journal d'audit des changements de rôle — voir qui a basculé quoi.
- Rôles par défaut — ce qu'incluent les rôles initialisés.