Saltar a contenido

Visión general del sistema

Qué es

e-training-back es la API del sistema de formación (e-training). Expone operaciones REST que consumen clientes (web, móvil u otros servicios) para gestionar usuarios, formación y recursos asociados.

Capacidades principales (desde el usuario del sistema)

  • Organizaciones: Empresas o entidades que usan E-Training; tipos COMMON y SUPER_ADMIN, slug fiscal, contacto principal, usuarios y roles. Ver 01-organizaciones.md.
  • Permisos: Recurso + acción (READ, WRITE, etc.); lista cerrada; ORGANIZATION solo para SUPER_ADMIN. Ver 02-permisos.md.
  • Roles: Roles por organización. Ver 03-roles.md (por documentar).
  • Modos existenciales: E-Modes; se asigna por test de onboarding o desde E-Talent. Ver 05-modos-existenciales.md.
  • Niveles: Conocimiento sobre E-Modes (1–3); desbloquean funcionalidades; cambio manual por administrador. Ver 06-niveles.md.
  • Usuarios: Un rol y una organización; creados por registro de org o invitación; onboarding; nivel por defecto 1. Ver 07-usuarios.md.
  • Registro: Alta de organización + primer usuario. Ver 08-registro.md.
  • Invitaciones: Organizaciones invitan usuarios por email; el invitado completa registro + onboarding. Ver 09-invitaciones.md.
  • Autenticación: Login y renovación de tokens mediante refresh tokens. Ver 10-autenticacion.md.
  • Entrevista E-Talent: Flujo de entrevista para determinar el eMode del usuario; integración con E-Talent vía webhook. Ver 11-entrevista.md.
  • Brun-E — Sesiones de voz: Conversaciones de voz con el asistente Brun-E; validación de derecho (créditos/cooldown), permiso temporal para la llamada, pantalla y conexión en el navegador; canal de apoyo y E-map (Fase B). Ver 12-brun-e-sesiones-voz.md.

Otras capacidades (equipos, cursos, etc.) se documentarán aquí cuando existan como funcionalidad expuesta.

Criterios generales de comportamiento

  • Las respuestas de la API siguen el formato JSON:API cuando aplica.
  • Los errores de validación o negocio se devuelven con códigos HTTP y mensajes traducidos (i18n) según el estándar del proyecto.
  • No se documentan en el DRF detalles de implementación (bases de datos, frameworks o arquitectura interna).