Affecter des responsables et des bergers

Il y a deux choses distinctes que vous pourriez vouloir dire quand vous dites "Jane dirige la Branche Nord". GCM les stocke dans deux tables différentes et elles font des travaux très différents.

1. Responsable d'une unité — le nom d'un seul membre s'affiche dans la carte héros de l'unité, le badge de responsable et les rapports. Stocké sur org_units.leader_member_id.
2. Utilisateur restreint à une unité — la connexion d'un utilisateur est restreinte à ne voir que les données dans (et sous) cette unité. Stocké dans user_unit_assignments_v2.

Un responsable est une relation d'affichage. Une portée d'utilisateur est une relation de sécurité. C'est souvent la même personne, mais ce ne doit pas l'être — et quand ce n'est pas le cas, vous verrez la valeur de la séparation.

Définir un responsable

Dans l'arbre organisationnel, chaque ligne d'unité a un bouton Définir le responsable à droite de son nom (ou Changer de responsable si l'un est déjà affecté). Cliquez dessus pour ouvrir un petit popover avec une recherche de membre.

• Tapez deux caractères pour déclencher le RPC search_members.
• Choisissez un résultat pour écrire leader_member_id sur l'unité.
• Un toast confirme ; la ligne se met à jour immédiatement avec le nouveau nom et un petit avatar.
• Pour effacer, ouvrez le popover sur une unité qui a déjà un responsable et cliquez sur Retirer le responsable.

Le bouton utilise un contour ambre doux quand aucun responsable n'est affecté, attirant votre œil sur les lacunes. Sur de grands arbres, c'est ainsi que vous repérez les cellules sans personnel sans défiler.

Ce que définir un responsable fait :

• Le nom + l'avatar du responsable s'affiche sur la carte d'unité, le héros de détails de l'unité et chaque endroit où l'unité est mentionnée dans les rapports.
• La photo du responsable et l'anneau de statut perdu/actif se rendent via le composant partagé MemberAvatar, donc un responsable qui est devenu "perdu" obtient un indice visuel.
• La vue unit_with_leader alimente le ratio "responsables affectés" sur la page de niveau (par exemple "2 / 7 responsables affectés").
• Cela ne change pas ce que la connexion utilisateur de ce membre peut voir. C'est la prochaine section.

Restreindre un utilisateur à une unité

C'est la moitié sécurité. Un compte utilisateur (pas un enregistrement de membre) obtient une ligne dans user_unit_assignments_v2 par unité que vous lui accordez. Sa portée visible est l'union de ses unités affectées et de tous les descendants.

Où le définir

Allez dans Utilisateurs et rôles → Utilisateurs, trouvez la ligne, et cliquez sur Modifier les affectations. Le sélecteur affiche votre hiérarchie complète avec des cases à cocher. Cochez chaque unité qu'il devrait voir.

Un modèle typique :

• Un admin d'organisation a zéro ligne dans la table — il voit tout.
• Un pasteur régional a une ligne au niveau 1 (une région). Il voit les branches, centres, cellules et membres de cette région.
• Un berger de cellule a une ligne au niveau 3 (une cellule). Il ne voit que sa cellule.
• Un directeur de louange multi-campus a deux lignes au niveau 2. Il voit les sous-arbres des deux campus.

Comment la portée est appliquée

Quand un utilisateur non-admin est connecté, le frontend appelle un RPC Postgres nommé user_visible_unit_ids qui parcourt l'arbre et renvoie chaque id d'unité qu'il peut toucher. Le hook useUnitScope met le résultat en cache pendant 2 minutes.

Chaque page de liste dans GCM filtre par org_unit_id IN (visible_unit_ids) avant de rendre. Les politiques RLS sur les tables sous-jacentes font de même. Un berger qui modifie ses requêtes réseau de navigateur ne peut pas tirer des lignes en dehors de sa portée — la base de données les refuse.

Défaut fermé en cas d'échec

Si le RPC échoue ou n'a pas encore renvoyé, le hook traite la portée comme vide plutôt qu'ouverte. Un coup réseau ne montrera pas accidentellement à un berger les données du pasteur principal — il verra juste une liste vide jusqu'à ce que le RPC se résolve.

Quand le responsable et la portée utilisateur divergent

Cas courants où ces deux ne sont intentionnellement pas la même personne :

• Le responsable d'un petit groupe est le berger reconnu que vous annonceriez depuis l'estrade, mais il n'utilise pas l'application. Aucune ligne user_unit_assignments_v2 n'existe pour lui.
• Un assistant administratif a la portée utilisateur pour saisir des données pour une branche mais n'est pas le responsable public. Il obtient une ligne user_unit_assignments_v2 mais leader_member_id pointe vers le pasteur.
• Un pasteur régional est le responsable de sa région (niveau 1) et a aussi la portée utilisateur à ce niveau. Les deux enregistrements correspondent. C'est le cas le plus courant.

GCM ne synchronise jamais automatiquement les deux. Définir un responsable ne crée pas de ligne de portée utilisateur, et donner à un utilisateur une portée ne le définit pas comme responsable. Vous faites les deux appels délibérément.

Le niveau le plus étroit

Quand un utilisateur a des affectations à plusieurs niveaux, GCM choisit le plus étroit (l'index de niveau le plus élevé) comme filtre par défaut sur les sélecteurs en cascade. Cela signifie qu'un utilisateur affecté à une région et à une cellule spécifique se met par défaut sur la vue cellule, avec une bascule manuelle pour élargir.

useUnitScope expose cela comme narrowestLevel. Les sélecteurs au-dessus de ce niveau peuvent être verrouillés sur la seule affectation de l'utilisateur s'il n'en a qu'une à ce niveau.

Aperçu des permissions

Action	Admin	Pasteur régional	Berger de cellule	Membre
Affecter un responsable à une unité	oui	dans la portée	non	non
Définir la portée utilisateur sur une unité	oui	dans la portée	non	non
Voir les membres d'une unité	global	dans la portée	dans la portée	propre uniquement
Voir la présence d'une unité	global	dans la portée	dans la portée	propre uniquement
Voir les dons d'une unité (si pas verrouillés par confidentialité)	global	dans la portée	configurable	propre uniquement

"Dans la portée" signifie que l'utilisateur ne peut toucher que les unités qui sont dans son propre sous-arbre visible. Il peut accorder une portée pas plus large que la sienne.

Questions courantes

Un responsable peut-il voir la liste des membres de son unité même sans portée utilisateur ? Seulement si son compte utilisateur a la portée. Définir leader_member_id sur un membre ne lui accorde pas de connexion ou de portée. S'il n'a pas encore de connexion, invitez-le via Utilisateurs et rôles et choisissez l'unité pendant le flux d'invitation — GCM crée la ligne user_unit_assignments_v2 pour vous.

Que se passe-t-il si j'affecte un responsable qui n'est pas membre ? Vous ne pouvez pas. Le sélecteur de responsable ne montre que les membres existants. Ajoutez-le comme membre d'abord.

Archiver une unité efface-t-il son responsable ? Non — le leader_member_id reste. Quand l'unité est restaurée, le responsable est toujours attaché. L'archivage ne supprime pas non plus les lignes de portée utilisateur ; les unités restaurées reviennent entièrement câblées.

Le même membre peut-il diriger plusieurs unités ? Oui. Il n'y a pas de contrainte d'unicité sur leader_member_id. Un pasteur peut diriger une région et une cellule en même temps — courant quand un pasteur principal anime aussi un groupe de discipulat.

Étapes suivantes

• Archiver et restaurer quand la composition de l'équipe change.
• Lisez l'aperçu utilisateurs-rôles pour le côté gestion d'utilisateurs de l'image.
• Invitez des membres d'équipe et définissez leur portée en un seul flux.