Release Notes — WUIC Framework v1.7.27

Datum: 14. Oktober 2026 Vorherige veröffentlichte Version: 1.7.26 (13. Oktober 2026) Backend: .NET 10 + IIS / Linux nginx Frontend: Angular 21

Version 1.7.27 behebt eine Regression der 1.7.26 bei between-Filtern mit Datum und Uhrzeit, macht die von Insert und Update geschriebenen Datumswerte unabhängig von der Kultur des Servers und schließt die Angleichung von MySQL, PostgreSQL und Oracle an SQL Server ab. Kurz zusammengefasst:

• between-Filter mit ISO-Grenzen inklusive Uhrzeit funktioniert wieder auf SQL Server, PostgreSQL und Oracle mit einem italienischen Server;
• für API-Clients sichtbare Änderung: ein als Nicht-ISO-8601-Text an Insert/Update gesendetes Datum liefert 400 errors.input.date_not_iso;
• auf der Route deaktivierte Operation: 403 errors.auth.operation_disabled statt 400, auf allen vier Datenbanken;
• Korrekturen der Provider MySQL, PostgreSQL und Oracle (verschachtelte Filtergruppen, Filter auf nicht ausgewählten Spalten, Pivot, eindeutige Werte, Pivot-Views);
• Hintergrund-Export mit Fortschrittsanzeige auch auf MySQL, PostgreSQL und Oracle.

Wo es verifiziert wurde: Unit-Tests und Tests mit echter Datenbank auf SQL Server, MySQL, PostgreSQL und Oracle; End-to-End-Tests der Dokumentation auf allen vier Datenbanken für die Filter von Grid und Pivot, den Pivot Builder, den Hintergrund-Export und die Export-Warteschlange (auf einer Tabelle mit 230.000 Zeilen) sowie für die sechs Tests, die Datumswerte speichern (Datumseditor, Assistent, Timeline, optimistische Nebenläufigkeit, Import).

🐛 Regression der 1.7.26: between mit Datum und Uhrzeit

Mit einem italienischen Server wurde ein between-Filter mit ISO-Grenzen inklusive Uhrzeit (2015-12-31T23:59:59) im Format des Servers neu gelesen: auf SQL Server lieferte der Filter einen Konvertierungsfehler, auf PostgreSQL und Oracle einen Formatfehler oder vertauschte Tag und Monat. Die Grenzen bleiben jetzt im invarianten ISO-Format; Grenzen nur mit Datum waren bereits korrekt.

🚦 Datumswerte in Insert und Update: nur ISO 8601 (für API-Clients sichtbare Änderung)

• Nicht-ISO-Text = 400. Ein Datum, das als Text an insertRecord, updateRecord, batchRecord, Clone oder OData gelangt, muss ISO 8601 sein: 2026-10-13, 2026-10-13T14:30:00 oder 2026-10-13 14:30:00, mit optionalen Sekunden, Sekundenbruchteilen, Z oder Offset. Andernfalls lautet die Antwort HTTP 400 errors.input.date_not_iso mit args.column und args.value. Bisher wurde der Text in der Kultur des Servers gelesen: 05/10/2026 war auf einem italienischen Server der 5. Oktober und auf einem amerikanischen der 10. Mai, und ein unlesbarer Text lieferte 500.
• Scheduler-Jobs. Dieselbe Regel gilt für die von Hand geschriebenen params_values der Jobs, die Insert oder Update ausführen: Datumswerte müssen in ISO geschrieben werden.
• Text mit Z. Er behält auf allen Datenbanken dieselbe Uhrzeit in UTC, wie ein Datum aus dem JSON; bisher wandelten SQL Server und MySQL ihn über batchRecord in die lokale Uhrzeit des Servers um.
• Logging-Datumswerte in der Antwort. Das in der Entity zurückgegebene Einfüge-, Änderungs- oder Löschdatum ist in ISO (yyyy-MM-ddTHH:mm:ss) und wird akzeptiert, wenn es in einem Update zurückgesendet wird. Verifiziert mit echter Datenbank auf SQL Server, MySQL und PostgreSQL; auf Oracle mit Unit-Tests.
• Dateiimport. Datumswerte im lokalen Format der Serverkultur werden weiterhin gelesen; eine unlesbare Zelle lässt die Zeile mit errors.input.date_not_iso fehlschlagen.
• SQL-Literale. Die im SQL von Insert und Update geschriebenen Datumswerte verwenden auf allen Datenbanken die invariante Kultur: mit einer Kultur mit buddhistischem Kalender (th-TH) ergab sich das Jahr 2569.

