Tipo de actualización: Despliegue Programado

Versiones Generadas (Fecha Liberación):

• 1.240_15 (3/07/2026)

Última Versión Liberada : : 1.240_15

[1.240_15] Se aplica una segunda iteración de la corrección de refresco del caso tras la ejecución de scripts. Esta iteración aborda escenarios adicionales no cubiertos por la primera corrección, garantizando que la vista del caso se actualice de forma consistente en todos los flujos de ejecución de scripts y acciones que modifican el estado del caso.

Para obtener más información sobre casos, haga clic aquí.

[1.240_15] Se corrigen tres defectos en las bandejas de “Supervisión de mis procesos” y su “Histórico”:

1. Casos no visibles en las bandejas: Algunos casos pertenecientes al proceso supervisado no aparecían en las bandejas debido a que la consulta dependía de un índice de búsqueda interno. Si un caso no tenía entrada en dicho índice, quedaba excluido de los resultados. Se corrige el mecanismo de indexación para garantizar la cobertura completa de todos los casos.

1. Histórico mostraba solo casos asignados: La bandeja de histórico filtraba exclusivamente los casos con usuario asignado, excluyendo los casos sin asignar del proceso. Se elimina esta restricción para que el histórico muestre todos los casos del proceso supervisado, independientemente de su estado de asignación.

1. Botón de limpiar búsqueda inoperante: En el panel de “casos sin asignar”, el botón de limpiar búsqueda (goma) no limpiaba el texto ingresado ni recargaba la lista. Se corrige para que el botón funcione correctamente, limpiando el filtro y recargando la vista completa.

Para obtener más información sobre casos, haga clic aquí.

[1.240_15] Se corrige un defecto donde, al cerrar un caso fijando directamente un estado de tipo “cierre” (sin recorrer los pasos del flujo de trabajo hasta la etapa de cierre), la fecha de cierre del caso quedaba con un valor incorrecto. En algunos casos, la fecha de creación resultaba mayor que la fecha de cierre.

El problema se originaba en una inconsistencia entre las dos rutas de cierre del caso: el cierre por pasos del flujo registraba correctamente el evento de finalización, mientras que el cierre por estado directo presentaba condiciones donde el evento podía no registrarse adecuadamente. Con la corrección, ambas rutas de cierre generan una fecha de finalización coherente y consistente.

Para obtener más información sobre casos, haga clic aquí.

[1.240_15] Se corrige un defecto en la integración con el gestor documental externo (ECM) donde el sistema no enviaba correctamente la información del usuario en las solicitudes de autenticación con los nuevos tokens de seguridad. Esta corrección garantiza la compatibilidad con el esquema de autenticación actualizado del gestor documental.

Para obtener más información sobre integraciones, haga clic aquí.

[1.240_15] Se implementa la segunda fase de optimización de rendimiento para instancias con gran cantidad de campos personalizados configurados (1.000+). Tras la primera fase que redujo el tiempo de guardado del caso de aproximadamente 3 minutos a menos de 2 segundos, esta segunda fase aborda el tiempo de presentación del caso, que permanecía en aproximadamente 40 segundos.

Las mejoras incluyen:

1. Backend: Reescritura del endpoint de obtención de definiciones de campos personalizados para utilizar el caché en memoria en lugar de consultas individuales a la base de datos, reduciendo de aproximadamente 1.000 consultas a menos de 10 por apertura de caso.

1. Frontend: Optimización del componente de campos personalizados mediante la eliminación de recálculos O(N²) en los computados, paralelización de las cargas de opciones de listas, pre-agrupación de opciones por campo, y debounce de los watchers que disparan recargas.

El resultado esperado es una reducción del tiempo de presentación del caso desde aproximadamente 40 segundos hasta menos de 2 segundos en el percentil 95.

Para obtener más información sobre casos, haga clic aquí.

[1.240_15] Se optimiza el manejo de logs en el filtro de autorización del backend para reducir el volumen de entradas de error generadas por solicitudes con formato de URL no esperado. Anteriormente, cada solicitud con una ruta que no cumplía el formato esperado (como rutas con menos segmentos de los requeridos) generaba una entrada de nivel ERROR con el stack trace completo, lo que saturaba los logs e impedía la identificación de errores reales.

Con la corrección, las solicitudes con formato no esperado se registran a nivel WARN con información contextual (URI, compañía, usuario) en una sola línea, sin stack trace. Las excepciones genuinamente inesperadas mantienen el nivel ERROR con traza completa. Adicionalmente, se implementa validación defensiva en el parseo de URL y del header de autorización para evitar excepciones por acceso fuera de rango.

Para obtener más información sobre la plataforma, haga clic aquí.