Roles y permisos
Roles propios, por qué el permiso se pregunta a la base y qué garantiza de verdad una revocación.
Los roles son tuyos
La plataforma trae roles por defecto, pero tu organización puede crear los suyos, combinando los permisos que tengan sentido para tu estructura. Un rol que solo lee privacidad, uno que administra proveedores sin tocar facturación, uno que revisa documentos y nada más.
La pregunta es qué puedes, no cómo te llamas
Internamente, la plataforma nunca decide comparando el nombre del rol. Pregunta si ese usuario tiene ese permiso, y la respuesta viene de la base de datos.
La diferencia no es sutil. Comparar nombres funcionaba mientras todas las organizaciones tenían los mismos tres roles, y deja de funcionar en el instante en que un cliente crea el suyo. Un rol que tiene el permiso de administrar la organización es un administrador en todo sentido que importa — y una comparación por nombre lo rechazaría por no estar escrito "admin".
Dos capas, no una
La verificación en la aplicación y la política de aislamiento en la base consultan la misma fuente, a propósito: así una pantalla y una consulta no pueden discrepar sobre el mismo usuario.
Tienen funciones distintas. La de la base es la que garantiza el aislamiento — gruesa e ineludible. La de la aplicación es la que da expresividad, permitiendo permisos finos por acción. La primera es la seguridad; la segunda es la precisión.
Efecto de un cambio
Cambiar el rol de alguien vale en su acción siguiente, porque el permiso se consulta en el momento del uso y no se guarda en la sesión. No hace falta pedirle a la persona que salga y vuelva a entrar.