Saltar al contenido principal

Arquitectura multi-tenant

QA Hub es una plataforma multi-tenant: cada organización opera en un espacio de trabajo completamente aislado llamado tenant. Todos los datos — proyectos, casos de prueba, ejecuciones, resultados, configuraciones — están acotados al tenant y nunca se comparten entre tenants.

Ciclo de vida del tenant​

EstadoAcceso
PENDINGSin acceso — esperando aprobación
ACTIVEAcceso completo al espacio de trabajo
REJECTEDRegistro denegado
SUSPENDEDAcceso revocado — datos preservados

Flujo de registro​

  1. Un usuario visita la página de registro de QA Hub y crea una cuenta.
  2. Se crea un tenant con estado PENDING.
  3. Se envía una notificación dentro de la app a todos los SUPER_ADMINs.
  4. Un SUPER_ADMIN aprueba o rechaza el tenant en /admin.
  5. Tras la aprobación, el estado del tenant pasa a ACTIVE y el usuario puede iniciar sesión.

Aislamiento de datos​

Cada consulta de Prisma en QA Hub está acotada por tenantId. No existe ningún mecanismo de acceso a datos entre tenants a través de la API. Los límites del tenant se aplican a nivel de middleware, no solo a nivel de consulta.

Los tokens de API también tienen alcance de tenant: un token creado en el Espacio de trabajo A no puede acceder a los datos del Espacio de trabajo B.

SUPER_ADMIN​

El rol SUPER_ADMIN es un rol de administrador a nivel de plataforma. Los SUPER_ADMINs pueden:

  • Aprobar, rechazar o suspender cualquier tenant
  • Suplantar a un tenant (via el panel de administración) para solucionar problemas en su nombre
  • Ver estadísticas y logs de auditoría de toda la plataforma
  • Resolver solicitudes de restablecimiento de contraseña

Los SUPER_ADMINs se asignan directamente en la base de datos — no hay promoción a este rol en modo autoservicio.

Suplantación de administrador​

Un SUPER_ADMIN puede suplantar a un tenant haciendo clic en Impersonate en el panel de administración (/admin). Esto establece una cookie qa_hub_admin_tenant acotada a ese espacio de trabajo. La sesión de suplantación puede finalizar en cualquier momento haciendo clic en Exit impersonation.

Las acciones de suplantación quedan registradas en el rastro de auditoría con la identidad del SUPER_ADMIN.

Autoalojado vs nube​

En las instalaciones autoalojadas, la configuración inicial del administrador requiere establecer directamente el estado de un tenant en ACTIVE en la base de datos. Ver Primeros pasos — Primer inicio de sesión para el SQL de bootstrap.

En el plan cloud, la aprobación de tenants es gestionada por el equipo de QA Hub.