Usuarios y Roles
Cada acción en GCM está controlada por un permiso. Registrar una donación, eliminar un miembro, enviar una difusión por WhatsApp, exportar un informe — cada una verifica los roles del usuario que ha iniciado sesión contra el catálogo de permisos antes de que la base de datos, la edge function o la UI la permitan. Este módulo es donde decides quién tiene cuál llave.
Usuarios vs miembros
GCM mantiene estos dos conceptos estrictamente separados:
- Un usuario es alguien que puede iniciar sesión en GCM. Tiene un correo, una contraseña y uno o más roles.
- Un miembro es alguien en tu congregación. Tiene un perfil, historial de asistencia, donaciones — pero la mayoría de ellos nunca iniciará sesión.
Los dos se superponen (un pastor es ambos), pero los módulos no comparten IDs. Invitar a alguien como usuario no lo agrega a tu lista de miembros; registrar un miembro no crea un inicio de sesión para él. Esto es intencional: puedes invitar a un auditor externo sin contaminar el conteo de tu congregación, y puedes registrar a un niño como miembro sin emitirle credenciales.
Roles vs permisos
El modelo tiene tres capas:
- Permisos — verbos pequeños y fijos como
members.create,giving.record,reports.approve. Hay 68 de ellos, distribuidos por la plataforma. No puedes agregar ni renombrarlos. - Roles — paquetes de permisos. Admin, Shepherd, Leader, Member vienen como roles del sistema; puedes crear roles personalizados (Tesorero, Líder de alabanza, Recepcionista de visitantes) y alternar qué permisos otorga cada uno.
- Asignaciones — quién tiene qué rol, opcionalmente limitado a una porción de tu estructura organizacional.
Cuando alguien intenta hacer algo, la plataforma pregunta: ¿alguno de sus roles incluye este permiso, y su alcance de asignación incluye esta fila? Ambos deben pasar.
Dos sabores de admin
Hay tres conceptos de administrador y son fáciles de confundir:
| Tipo de admin | Alcance | Para quién es |
|---|---|---|
| Org admin | Solo tu iglesia | Pastor principal, administrador ejecutivo — opera tu espacio de trabajo |
| Platform admin | Cada iglesia en la plataforma | El equipo de GCM — atiende escalaciones de soporte |
| Superadmin | Cada iglesia + puede gestionar otros platform admins | Los fundadores de GCM — atiende a los platform admins mismos |
Solo el primero es asignable desde este módulo. Los otros dos son sembrados por el equipo de GCM y protegidos por un trigger de base de datos que previene la degradación del último superadmin. Si ves una insignia de Platform Admin en el diálogo de roles, ese usuario es un miembro de nuestro equipo ayudando con soporte — no un admin regular.
Dónde encontrar cada herramienta
La página de Usuarios y Roles tiene dos pestañas:
- Usuarios — la lista de usuarios con sesión iniciada en tu espacio de trabajo. Invitar, editar, suspender, eliminar; alternar qué roles tiene cada usuario; asignarlos a unidades organizacionales.
- Roles y Permisos — el catálogo de roles y la gran matriz de permisos. Solo los org admins ven esta pestaña.
Los artículos en esta sección te guían por cada tarea, aproximadamente en el orden en que las harás al configurar:
- Invitar un usuario — meter a alguien en el espacio de trabajo
- Roles predeterminados explicados — entender qué significan realmente Admin, Shepherd, Leader, Member
- Crear un rol personalizado — cuando los predeterminados no encajan
- Otorgar permisos — la matriz de 68 llaves y cómo ajustarla
- Permisos limitados — limitar un líder a una sola sede
- Registro de auditoría de cambios de rol — quién promovió a quién y cuándo
- Recuperar un usuario bloqueado — qué hacer cuando alguien no puede iniciar sesión
TIP
Para el arranque rápido absoluto — invitar a tres compañeros de equipo y elegir roles en dos minutos — ve Invita a tu equipo bajo Primeros Pasos. Esta sección es la referencia más profunda.
El frontend, las edge functions y la base de datos todos verifican
Una verificación de permiso se ejecuta en tres lugares:
- La UI oculta botones y elementos de la barra lateral que no puedes usar, para que el espacio de trabajo no se vea roto.
- Las edge functions afirman el permiso con
assertPermission(ctx, "members.write")antes de hacer cualquier cosa sensible. - Row-Level Security en Postgres re-verifica cada lectura y escritura contra
has_permission()para que incluso una petición de cliente falsificada sea rechazada.
No tienes que pensar en esto. Pero es por eso que un rol mal configurado nunca puede filtrar datos accidentalmente — hay dos capas de defensa debajo de la pantalla.