Consolidar MobileFix como una aplicación estable, limpia y estructurada, implementando:
- Vistas en Thymeleaf.
- Persistencia con JPA/Hibernate sobre MySQL.
- Arquitectura por capas (controller, service, repository, model, dto, config, view).
- Gestión de permisos mediante validaciones, sin frameworks de seguridad.
- API basada en DTOs con respuestas coherentes.
- Trazabilidad y commits convencionales.
- Sustitución completa de JSP/JSTL por Thymeleaf.
- Migración de H2 a MySQL con JPA/Hibernate.
- Eliminación de autenticación y seguridad embebida.
- Implementación de validaciones explícitas para determinar permisos y accesos.
- Reemplazo de entidades expuestas por DTOs de entrada y salida.
- Unificación del formato de errores y validaciones.
- Incorporación de campos de auditoría automáticos.
- Separación estricta de capas lógicas.
- Inclusión de paginación, búsqueda y filtros en los listados.
- Establecimiento de trazabilidad mediante work items y commits convencionales.
El proyecto debe conservar una estructura modular con las siguientes carpetas:
- config: configuraciones generales.
- controller: controladores REST y MVC.
- dto: objetos de transferencia de datos.
- exception: manejo de errores.
- model: entidades JPA.
- repository: interfaces de acceso a datos.
- service: lógica de negocio.
- templates: vistas Thymeleaf y fragmentos reutilizables.
El sistema distinguirá tres tipos de usuarios: USER, TECH y ADMIN. No se usará un sistema de autenticación real; las acciones estarán controladas por validaciones explícitas en la capa de servicio y controlador, en función del rol o contexto proporcionado.
USER
- Crear solicitud de reparación.
- Consultar únicamente sus órdenes.
- Cancelar órdenes propias si están en estado PENDING.
TECH
- Ver órdenes asignadas.
- Cambiar estado a IN_PROGRESS, READY o DELIVERED.
- Agregar notas técnicas.
ADMIN
- Consultar todas las órdenes.
- Asignar técnicos.
- Administrar dispositivos y usuarios.
- User: id, username, password, role, fullName, email, enabled.
- Device: id, brand, model, serialNumber.
- RepairOrder: id, customer, device, issueDescription, status, assignedTech, createdAt, updatedAt, techNotes.
- Registro histórico de cambios de estado por orden.
- Búsqueda por nombre de usuario, marca o modelo del dispositivo y rango de fechas.
- Paginación y ordenamiento en los listados.
- Eliminación lógica (soft delete) visible solo para ADMIN.
- Exportación de órdenes en formato CSV con filtros aplicados.
- Registro de notas internas para cada orden, visibles por TECH y ADMIN.
- Posibilidad de adjuntar metadatos de archivos relacionados con la orden.
-
Creación de orden (USER)
- El campo issueDescription debe tener longitud mínima válida.
- El device debe existir.
- Estado inicial: PENDING.
-
Asignación de técnico (ADMIN)
- Solo posible si la orden no está DELIVERED o CANCELED.
- Se registra un movimiento en el historial.
-
Cambio de estado (TECH o ADMIN)
- Transiciones válidas:
PENDING → IN_PROGRESS → READY → DELIVERED. - Cancelación disponible para ADMIN o USER si es su orden y está en PENDING.
- Cada cambio se registra en el historial con fecha y nota.
- Transiciones válidas:
-
Eliminación
- USER puede cancelar sus órdenes PENDING.
- ADMIN puede aplicar eliminación lógica para ocultar registros.
-
Visibilidad
- USER ve solo sus órdenes.
- TECH ve las asignadas.
- ADMIN ve todas.
-
Administración de catálogo
- Alta, baja y modificación de devices y users con validaciones.
-
Rutas base:
/api/**. -
Respuestas estándar:
- Éxito: datos en DTO.
- Error de validación:
"error": "Validation failed"con detalle de campos. - Error de acceso:
"error": "Forbidden". - No encontrado:
"error": "Not found". - Conflicto o regla inválida:
"error": "Conflict".
-
Filtros y paginación aplicables a listados por estado, texto o fechas.
-
Login (simulado): formulario que permite seleccionar o identificar el rol de usuario.
-
Dashboard:
- USER: formulario de creación y listado de órdenes personales.
- TECH: listado de órdenes asignadas con acciones de actualización.
- ADMIN: listado completo con asignaciones, filtros, gestión de devices y users, y exportación CSV.
-
Detalle de orden: historial, notas y adjuntos.
-
Catálogos: gestión de usuarios y dispositivos con validaciones y paginación.
- Validaciones de datos: longitud mínima, unicidad, obligatoriedad.
- Mensajes de error claros y consistentes.
- Estructura única de error para todo el sistema.
- Campos automáticos de creación y actualización en las entidades principales.
- Historial de estados vinculado a cada orden.
- Asociación de commits con identificadores de trabajo.
- Servicio: validación de creación, asignación, cambios de estado, cancelaciones y eliminación.
- Repositorio: consultas por usuario, técnico, estado y rango de fechas.
- Controlador (opcional): verificación de respuestas y códigos.
- Proyecto funcional con persistencia en MySQL y estructura por capas.
- Vistas Thymeleaf operativas para cada tipo de usuario.
- API REST con DTOs y formato de respuesta unificado.
- Reglas de negocio implementadas en la capa de servicio.
- Auditoría y registro histórico de estados.
- Paginación, búsqueda y exportación CSV disponibles.
- Documentación mínima en README con explicación de roles y flujo validado.
- Commits con convención establecida y trazabilidad.
- Persistencia operativa con MySQL y entidades funcionales.
- Roles gestionados por validaciones explícitas.
- Reglas de negocio y transiciones correctamente aplicadas.
- Listados con filtros, búsqueda y paginación.
- API coherente en formato y manejo de errores.
- Registro correcto del historial de estados y auditoría.
- Funcionalidad de exportación para ADMIN.
- Commits asociados a tareas y con formato convencional.
Formato general:
tipo(scope): descripción breve #ID-WorkItem
Tipos recomendados:
feat, fix, refactor, test, docs, chore.
- No se utiliza Spring Security ni autenticación real.
- Los permisos se gestionan mediante validaciones en la lógica del negocio.
- El proyecto debe mantener consistencia en inglés en nombres, rutas y estructuras.