Notas de la versión — WUIC Framework v1.7.27

Fecha: 14 de octubre de 2026 Versión anterior publicada: 1.7.26 (13 de octubre de 2026) Backend: .NET 10 + IIS / Linux nginx Frontend: Angular 21

La 1.7.27 corrige una regresión de la 1.7.26 en los filtros between con fecha y hora, hace que las fechas escritas por insert y update no dependan de la cultura del servidor y completa la alineación de MySQL, PostgreSQL y Oracle con SQL Server. En resumen:

• filtro between con extremos ISO que incluyen la hora de nuevo operativo en SQL Server, PostgreSQL y Oracle con un servidor en italiano;
• cambio visible para los clientes de las API: una fecha enviada como texto no ISO 8601 a insert/update responde 400 errors.input.date_not_iso;
• operación deshabilitada en la ruta: 403 errors.auth.operation_disabled en lugar de 400, en las cuatro bases de datos;
• correcciones de los providers MySQL, PostgreSQL y Oracle (grupos de filtros anidados, filtros sobre columnas no seleccionadas, pivot, valores distintos, vistas del pivot);
• export en segundo plano con progreso también en MySQL, PostgreSQL y Oracle.

Dónde se ha verificado: tests unitarios y tests con base de datos real en SQL Server, MySQL, PostgreSQL y Oracle; tests end-to-end de la documentación en las cuatro bases para los filtros de la grilla y del pivot, el pivot builder, el export en segundo plano y la cola de exports (sobre una tabla de 230.000 filas) y para los seis tests que guardan fechas (editor de fecha, asistente, timeline, concurrencia optimista, import).

🐛 Regresión de la 1.7.26: between con fecha y hora

Con un servidor en italiano, un filtro between con extremos ISO que incluían la hora (2015-12-31T23:59:59) se releía en el formato del servidor: en SQL Server el filtro daba un error de conversión, en PostgreSQL y Oracle un error de formato o día y mes invertidos. Los extremos se mantienen ahora en ISO invariante; los extremos con solo la fecha ya eran correctos.

🚦 Fechas en insert y update: solo ISO 8601 (cambio visible para los clientes de las API)

• Texto no ISO = 400. Una fecha que llega como texto a insertRecord, updateRecord, batchRecord, clone u OData debe ser ISO 8601: 2026-10-13, 2026-10-13T14:30:00 o 2026-10-13 14:30:00, con segundos, fracciones, Z o desfase opcionales. Si no, la respuesta es HTTP 400 errors.input.date_not_iso con args.column y args.value. Antes el texto se leía en la cultura del servidor: 05/10/2026 era el 5 de octubre en un servidor italiano y el 10 de mayo en uno estadounidense, y un texto ilegible daba 500.
• Jobs del scheduler. La misma regla vale para los params_values escritos a mano de los jobs que ejecutan insert o update: las fechas deben escribirse en ISO.
• Texto con Z. Mantiene la misma hora en UTC en todas las bases, como una fecha del JSON; antes, vía batchRecord, SQL Server y MySQL la convertían a la hora local del servidor.
• Fechas de logging en la respuesta. La fecha de inserción, modificación o eliminación devuelta en la entity está en ISO (yyyy-MM-ddTHH:mm:ss) y, reenviada en un update, se acepta. Verificado con base de datos real en SQL Server, MySQL y PostgreSQL; en Oracle con los tests unitarios.
• Import de archivos. Las fechas en el formato local de la cultura del servidor se siguen leyendo; una celda ilegible hace fallar la fila con errors.input.date_not_iso.
• Literales SQL. Las fechas escritas en el SQL de insert y update usan la cultura invariante en todas las bases: con una cultura de calendario budista (th-TH) el año salía 2569.

Defectos corregidos con este trabajo:

• PostgreSQL y Oracle, día y mes invertidos. Con un servidor en italiano, una fecha guardada desde el formulario como el 12/10/2026 se escribía como el 10/12/2026.
• Guardado batch de la grilla y de la hoja. Una fecha a medianoche se enviaba en UTC y llegaba como el día anterior; ahora se envía como en el guardado de un solo registro.
• Hoja. Una fecha pegada o arrastrada en una celda de fecha se convierte a ISO con el formato del idioma actual.

🔐 Operación deshabilitada: 403

Insert, update, delete o restauración en una ruta que tiene esa operación deshabilitada responden HTTP 403 errors.auth.operation_disabled (con la ruta) en SQL Server, MySQL, PostgreSQL y Oracle; antes la respuesta era 400 errors.validation.failed en las cuatro.

🗄️ MySQL, PostgreSQL y Oracle

• Grupos de filtros anidados. En PostgreSQL y Oracle un grupo dentro del filtro (desde "Pregunta a los datos" o el filtro avanzado de la grilla) no se aplicaba y la lista devolvía filas de más. Un subgrupo dentro de un grupo funciona en todas las bases: en SQL Server repetía el grupo, en MySQL daba un error de sintaxis.
• Filtros sobre columnas no seleccionadas. En PostgreSQL y Oracle un filtro sobre una columna de la tabla no pedida por la lista (columnas ocultadas por el usuario, export, "Pregunta a los datos") se ignoraba en silencio; ahora se aplica, como en SQL Server y MySQL.
• between en el pivot. El filtro por intervalo del pivot funciona en SQL Server, MySQL, PostgreSQL y Oracle.
• Fechas en las comparaciones. Las fechas de los filtros de la grilla y del pivot se escriben en formato ANSI/ISO independiente de la cultura del servidor (antes ORA-01858/ORA-01843 en Oracle, un error de conversión en SQL Server con un login en italiano); una fecha ilegible da un error tipado.
• Valores distintos. En Oracle funcionan también sobre columnas de texto largo (ORA-22848); en MySQL respetan DISTINCT y las restricciones de fila de la ruta.
• Vistas del pivot. scaffoldView y la vista creada por el pivot registran un md_id válido en PostgreSQL, Oracle y SQL Server (antes 0) y el job de actualización de la vista se crea también en PostgreSQL y Oracle.
• Usuarios en MySQL. La búsqueda de un usuario por id, nombre o email vuelve a leer la base si el usuario no está en caché: un usuario recién creado figuraba como inexistente (401).
• Export en segundo plano. En MySQL, PostgreSQL y Oracle el progreso del export llega al diálogo y a la cola como en SQL Server (antes saltaba de 0 a 100 %); en Oracle la lectura del progreso fallaba con ORA-00911.

📦 Paquetes actualizados

🔧 Actualizaciones operativas recomendadas

1. Clientes de las API: comprobar que insert, update, batch, clone y OData envían las fechas en ISO 8601; un formato local ahora responde 400 errors.input.date_not_iso.
2. Jobs del scheduler que ejecutan insert o update: reescribir en ISO las fechas de los params_values.
3. Gestión de errores: el código que interceptaba el 400 de una operación deshabilitada debe gestionar el 403 errors.auth.operation_disabled.
4. Traducciones: la clave errors.input.date_not_iso (cinco idiomas) está en los scripts de primer arranque y también se añade al arrancar a las bases existentes.