Actualización Be Aware 360 - Release Notes - Abril 2026

Tipo de actualización: Despliegue Programado

Versiones Generadas (Fecha Liberación):

• 1.231_4 (13/04/2026)

Última Versión Liberada Abril: : 1.231_4

[1.231_4] Se corrigió un defecto en el cual el estado del usuario permanecía como “Disponible” en la base de datos cuando la sesión finalizaba de forma no intencional, ya sea por expiración del token, invalidación de credenciales o finalización forzada de sesión desde el backend.

Anteriormente, el sistema solo actualizaba el estado a “Desconectado” cuando el usuario ejecutaba la acción de cierre de sesión de forma explícita. Esta inconsistencia provocaba que el motor de asignación de casos considerara al usuario como disponible, generando asignaciones incorrectas y discrepancias entre el estado real y el registrado.

Con esta corrección, se implementó un mecanismo de limpieza automática que detecta sesiones finalizadas de forma no explícita y actualiza el estado del usuario a “Desconectado” de manera consistente.

Para mayor información sobre Conceptos hacer clic aquí

[1.231_4] Se corrigió un defecto en el módulo de Casos donde los permisos de Chequeo (Checklist) no tenían efecto funcional. La pestaña de Chequeo se mostraba independientemente de los permisos configurados para el rol del usuario.

Con esta corrección, la visibilidad y las acciones sobre el Chequeo de casos ahora respetan los permisos asignados:

Nota: Para que la pestaña sea visible, el usuario debe poseer al menos el permiso checklist.listar o checklist.ver, y además deben existir tareas asociadas al caso.

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

[1.231_4] Se corrigió un defecto en el cual la parametrización general EDICION_CASO_CERRADO_DATOS_CFS permitía la edición de casos cerrados incluso cuando el usuario no contaba con permisos de modificación en su rol. Esto generaba una sobrescritura indebida de los permisos del rol.

Con esta corrección, se ajustó la lógica de validación para que los permisos del usuario tengan prioridad sobre la parametrización general:

1. Si el usuario no posee permiso de modificar, no puede editar el caso independientemente del valor del parámetro.
2. Si el usuario posee permiso de modificar y el caso está abierto, puede editar normalmente.
3. Si el usuario posee permiso de modificar y el caso está cerrado, la edición depende del valor del parámetro de configuración.

Nota: Este ajuste también aplica al bloqueo de edición de notas en casos cerrados, garantizando consistencia en el comportamiento de permisos.

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

[1.231_4] Se corrigió un defecto en el cual la configuración de permisos por rol y proceso para las Vistas 360 funcionaba correctamente en la consola de Be Aware 360, pero no se respetaba al acceder desde Sistemas Externos.

Con esta corrección, se ajustó la lógica de carga y visualización de las Vistas 360 en Sistemas Externos para que aplique el mismo filtrado que la consola, considerando el rol del usuario autenticado (rol principal y roles asociados) y el proceso (workflow) del caso en curso. De esta manera, las Vistas 360 solo se muestran cuando el usuario posee los permisos correspondientes y el caso pertenece a un proceso habilitado.

Para obtener más información sobre integración con sistemas externos, haga clic aquí.

[1.231_4] Se corrigió un defecto en el cual al adjuntar un archivo marcado como privado a un caso, la nota automática generada por el sistema indicaba incorrectamente que el archivo era público.

El problema se originaba en el backend, donde el código encargado de asignar la privacidad a la nota automática se encontraba comentado y además contenía un error en el nombre de la propiedad utilizada. Con esta corrección, al cargar un archivo privado, la nota asociada se crea correctamente como mensaje privado, y al cargar un archivo público, la nota se crea como mensaje público.

Para obtener más información sobre adjuntar archivos a un caso, haga clic aquí.

[1.231_4] Se corrigió un defecto que impedía la creación de nuevos usuarios en Be Aware 360. Los usuarios reportaban que el proceso de creación no se completaba correctamente, bloqueando la operación de administración de la plataforma.

Para obtener más información sobre gestión de usuarios, haga clic aquí.

[1.231_4] Se realizó una optimización en los tiempos de carga al recargar un caso, especialmente durante la ejecución de scripts HTML. Anteriormente, la recarga del caso tras la ejecución de un script invocaba la recarga de todos los catálogos globales (roles, grupos, acuerdos, prioridades, sistemas externos, archivos custom), lo cual era innecesario ya que estos datos no cambian como resultado de la ejecución de un script.

.

[1.231_4] Se implementó una validación en el proceso de carga de archivos adjuntos a casos para que, cuando se intente subir un archivo que exceda el límite permitido de 12.5 MB, el sistema retorne un mensaje claro indicando que el archivo no pudo ser adjuntado por superar el tamaño máximo.

Anteriormente, al intentar adjuntar un archivo mayor al límite permitido a través de la API, el sistema retornaba un código HTTP 200 con estado “NO OK” sin proporcionar información sobre la causa del rechazo.

Nota: Para archivos mayores a 200 MB, el servidor puede descartar la solicitud antes de que la validación se ejecute. Se recomienda implementar validación de tamaño en el cliente previo al envío .

[1.225_0]

• Componente Icono: se dispone de un catalogo de iconos para utilizar en las pantallas asociados al nuevo componente “Icono” en la sección de predefinidos.
• Paleta de Colores: En el contexto del módulo de proyectos, la configuración del proyecto presenta un apartado de estilos donde por el momento se pueden guardar colores asociados al proyecto, estos colores que se carguen aquí van a aparecer para ser seleccionables en las configuraciones de color de los componentes.

[1.223_0]

• Integración de workflows en el módulo de proyectos
• Backup en el historial de versiones, de hasta tres pantallas, de EB con posibilidad de restaurarlas.
• Se soluciona: Cuando el nombre del script tiene guiones, no funciona la sintaxis que actualiza otro componente al llamarlo en un evento ej: nombre-script(datakey). Recibir siempre en el payload de scripts nombre de pantalla, para hacer diferenciaciones si se reutiliza script
• Se reciben datos de elementos adjuntos en el payload del evento onclick
• Se soluciona la configuración de campo requerido para componente datetime

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