Roles y permisos: dos capas, siete roles de organización

Los permisos en una plataforma ITAD multiinquilino tienen que estar exactamente bien o visiblemente mal. Terreno intermedio útil hay muy poco. ReVend OS usa dos capas: roles de plataforma para el operador de ReVend y roles de organización para los usuarios del inquilino.

Roles de plataforma

platform_owner puede gestionar la plataforma de punta a punta. platform_staff puede dar soporte a clientes y trabajar entre inquilinos allí donde el flujo de soporte o de administración lo permite. platform_viewer es de solo lectura, para supervisión. Las páginas de plataforma comprueban el scope de plataforma antes de mostrar herramientas exclusivas como health, los planes de paquetes o los ajustes de puntuación de confianza.

Roles de organización

Hoy se usan siete roles de organización: org_admin, org_manager, org_warehouse, org_commercial, org_finance, org_operator y org_viewer. Describen el trabajo de la persona dentro del inquilino. Los entitlements del paquete deciden qué módulos ha comprado el inquilino; el rol decide cuáles de esos módulos puede abrir una persona. Ambas comprobaciones se ejecutan, en ese orden, y una pestaña solo aparece cuando las dos dicen que sí.

Una matriz, tres lectores

Qué rol puede abrir qué módulo vive en una sola matriz dentro del código, y las pestañas de módulo, la barra lateral, la paleta de comandos y los guards de página del servidor leen todos esa misma matriz. Market, Auction y Sourcing se abren para Administrador, Gerente y Comercial. Escrow se abre para Administrador y Finanzas. Finanzas —facturas, liquidaciones, márgenes— se abre para Administrador, Gerente y Finanzas. Pruebas se abre para Administrador, Gerente, Almacén y Operador. Dashboard, Core, General, Settings y Soporte están abiertos a todos los roles de organización. El soporte de plataforma se salta la matriz por completo, porque la suplantación y el trabajo de soporte tienen que poder abrir cualquier página. Antes de que existiera la matriz, la navegación sabía qué había comprado el inquilino y los guards de página sabían qué permitía el rol, y las dos cosas no se hablaban: un usuario de finanzas tenía una pestaña Market en la que se podía hacer clic y que terminaba en un 404 pelado. Una matriz, tres lectores. Se acabaron las pestañas que no llevan a ninguna parte.

Oculto, no 404

Un módulo que su rol no puede abrir sencillamente no está en la navegación. Un usuario de finanzas no ve Market, Auction ni Sourcing; un usuario comercial no ve Escrow. Las páginas de Settings de los módulos que el inquilino no tiene desaparecen también del menú, en lugar de rebotar a la página de suscripción. Quien aun así aterrice en una de ellas por un marcador, un enlace de correo o un atajo antiguo recibe una explicación: de qué módulo se trata, que este rol no puede abrirlo, qué roles sí pueden, y un botón de vuelta al dashboard. Los ajustes de todo el inquilino reservados al administrador de la organización —facturación, horario comercial, umbrales de analítica— siguen visibles para todos, pero se abren con la nota “Gestionado por su administrador” para los demás roles. Una página que se explica cuesta un párrafo; un 404 cuesta un ticket de soporte.

Operador es el valor por defecto

Operador es el rol que lleva una invitación salvo que quien invita elija otro, y es el rol que hace el trabajo de pruebas: la pantalla de pruebas está abierta a Administrador, Gerente, Almacén y Operador. Los contratos van en la dirección contraria: crear y editar un contrato, sus servicios y tarifas, sus certificaciones requeridas y el acuerdo firmado está reservado a Administrador, Gerente y Comercial, el mismo círculo que puede activarlo. Almacén, Operador, Finanzas y Lector leen contratos; no ven botón de editar, de gestionar ni de contrato nuevo, y una llamada directa al servidor se rechaza y se registra como acceso denegado.

Dónde se aplica de verdad

La navegación de la interfaz ayuda, pero el servidor y la base de datos son los adultos de la sala. Los guards del servidor leen los roles de los registros de membresía, no de metadatos de usuario editables. RLS mantiene los datos del inquilino dentro de su inquilino. El código de administración que usa el service role tiene que añadir el scope de inquilino de forma explícita, porque el service role se salta RLS; eso es poder con papeleo, no un atajo.

Fronteras de Admin

Las páginas de Admin son solo de plataforma: los roles de plataforma ven las herramientas entre inquilinos y los usuarios que no son de plataforma son redirigidos fuera de Admin. El perfil del inquilino y la administración del equipo viven en Settings, en /settings/organization-profile y /settings/users. Una ruta que falta es molesta; una herramienta entre inquilinos que se filtra es un simulacro de incendio.

Cambios y auditoría

Los cambios de rol y de permisos son sensibles para la auditoría. La plataforma registra quién cambió el acceso, qué cambió y por qué. Si un usuario ve de repente menos botones, soporte debería poder explicarlo sin leer los posos del café en la caché del navegador.