Tareas #5014
Updated by Daniel García 15 days ago
Se han detectado múltiples incidencias funcionales en los módulos de *Entidades* y *Programas* relacionadas con validaciones incorrectas, comportamiento de formularios y limitaciones en buscadores. Se requiere su revisión y corrección para asegurar coherencia funcional y usabilidad.
h3. Requisitos funcionales:
*Entidades – Otros datos / Cuentas bancarias*
- Corregir validación al añadir una nueva cuenta bancaria:
- Actualmente muestra error *“no hay datos cuenta bancaria que validar”* incluso cuando se ha introducido una cuenta válida.
- La validación debe ejecutarse únicamente cuando existan datos informados y debe reconocer correctamente los campos introducidos.
- Los *contactos* no deben requerir cuentas bancarias:
- Eliminar el bloque o campos de cuenta bancaria del formulario cuando la modalidad sea *Contacto*.
*Entidades – Buscador de contactos*
- Permitir búsqueda de contactos por *correo electrónico* además de nombre/apellidos.
- En el modal se deben quitar las columnas de tipo identifacion y la de identificación y se debe añadir la de Email.
- La búsqueda debe funcionar tanto con email principal como secundario si existe.
*Entidades – Cliente*
- Habilitar el campo de selección de *tipo de empresa* en entidades cliente.
- Revisar por qué está deshabilitado actualmente y restaurar su funcionamiento.
*Programas – Datos generales*
- Permitir introducir valor *0* en el campo de *años* durante el alta de programa.
- Actualmente no permite este valor y debe aceptarse como válido.
- Eliminar el campo *firma del programa*:
- No tiene uso funcional.
- Actualmente está persistiendo en el campo *tarifa*, lo cual es incorrecto.
*Programas – Formularios (UX inputs)*
- Corregir comportamiento de labels en inputs:
- Actualmente, al introducir datos, desaparece el nombre del campo.
- Se debe replicar el comportamiento de *Entidades*:
- El label debe desplazarse (floating label) y seguir siendo visible tras informar el campo.
h3. Requisitos técnicos:
- Revisar lógica de validación en cuentas bancarias dentro de *Otros datos* (frontend y backend si aplica).
- Ajustar condiciones de renderizado del formulario según tipo de entidad (Contacto vs otras).
- Ampliar consultas del buscador para incluir filtros por email (LIKE o equivalente).
- Revisar bindings y estados del campo *tipo de empresa* para evitar deshabilitado no intencionado.
- Modificar validación del campo *años* para permitir valor 0 (revisar tipo numérico y constraints).
- Eliminar completamente el campo *firma*:
- Frontend (vista)
- Backend (DTO/controlador)
- Evitar persistencia errónea en *tarifa*
- Implementar o reutilizar componente de *floating label* ya usado en Entidades para inputs de Programas.
h3. Flujo esperado:
- En Entidades:
- Al añadir cuenta bancaria válida → no debe saltar error.
- En Contactos → no se muestran campos de cuenta bancaria.
- Buscador permite localizar contactos por email.
- En Programas:
- Se permite introducir 0 en años sin error.
- El campo firma no aparece ni se guarda.
- Los labels de inputs permanecen visibles tras introducir datos.
h3. Validaciones o condiciones especiales:
- No romper la validación existente de cuentas bancarias para otros tipos de entidad.
- Asegurar compatibilidad con datos ya existentes en base de datos.
- Mantener coherencia visual con el resto de formularios de la aplicación.
h3. Requisitos funcionales:
*Entidades – Otros datos / Cuentas bancarias*
- Corregir validación al añadir una nueva cuenta bancaria:
- Actualmente muestra error *“no hay datos cuenta bancaria que validar”* incluso cuando se ha introducido una cuenta válida.
- La validación debe ejecutarse únicamente cuando existan datos informados y debe reconocer correctamente los campos introducidos.
- Los *contactos* no deben requerir cuentas bancarias:
- Eliminar el bloque o campos de cuenta bancaria del formulario cuando la modalidad sea *Contacto*.
*Entidades – Buscador de contactos*
- Permitir búsqueda de contactos por *correo electrónico* además de nombre/apellidos.
- En el modal se deben quitar las columnas de tipo identifacion y la de identificación y se debe añadir la de Email.
- La búsqueda debe funcionar tanto con email principal como secundario si existe.
*Entidades – Cliente*
- Habilitar el campo de selección de *tipo de empresa* en entidades cliente.
- Revisar por qué está deshabilitado actualmente y restaurar su funcionamiento.
*Programas – Datos generales*
- Permitir introducir valor *0* en el campo de *años* durante el alta de programa.
- Actualmente no permite este valor y debe aceptarse como válido.
- Eliminar el campo *firma del programa*:
- No tiene uso funcional.
- Actualmente está persistiendo en el campo *tarifa*, lo cual es incorrecto.
*Programas – Formularios (UX inputs)*
- Corregir comportamiento de labels en inputs:
- Actualmente, al introducir datos, desaparece el nombre del campo.
- Se debe replicar el comportamiento de *Entidades*:
- El label debe desplazarse (floating label) y seguir siendo visible tras informar el campo.
h3. Requisitos técnicos:
- Revisar lógica de validación en cuentas bancarias dentro de *Otros datos* (frontend y backend si aplica).
- Ajustar condiciones de renderizado del formulario según tipo de entidad (Contacto vs otras).
- Ampliar consultas del buscador para incluir filtros por email (LIKE o equivalente).
- Revisar bindings y estados del campo *tipo de empresa* para evitar deshabilitado no intencionado.
- Modificar validación del campo *años* para permitir valor 0 (revisar tipo numérico y constraints).
- Eliminar completamente el campo *firma*:
- Frontend (vista)
- Backend (DTO/controlador)
- Evitar persistencia errónea en *tarifa*
- Implementar o reutilizar componente de *floating label* ya usado en Entidades para inputs de Programas.
h3. Flujo esperado:
- En Entidades:
- Al añadir cuenta bancaria válida → no debe saltar error.
- En Contactos → no se muestran campos de cuenta bancaria.
- Buscador permite localizar contactos por email.
- En Programas:
- Se permite introducir 0 en años sin error.
- El campo firma no aparece ni se guarda.
- Los labels de inputs permanecen visibles tras introducir datos.
h3. Validaciones o condiciones especiales:
- No romper la validación existente de cuentas bancarias para otros tipos de entidad.
- Asegurar compatibilidad con datos ya existentes en base de datos.
- Mantener coherencia visual con el resto de formularios de la aplicación.