Crear un rol personalizado

Los tres roles predeterminados cubren la mayoría de los casos, pero cada iglesia eventualmente necesita algo que no encaja en ellos — un tesorero que puede registrar donaciones pero no puede ver direcciones de miembros, un líder de alabanza que gestiona un solo ministerio, un coordinador de voluntarios que maneja asistencia durante la semana pero nunca toca donaciones. Los roles personalizados te permiten construir exactamente el paquete de permisos que quieres y darle un nombre que tu equipo reconozca.

Abre el diálogo de crear rol

Desde Usuarios y Roles → Roles y Permisos, haz clic en el botón Agregar rol en la esquina superior derecha de la tarjeta Gestionar roles. La pestaña Roles y Permisos solo es visible para usuarios con users.manage — si no la ves, probablemente has iniciado sesión como un Leader o Viewer; cambia a una cuenta Administrator.

Completa los tres campos

Nombre del rol

Cómo se llama el rol en todos los lugares donde aparece — el chip en el perfil de un usuario, el encabezado de columna en la matriz de permisos, la opción en el selector de rol cuando estás invitando a un usuario. Usa el título que tu iglesia realmente usa en voz alta: Tesorero, Líder de alabanza, Recepcionista de visitantes, Coordinador de escuela dominical. Dos o tres palabras es el punto óptimo.

Llave del rol

Un identificador corto, seguro para máquina, que la base de datos y el registro de auditoría usan para referenciar el rol. Si la dejas en blanco, GCM la deriva del nombre — minúsculas, espacios reemplazados con guiones bajos, puntuación eliminada. Worship Leader se convierte en worship_leader; Sunday School Coordinator se convierte en sunday_school_coordinator.

Puedes sobreescribirla si quieres algo más corto (treasurer en lugar de church_treasurer), pero elige con cuidado — la llave es lo que aparece en los registros de error, en el rastro de auditoría, y en cualquier integración personalizada que consulte la tabla de roles. Una vez que un usuario ha sido asignado al rol, cambiar la llave dejaría huérfana la asignación, así que la UI no te deja editarla después de la creación. Elimina y recrea si necesitas una llave diferente.

TIP

Apégate a letras minúsculas, dígitos y guiones bajos. El derivador automático hace cumplir esto, y la base de datos tiene un índice único en (organization_id, key) para que dos roles en tu espacio de trabajo no puedan compartir una llave.

Descripción

Una nota de una línea para que el siguiente admin la lea. "Registra donaciones y gestiona fondos, pero no puede ver direcciones de miembros ni el historial de donaciones de otros miembros." Opcional, pero apreciada — se muestra debajo del nombre del rol en la lista de roles y en el tooltip de columna en la matriz de permisos.

Guardar y elegir permisos

Haz clic en Crear. El rol es insertado en roles_v2 con is_system = false (lo que lo hace eliminable después) e inmediatamente aparece como una nueva columna en la matriz de permisos debajo. Comienza con cero permisos marcados — la matriz es tu lienzo en blanco.

Desplázate por la matriz y activa lo que el rol necesita. Cada interruptor escribe en role_permissions_v2 en el momento que lo mueves; no hay botón de guardar. Ve Otorgar permisos para el catálogo completo y combinaciones comunes.

WARNING

Un rol personalizado con cero permisos es funcionalmente inútil — asígnalo a un usuario y pueden iniciar sesión pero cada página devuelve un banner de permiso denegado. La UI te deja crear roles vacíos deliberadamente (podrías querer otorgar permisos después) pero no los dejes vacíos en producción.

La bandera is_system

Los tres roles sembrados tienen is_system = true. Los tuyos tendrán is_system = false. Esto importa en dos lugares:

1. La lista de roles oculta el botón de eliminar en roles del sistema. Todavía puedes alternar sus permisos — eso es seguro — pero no puedes removerlos por completo.
2. Un trigger de base de datos también hace cumplir esto en el backend. Incluso si pasas por alto la UI y llamas al endpoint de eliminar directamente, el SQL rechaza la petición con un error cannot delete system role.

La bandera is_system se establece al momento de inserción y no puede ser cambiada después. No hay forma soportada de convertir un rol personalizado en uno del sistema, o viceversa. Si necesitas eso, contacta a soporte y lo manejaremos vía una sesión de impersonación de platform admin.

Eliminar un rol personalizado

Haz clic en el ícono rojo de basura en la fila en la lista de roles. Dos verificaciones se ejecutan:

1. Si algún usuario aún está asignado al rol, la eliminación es rechazada con un conteo de cuántos. Reasigna o remueve esos usuarios primero — ve Invitar un usuario para el diálogo de asignación.
2. Si la eliminación tiene éxito, cada fila en role_permissions_v2 para ese rol también es removida en la misma transacción. Nada es eliminado suavemente; esta es una limpieza dura.

Si eliminas por accidente, necesitarás recrear el rol y volver a otorgar los permisos. Los roles personalizados no están en la papelera de reciclaje.

Patrones de nombres que funcionan

Algunos patrones que hemos visto pagar:

• Tesorero — giving.view, giving.record, giving.manage, reports.view. Nada más. Excelente para el contador de efectivo y el comité de auditoría.
• Líder de alabanza — members.view, events.view, events.create, events.edit, messaging.send. Limitado al ministerio Equipo de alabanza, gestionan ensayos sin ver el directorio más amplio.
• Recepcionista de visitantes — members.view, members.create, forms.submit. Permite al voluntario de la mesa de bienvenida agregar nuevos visitantes durante el servicio.
• Auditor — cada permiso view y nada más. Misma forma que Viewer pero nombrado para contexto, así que el registro de auditoría muestra Auditor inició sesión en lugar de Viewer inició sesión.

Siguiente

• Otorgar permisos — la matriz en detalle.
• Permisos limitados — restringir el rol a una sola sede.
• Registro de auditoría de cambios de rol — ver quién crea y edita roles.