Notes de version — WUIC Framework v1.7.27

Date : 14 octobre 2026 Version précédente publiée : 1.7.26 (13 octobre 2026) Backend : .NET 10 + IIS / Linux nginx Frontend : Angular 21

La 1.7.27 corrige une régression de la 1.7.26 sur les filtres between avec date et heure, rend les dates écrites par insert et update indépendantes de la culture du serveur et complète l'alignement de MySQL, PostgreSQL et Oracle sur SQL Server. En résumé :

• filtre between avec des bornes ISO comprenant l'heure de nouveau fonctionnel sur SQL Server, PostgreSQL et Oracle avec un serveur en italien ;
• changement visible pour les clients des API : une date envoyée en texte non ISO 8601 à insert/update répond 400 errors.input.date_not_iso ;
• opération désactivée sur la route : 403 errors.auth.operation_disabled au lieu de 400, sur les quatre bases de données ;
• corrections des providers MySQL, PostgreSQL et Oracle (groupes de filtres imbriqués, filtres sur des colonnes non sélectionnées, pivot, valeurs distinctes, vues du pivot) ;
• export en arrière-plan avec progression également sur MySQL, PostgreSQL et Oracle.

Où cela a été vérifié : tests unitaires et tests avec une base de données réelle sur SQL Server, MySQL, PostgreSQL et Oracle ; tests end-to-end de la documentation sur les quatre bases pour les filtres de la grille et du pivot, le pivot builder, l'export en arrière-plan et la file des exports (sur une table de 230 000 lignes) et pour les six tests qui enregistrent des dates (éditeur de date, assistant, timeline, concurrence optimiste, import).

🐛 Régression de la 1.7.26 : between avec date et heure

Avec un serveur en italien, un filtre between avec des bornes ISO comprenant l'heure (2015-12-31T23:59:59) était relu dans le format du serveur : sur SQL Server le filtre donnait une erreur de conversion, sur PostgreSQL et Oracle une erreur de format ou le jour et le mois inversés. Les bornes restent désormais en ISO invariant ; les bornes avec la seule date étaient déjà correctes.

🚦 Dates dans insert et update : ISO 8601 uniquement (changement visible pour les clients des API)

• Texte non ISO = 400. Une date qui arrive en texte à insertRecord, updateRecord, batchRecord, clone ou OData doit être en ISO 8601 : 2026-10-13, 2026-10-13T14:30:00 ou 2026-10-13 14:30:00, avec secondes, fractions, Z ou décalage facultatifs. Sinon la réponse est HTTP 400 errors.input.date_not_iso avec args.column et args.value. Auparavant le texte était lu dans la culture du serveur : 05/10/2026 était le 5 octobre sur un serveur italien et le 10 mai sur un serveur américain, et un texte illisible donnait 500.
• Jobs du scheduler. La même règle vaut pour les params_values écrits à la main des jobs qui exécutent insert ou update : les dates doivent être écrites en ISO.
• Texte avec Z. Il conserve la même heure en UTC sur toutes les bases, comme une date du JSON ; auparavant, via batchRecord, SQL Server et MySQL la convertissaient dans l'heure locale du serveur.
• Dates de journalisation dans la réponse. La date d'insertion, de modification ou de suppression renvoyée dans l'entity est en ISO (yyyy-MM-ddTHH:mm:ss) et, renvoyée dans un update, elle est acceptée. Vérifié avec une base réelle sur SQL Server, MySQL et PostgreSQL ; sur Oracle avec les tests unitaires.
• Import de fichiers. Les dates au format local de la culture du serveur continuent d'être lues ; une cellule illisible fait échouer la ligne avec errors.input.date_not_iso.
• Littéraux SQL. Les dates écrites dans le SQL d'insert et d'update sont en culture invariante sur toutes les bases : avec une culture à calendrier bouddhiste (th-TH) l'année sortait 2569.

Défauts corrigés par ce travail :

• PostgreSQL et Oracle, jour et mois inversés. Avec un serveur en italien, une date enregistrée depuis le formulaire comme le 12/10/2026 était écrite comme le 10/12/2026.
• Enregistrement batch de la grille et de la feuille. Une date à minuit était envoyée en UTC et arrivait comme le jour précédent ; elle est désormais envoyée comme dans l'enregistrement d'un seul record.
• Feuille. Une date collée ou glissée dans une cellule date est convertie en ISO avec le format de la langue courante.

🔐 Opération désactivée : 403

Insert, update, delete ou restauration sur une route où cette opération est désactivée répondent HTTP 403 errors.auth.operation_disabled (avec la route) sur SQL Server, MySQL, PostgreSQL et Oracle ; auparavant la réponse était 400 errors.validation.failed sur les quatre.

🗄️ MySQL, PostgreSQL et Oracle

• Groupes de filtres imbriqués. Sur PostgreSQL et Oracle un groupe à l'intérieur du filtre (depuis « Interroger les données » ou le filtre avancé de la grille) n'était pas appliqué et la liste renvoyait des lignes en trop. Un sous-groupe à l'intérieur d'un groupe fonctionne sur toutes les bases : sur SQL Server il répétait le groupe, sur MySQL il donnait une erreur de syntaxe.
• Filtres sur des colonnes non sélectionnées. Sur PostgreSQL et Oracle un filtre sur une colonne de la table non demandée par la liste (colonnes masquées par l'utilisateur, export, « Interroger les données ») était ignoré en silence ; il s'applique désormais, comme sur SQL Server et MySQL.
• between dans le pivot. Le filtre par intervalle du pivot fonctionne sur SQL Server, MySQL, PostgreSQL et Oracle.
• Dates dans les comparaisons. Les dates des filtres de la grille et du pivot sont écrites au format ANSI/ISO indépendant de la culture du serveur (auparavant ORA-01858/ORA-01843 sur Oracle, une erreur de conversion sur SQL Server avec un login en italien) ; une date illisible donne une erreur typée.
• Valeurs distinctes. Sur Oracle elles fonctionnent aussi sur les colonnes de texte long (ORA-22848) ; sur MySQL elles respectent DISTINCT et les contraintes de ligne de la route.
• Vues du pivot. scaffoldView et la vue créée par le pivot enregistrent un md_id valide sur PostgreSQL, Oracle et SQL Server (auparavant 0) et le job de mise à jour de la vue est aussi créé sur PostgreSQL et Oracle.
• Utilisateurs sur MySQL. La recherche d'un utilisateur par id, nom ou email relit la base si l'utilisateur n'est pas en cache : un utilisateur tout juste créé était déclaré inexistant (401).
• Export en arrière-plan. Sur MySQL, PostgreSQL et Oracle la progression de l'export arrive au dialogue et à la file comme sur SQL Server (auparavant elle passait de 0 à 100 %) ; sur Oracle la lecture de la progression échouait avec ORA-00911.

📦 Paquets mis à jour

🔧 Mises à jour opérationnelles recommandées

1. Clients des API : vérifier qu'insert, update, batch, clone et OData envoient les dates en ISO 8601 ; un format local répond désormais 400 errors.input.date_not_iso.
2. Jobs du scheduler qui exécutent insert ou update : réécrire en ISO les dates des params_values.
3. Gestion des erreurs : le code qui interceptait le 400 d'une opération désactivée doit gérer le 403 errors.auth.operation_disabled.
4. Traductions : la clé errors.input.date_not_iso (cinq langues) est dans les scripts de premier démarrage et elle est aussi ajoutée au démarrage aux bases existantes.