update
This commit is contained in:
parent
3d9b2d9bb3
commit
37da6197f9
31
.gitignore
vendored
31
.gitignore
vendored
@ -5,11 +5,18 @@
|
|||||||
/tmp
|
/tmp
|
||||||
/out-tsc
|
/out-tsc
|
||||||
/bazel-out
|
/bazel-out
|
||||||
|
/build
|
||||||
|
backend/dist
|
||||||
|
backend/build
|
||||||
|
|
||||||
# Node
|
# Node
|
||||||
/node_modules
|
/node_modules
|
||||||
|
backend/node_modules
|
||||||
npm-debug.log
|
npm-debug.log
|
||||||
yarn-error.log
|
yarn-error.log
|
||||||
|
pnpm-debug.log*
|
||||||
|
yarn-debug.log*
|
||||||
|
lerna-debug.log*
|
||||||
|
|
||||||
# IDEs and editors
|
# IDEs and editors
|
||||||
.idea/
|
.idea/
|
||||||
@ -33,9 +40,13 @@ yarn-error.log
|
|||||||
.sass-cache/
|
.sass-cache/
|
||||||
/connect.lock
|
/connect.lock
|
||||||
/coverage
|
/coverage
|
||||||
|
backend/coverage
|
||||||
|
backend/.nyc_output
|
||||||
/libpeerconnection.log
|
/libpeerconnection.log
|
||||||
testem.log
|
testem.log
|
||||||
/typings
|
/typings
|
||||||
|
.temp
|
||||||
|
.tmp
|
||||||
|
|
||||||
# System files
|
# System files
|
||||||
.DS_Store
|
.DS_Store
|
||||||
@ -43,4 +54,22 @@ Thumbs.db
|
|||||||
.sonarlint
|
.sonarlint
|
||||||
.vscode
|
.vscode
|
||||||
.scannerwork
|
.scannerwork
|
||||||
package-lock.json
|
package-lock.json
|
||||||
|
backend/package-lock.json
|
||||||
|
**/.claude/settings.local.json
|
||||||
|
|
||||||
|
# Environment variables
|
||||||
|
.env
|
||||||
|
.env.development.local
|
||||||
|
.env.test.local
|
||||||
|
.env.production.local
|
||||||
|
.env.local
|
||||||
|
|
||||||
|
# Runtime data
|
||||||
|
pids
|
||||||
|
*.pid
|
||||||
|
*.seed
|
||||||
|
*.pid.lock
|
||||||
|
|
||||||
|
# Diagnostic reports
|
||||||
|
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
|
||||||
276
HU - definiciones(1).txt
Normal file
276
HU - definiciones(1).txt
Normal file
@ -0,0 +1,276 @@
|
|||||||
|
*********************************************************************
|
||||||
|
EP01 – Ingresar al Sistema
|
||||||
|
El objetivo es comprobar la autenticidad del usuario. Los usuarios serán los analistas técnicos de la unidad de concesiones, la jefatura de dicha unidad y un usuario de la Unidad de Información.
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP01.HU01 – Implementar servicio validación de usuario
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO crear un servicio que valide usuario
|
||||||
|
PARA Permitir acceder al sistema
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- Debe recibir como parametros USUARIO (correo electronico) y CONTRASEÑA.
|
||||||
|
- Debe validar formato correo electronico.
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/login).
|
||||||
|
- El servicio debe conectarse a una fuente de datos (LDAP).
|
||||||
|
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||||
|
- La respuesta debe entregar el ROL del usuario validado dentro del sistema.
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP01.HU02 – Autenticar usuario
|
||||||
|
COMO Usuario
|
||||||
|
QUIERO Ingresar mi correo electronico institucional y mi contraseña en un formulario de acceso
|
||||||
|
PARA Que el sistema valide mi identidad y me permita acceder a mi cuenta personal de manera segura.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
1. Debe existir un formulario con campos obligatorios de usuario y contraseña.
|
||||||
|
2. El sistema debe validar que ninguno de los campos esté vacío.
|
||||||
|
3. Si el usuario o la contraseña son incorrectos, se mostrará un mensaje de error (por definir)
|
||||||
|
4. Si las credenciales son válidas, el usuario será redirigido al panel principal del sistema.
|
||||||
|
5. Si las credenciales son válidas, el sistema deberá desplegar las opciones de MENÚ habiltadas para el ROL del usuario logueado.
|
||||||
|
*********************************************************************
|
||||||
|
EP02 – Pantalla de Usuario Administrador Unidad de Concesiones
|
||||||
|
El objetivo es mostrar de forma consolidada las cargas temporales del PR047, para que un usuario administrador asigne cronogramas a los analistas y se notifique. Además, que permita realizar solicitud de carga a la Unidad de Información y notifique a la empresa.
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU01. Implementar servicio asignación de cronograma
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que asigne cronogramas
|
||||||
|
PARA Perimtir asignar cronogramas a un analista.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- Debe recibir como parametros el identificador del cronograma y del analista.
|
||||||
|
- Debe generar los registros que sean necesarios en la base de datos.
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/cronogramas/asignar).
|
||||||
|
- El servicio debe conectarse a la fuente de datos correspondiente (base de datos, API externa, etc.).
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU02. Implementar servicio de solicitudes de carga
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que solicite la carga de ¿cronogramas?
|
||||||
|
PARA Perimtir solicitar la carga de nuevos ¿cronogramas? a la unidad de información.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- Debe recibir como parametros el identificador del ¿cronograma? que se desea cargar.
|
||||||
|
- Debe generar los registros que sean necesarios en la base de datos.
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/cronogramas/solicitudcarga).
|
||||||
|
- El servicio debe conectarse a la fuente de datos correspondiente (base de datos, API externa, etc.).
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU03. Cargar cronogramas
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU04. Implementar filtros
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU05. Asignar cronograma
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU06. Implementar semaforo
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU07. Solicitar carga de cronogramas
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP02.HU08. Notificar a Unidad de Información
|
||||||
|
*********************************************************************
|
||||||
|
EP03 – Vista de Carga de Cronograma Temporal por Actualización de PD
|
||||||
|
El objetivo es desplegar la carga temporal de los cronogramas de actualización de PD o nuevas concesiones para cada analista, aprobar o rechazar la carga, añadir comentarios generales y/o por cada glosa, notificar a la empresa cuando se rechace la carga y exportar los datos a un archivo pdf.
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU01. Implementar servicio de gestión de glosas (aprobación/rechazo)
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU02. Implementar servicio para exportar datos a Excel
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU03. Cargar cronogramas
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU04. Implementar filtros
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU05. Aprobar carga
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU06. Rechazar carga
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU07. Ingresar observación
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU08. Exportar a Excel
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP03.HU09. Notificar a empresa
|
||||||
|
*********************************************************************
|
||||||
|
EP04 – Vista de Carga de Cronograma Temporal por Ajuste de PD
|
||||||
|
EP04.01. Implementar servicio para obtener listado de ajustes y amplicaciones
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU02. Cargar cronogramas
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU03. Cargar ajustes PD y ampliación TO
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU04. Implementar filtros
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU05. Ingresar observación
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU06. Aprobar carga
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU07. Rechazar carga
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU08. Exportar a Excel
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU09. Exportar a PDF
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP04.HU10. Notificar a empresa
|
||||||
|
*********************************************************************
|
||||||
|
EP05 – Vista de Resumen
|
||||||
|
EP05.HU01. Implementar switch vistas
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP05.HU02. Cargar cronogramas aprobados
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP05.HU03. Cargar cronogramas rechazados
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP05.HU04. Implementar filtros
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP05.HU05. Generar PDF para firma digital (x2)
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP05.HU06. Notificar a empresa
|
||||||
|
*********************************************************************
|
||||||
|
EP06 – Vista para Usuario de Unidad de Información
|
||||||
|
EP06.HU01. Cargar cronogramas pendientes de carga
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP06.HU02. Cargar cronogramas aprobados
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP06.HU03. Cargar cronogramas rechazados
|
||||||
|
*********************************************************************
|
||||||
|
EP07. Servicios transversales
|
||||||
|
EP07.HU01. Implementar servicio listado de cronogramas por estado
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que devuelva una lista de cronogramas por estado
|
||||||
|
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- El servicio debe retornar todos los registros
|
||||||
|
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/cronogramas/listado).
|
||||||
|
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||||
|
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||||
|
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||||
|
- Debe permitir filtros opcionales mediante parámetros (por ejemplo, 'estado').
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP07.HU02. Implementar servicio listado empresas
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que devuelva una lista de empresas
|
||||||
|
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- El servicio debe retornar todos los registros
|
||||||
|
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /empresas).
|
||||||
|
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||||
|
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||||
|
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||||
|
- Debe permitir filtros opcionales mediante parámetros (por ejemplo, 'estado').
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP07.HU03. Implementar servicio listado ajustes PD
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que devuelva una lista de ajustes de PD
|
||||||
|
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- El servicio debe retornar todos los registros
|
||||||
|
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /ajustespd).
|
||||||
|
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||||
|
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||||
|
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP07.HU04. Implementar servicio listado ampliación TO
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que devuelva una lista de ampliación de TO
|
||||||
|
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- El servicio debe retornar todos los registros
|
||||||
|
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||||
|
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /ampliacionto).
|
||||||
|
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||||
|
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||||
|
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||||
|
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||||
|
- Los errores además, deben presentar mensajes descriptivos.
|
||||||
|
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||||
|
- Aplicar principios de clean code y separación de responsabilidades.
|
||||||
|
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
EP07.HU05. Implementar servicio notificaciones
|
||||||
|
COMO Desarrollador
|
||||||
|
QUIERO Crear un servicio que envie correos electronicos
|
||||||
|
PARA Notificar a quien corresponda respecto de alertas o confirmaciones.
|
||||||
|
|
||||||
|
CRITERIOS DE ACEPTACIÓN
|
||||||
|
- El servicio debe aceptar al menos los siguientes parámetros:
|
||||||
|
- Destinatario(s)
|
||||||
|
- Asunto
|
||||||
|
- Cuerpo del mensaje (HTML o texto plano)
|
||||||
|
- Remitente (opcional, configurable)
|
||||||
|
- Debe realizar validaciones básicas (formato de email, campos requeridos).
|
||||||
|
- Debe manejar errores como correos inválidos, errores de red, o problemas con el servidor SMTP.
|
||||||
|
- El servicio debe retornar respuestas con códigos HTTP claros (200, 400, 500, etc.).
|
||||||
|
- El envío debe ser asincrónico si se anticipa alto volumen (opcional).
|
||||||
|
- Debe registrar los envíos en logs o base de datos (para trazabilidad, opcional).
|
||||||
|
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
*********************************************************************
|
||||||
|
|
||||||
|
generar epica de servicios transversales
|
||||||
|
por cada HU generar su propio exportar a excel
|
||||||
|
generar servicio por cada pdf a generar
|
||||||
|
no incluir botonera de switch de vistas
|
||||||
|
generar matriz de autorizaciones (perfil, pantalla)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### ✅ **Criterios de Aceptación:**
|
||||||
|
|
||||||
|
- Se debe crear un endpoint (por ejemplo, `POST /api/email/send`) que reciba los datos del correo.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🔁 **Flujo Básico de Desarrollo:**
|
||||||
|
|
||||||
|
1. Diseñar el endpoint REST (por ejemplo, en .NET, Node.js, Spring Boot).
|
||||||
|
2. Configurar un proveedor de correo (SMTP, SendGrid, Mailgun, etc.).
|
||||||
|
3. Implementar la lógica de envío y validación.
|
||||||
|
4. Manejar errores y respuestas.
|
||||||
|
5. Agregar logs y/o almacenamiento de eventos.
|
||||||
|
6. Probar con diferentes escenarios y correos de prueba.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 🛠️ **Notas Técnicas:**
|
||||||
|
|
||||||
|
- Se recomienda usar una biblioteca estándar de envío de correo según el lenguaje (ej. Nodemailer en Node.js, MailKit en .NET, JavaMail en Java).
|
||||||
|
- Usar plantillas de email si se requiere formato HTML.
|
||||||
|
- Considerar seguridad: autenticación con el proveedor, evitar inyecciones, validar origen de llamadas.
|
||||||
|
- Considerar colas de mensajes si se requiere alta disponibilidad (ej. RabbitMQ, Azure Service Bus).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
¿Te gustaría que prepare una versión adaptada para .NET Core, Node.js o algún otro stack específico?
|
||||||
BIN
Requerimientos_vista PR047.docx
Normal file
BIN
Requerimientos_vista PR047.docx
Normal file
Binary file not shown.
Loading…
x
Reference in New Issue
Block a user