Módulo de administración (frontend)

Pantallas para administrar a las personas (el listado, crear una cuenta y la ficha de cada una) y los roles. Las reglas viven en la API (Módulo Users): qué botones aparecen sale del campo actions de cada persona o rol; qué roles y permisos se pueden dar sale de assignable y grantable. El front no calcula la jerarquía ni decide qué es sensible.

El menú muestra “Usuarios” solo con users.view y “Roles” solo con roles.manage. “Nueva persona” aparece con users.create y “Nuevo rol” con roles.manage.

Pantallas

Listado

• Criterios en la URL (role, status, mfa, search, sort, page, per_page), con la misma mecánica del listado de incidentes (useRouteList).
• Búsqueda al dejar de escribir, por nombre o correo.
• Filtros de una sola opción (estado y MFA): se quitan eligiendo “Todas”.

Crear una cuenta

• Campos: nombre, correo y rol. El rol se elige con AppRadioList, solo entre los roles que quien crea puede dar, cada uno con una línea que explica qué hace.
• Contraseña: no se define ninguna. Un aviso a la vista explica que a la persona le llega un correo para crearla.
• Si el rol trae permisos de administración, la API pide el código de quien crea y se abre el diálogo del código.
• Doble envío: la creación lleva Idempotency-Key, así un doble clic no crea dos cuentas.
• Al terminar, va a la ficha nueva con el aviso “Cuenta creada…”.

Ficha

Arriba, ”‹ Usuarios” (AppBackLink) vuelve al listado. Debajo, el nombre y las etiquetas de estado y rol (el correo va en la tarjeta Datos); a la derecha (desde tablet) o debajo a todo el ancho (celular), el botón “Ver su actividad”.

Portátil y monitor: dos columnas iguales, con Datos, Rol y Acceso a la izquierda y Permisos a la derecha, que se estira hasta el final de Acceso para que las dos columnas terminen parejas. Celular y tablet: una columna.

• “Ver su actividad” (botón con el ícono de Auditoría, con permiso de auditoría): lleva a la auditoría filtrada por esa persona, en la pestaña de administración o, si solo se tiene la de incidentes, en esa (Módulo de auditoría).
• La cuenta propia: un aviso explica que solo puede corregir sus datos. El resto lo cambia otra persona.
• Desactivar pide confirmación. Si la persona tiene incidentes pendientes asignados, la confirmación lo dice: no se reasignan solos.
• En el editor de permisos, un permiso que quien administra no tiene, y que la persona tampoco tiene, queda deshabilitado. El ícono de información explica por qué. Quitarlo sí se puede.

Roles

• Listado, de mayor a menor nivel: nombre (con “Base” en los cinco roles de sistema), código, nivel, personas, cuántos permisos trae y su política de MFA (“Obligatoria · 1 de gracia” u “Opcional”).
  • Portátil y monitor: tabla (AppDataTable).
  • Tablet y celular: tarjetas.
• Crear y editar comparten la pantalla (RoleFormPage).
  • Portátil y monitor: Datos y Verificación en dos pasos lado a lado, y Permisos debajo, a lo ancho. Celular y tablet: una columna.
  • Datos (RoleFields): código (solo al crear; después no cambia), nombre y nivel, con la regla de cada uno en el ícono de información. El nivel usa el teclado numérico en el celular.
  • Verificación en dos pasos: casilla “Obligatoria para este rol” y, si lo es, los ingresos en que se puede posponer.
  • Permisos: PermissionChecklist con casillas, en modo columns para que la página no se alargue:
    • Portátil y monitor: los módulos se reparten en tres columnas; tablet, en dos. Cada módulo muestra cuántos van marcados (“5 de 14”).
    • Celular: cada módulo es una fila plegable con el conteo a la vista. Arranca abierto el que trae un permiso que quien edita no puede conceder.
    • Cada módulo tiene la casilla “Todos” (a medias si solo hay una parte marcada). Al marcarla suma solo los permisos que quien edita puede conceder; al desmarcarla quita todo el módulo. Las reglas están en moduleSelection y toggleModule (domain/permissions.ts).
    • Al crear, “Copiar permisos de” otro rol llena la lista para no empezar desde cero.
    • El panel de permisos de una persona usa la lista en una sola columna, porque es angosto y se desplaza por dentro.
• Guardar un rol que tiene personas pide confirmación indicando a cuántas afecta. Si la API pide el código, se abre el diálogo del código.
• “Eliminar rol” solo aparece si la API lo permite (un rol creado que nadie tiene) y pide confirmación.
• Si el rol no se puede editar (el Super admin, o uno en el nivel de quien administra o por encima), se muestra sin campos y con un aviso que dice por qué.
• Formularios de personas al día: después de cada cambio de un rol, el catálogo de los formularios de personas se invalida (useAccessCatalogStore.invalidate) y se vuelve a leer en la siguiente pantalla.

Reautenticación

useReauth (en shared/ui/feedback, porque también lo usa la pantalla de sistema) intenta el cambio sin código. Si la API responde REAUTHENTICATION_REQUIRED, abre AppCodeDialog y lo reintenta con el código. Si la persona cierra el diálogo, el cambio no se hizo y el diálogo de origen (por ejemplo, el de cambiar rol) sigue abierto.

Restablecer el MFA o el acceso siempre lo pide, así que el diálogo del código se abre de una vez y sirve también como confirmación.

Capas

Dónde está en el código

• frontend/src/modules/admin/
• Componentes compartidos: AppDataTable, AppFilterSheet, AppRadioList, AppFormDialog y AppCodeDialog
• Listado ligado a la URL: shared/listing/useRouteList.ts
• Pruebas: *.spec.ts del módulo, e2e/users.spec.ts y e2e/roles.spec.ts
• Decisiones: ADR-0053 y ADR-0055