Mit dieser Arbeit behobene Fehler:

• PostgreSQL und Oracle, Tag und Monat vertauscht. Mit einem italienischen Server wurde ein im Formular als 12/10/2026 gespeichertes Datum als 10/12/2026 geschrieben.
• Batch-Speichern von Grid und Tabellenblatt. Ein Datum um Mitternacht wurde in UTC gesendet und kam als Vortag an; jetzt wird es wie beim Speichern eines einzelnen Datensatzes gesendet.
• Tabellenblatt. Ein in eine Datumszelle eingefügtes oder gezogenes Datum wird mit dem Format der aktuellen Sprache in ISO umgewandelt.

🔐 Deaktivierte Operation: 403

Insert, Update, Delete oder Wiederherstellung auf einer Route, auf der diese Operation deaktiviert ist, liefern HTTP 403 errors.auth.operation_disabled (mit der Route) auf SQL Server, MySQL, PostgreSQL und Oracle; bisher lautete die Antwort auf allen vier 400 errors.validation.failed.

🗄️ MySQL, PostgreSQL und Oracle

• Verschachtelte Filtergruppen. Auf PostgreSQL und Oracle wurde eine Gruppe innerhalb des Filters (aus „Frag die Daten“ oder dem erweiterten Filter des Grids) nicht angewendet und die Liste lieferte zu viele Zeilen. Eine Untergruppe innerhalb einer Gruppe funktioniert auf allen Datenbanken: auf SQL Server wiederholte sie die Gruppe, auf MySQL lieferte sie einen Syntaxfehler.
• Filter auf nicht ausgewählten Spalten. Auf PostgreSQL und Oracle wurde ein Filter auf eine Tabellenspalte, die die Liste nicht anforderte (vom Benutzer ausgeblendete Spalten, Export, „Frag die Daten“), stillschweigend ignoriert; jetzt wird er angewendet, wie auf SQL Server und MySQL.
• between im Pivot. Der Bereichsfilter des Pivots funktioniert auf SQL Server, MySQL, PostgreSQL und Oracle.
• Datumswerte in Vergleichen. Die Datumswerte der Filter von Grid und Pivot werden im ANSI/ISO-Format unabhängig von der Serverkultur geschrieben (bisher ORA-01858/ORA-01843 auf Oracle, ein Konvertierungsfehler auf SQL Server mit italienischem Login); ein unlesbares Datum liefert einen typisierten Fehler.
• Eindeutige Werte. Auf Oracle funktionieren sie auch auf Spalten mit langem Text (ORA-22848); auf MySQL beachten sie DISTINCT und die Zeilenbeschränkungen der Route.
• Pivot-Views. scaffoldView und die vom Pivot erstellte View registrieren eine gültige md_id auf PostgreSQL, Oracle und SQL Server (bisher 0), und der Aktualisierungsjob der View wird auch auf PostgreSQL und Oracle erstellt.
• Benutzer auf MySQL. Die Suche nach einem Benutzer per ID, Name oder E-Mail liest die Datenbank erneut, wenn der Benutzer nicht im Cache ist: ein gerade erstellter Benutzer galt als nicht vorhanden (401).
• Hintergrund-Export. Auf MySQL, PostgreSQL und Oracle erreicht der Fortschritt des Exports den Dialog und die Warteschlange wie auf SQL Server (bisher sprang er von 0 auf 100 %); auf Oracle schlug das Lesen des Fortschritts mit ORA-00911 fehl.

📦 Aktualisierte Pakete

🔧 Empfohlene Schritte beim Aktualisieren

1. API-Clients: prüfen, dass Insert, Update, Batch, Clone und OData Datumswerte in ISO 8601 senden; ein lokales Format liefert jetzt 400 errors.input.date_not_iso.
2. Scheduler-Jobs, die Insert oder Update ausführen: die Datumswerte in den params_values in ISO umschreiben.
3. Fehlerbehandlung: Code, der die 400 einer deaktivierten Operation abfing, muss die 403 errors.auth.operation_disabled behandeln.
4. Übersetzungen: der Schlüssel errors.input.date_not_iso (fünf Sprachen) ist in den Erststart-Skripten und wird beim Start auch zu bestehenden Datenbanken hinzugefügt.