4.5 KiB
Tickets
Cada ticket pertenece a una única compañía, que no puede cambiar tras el alta. Tiene UUID v7 y referencia corta global T-000001. La referencia se reserva en una transacción; no sustituye al UUID.
Información y comportamiento
Asunto obligatorio y descripción opcional. Solicitante opcional entre las personas de la compañía; responsable opcional entre los usuarios internos de Metis Desk. Las personas de las compañías no acceden a esta aplicación.
Canales: email, teléfono, interno y otro. Estados: abierto, en curso, en espera, resuelto y cancelado. Prioridades: baja, normal, alta y urgente. El formulario empieza abierto, prioridad normal y canal email. Se puede reabrir un ticket editando su estado; siempre se conserva el historial.
Elementos afectados opcionales y múltiples: personas, puestos de trabajo, activos y recursos de la misma compañía. No se repite el mismo tipo e identificador. Solo se añaden elementos disponibles y personas/usuarios activos; las referencias existentes que se desactivan se pueden conservar para consulta e historial.
Cada cambio semántico crea TicketRevision con UUID, usuario y fecha. Guardar sin cambios no añade otra revisión. El último UUID de revisión protege la edición frente a cambios simultáneos: el formulario muestra un conflicto y permite cerrarlo y abrir la versión actual.
Las altas incluyen una clave de solicitud para evitar duplicar un ticket al reintentar. La misma clave y datos originales devuelve el ticket existente; reutilizarla con otros datos, actor o compañía se rechaza. El navegador genera la clave con el generador compartido, compatible con HTTP por IP local.
No se eliminan tickets. Cancelar o resolver conserva toda la información. Esta entrega no incluye intervenciones ni tiempos de trabajo.
Interfaz
Tickets dentro de cada compañía muestra únicamente sus registros. Todos los tickets se abre desde el acceso T de la barra de espacios; reúne todas las compañías. Permite buscar por referencia/asunto/compañía/solicitante y filtrar por compañía (vista global), estado, prioridad y responsable, incluyendo sin asignar. Orden inicial: último cambio más reciente.
Nuevo ticket está a la derecha de la cabecera. Alta y edición en modal; la ayuda aparece inmediatamente antes del pie Guardar/Cancelar. En la compañía, esta queda fijada. En la vista global se selecciona; cambiarla antes de guardar limpia solicitante y elementos afectados, conservando el resto del formulario.
SelectWithAction permite crear compañía, solicitante y elementos afectados desde el propio formulario. Las altas rápidas reutilizan los formularios de persona, activo, recurso y puesto, conservan los datos del ticket y seleccionan el elemento creado.
Ficha e historial muestra datos, revisiones, autor y fecha. Los nombres de referencias se consultan en los catálogos actuales; las revisiones conservan los identificadores originales.
Arquitectura y persistencia
Ticket es AggregateRoot, TicketValues encapsula Name, referencias UniqueID/Maybe y TicketTarget como valor de referencia tipada. TicketRevision es DomainEntity. Las referencias afectadas no tienen un ciclo de vida independiente; se comparan como valores sin importar el orden.
Migración explícita e idempotente: tickets, ticket_revisions y ticket_counter (contador técnico). FK a compañía, solicitantes, responsables y actores, unicidad de referencia, clave de solicitud y posición de revisión. Escritos en una transacción, con bloqueo de compañía y contador para garantizar coherencia y numeración global.
Los activos/puestos y recursos se consultan mediante servicios públicos de sus módulos; no se importan modelos ORM ajenos. Repositorio y mapper propios en Infrastructure, puertos y adaptación en Application.
API autenticada:
- GET /api/tickets: listado global.
- GET /api/tickets/:companyId: listado de compañía.
- GET /api/tickets/:companyId/lookups: opciones de esa compañía.
- POST /api/tickets/:companyId: alta.
- POST /api/tickets/:companyId/:id/update: edición.
Entradas y salidas estrictas. Escrituras protegidas por sesión, CSRF y origen. La compañía del ticket y las referencias se validan en el servidor.
Validación
Pruebas de dominio/mapper, filtros y renderizado de formularios, e integración HTTP/MariaDB: pertenencia, campos opcionales, afectados únicos, inactividad, referencias conservadas, UUID, referencia global, historial, idempotencia, conflictos concurrentes, autenticación, CSRF y origen. Las pruebas usan la base dedicada y no crean registros de prueba en desarrollo.