OS.bee documentation - User contributions [en]

https://download.osbee.org/documentation/api.php?action=feedcontributions&feedformat=atom&user=Mollik OS.bee documentation - User contributions [en] 2026-11-12T22:26:06Z User contributions MediaWiki 1.26.2 https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4635 Releasenotes 2026 OS.pos 2026-11-11T10:22:16Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> <br /> == Version 5.3.0-V20261110 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist ein '''schnellerer und ruhigerer Start''' der Kasse. <br>Dazu kommen Datenimporte, die Datumsangaben in den üblichen Schreibweisen lesen, nicht nur im Format, das im Modell definiert ist.<br /> <br /> == Änderungen ==<br /> <br /> * Änderung: Die Kasse ist nach dem Start deutlich schneller bereit. Die Datenbank wird angebunden, während die Modelle noch eingelesen werden, statt danach. Betroffene Komponenten: Softwarefactory 5.3.0.20261109<br /> * Fix: Wird die Kasse kurz nach dem Start im Browser geöffnet, erscheint weder eine weiße Seite noch die Meldung „Failed to load the widgetset“. Die Startseite („Starting …“) bleibt stehen, bis die Kasse bereit ist, und lädt dann von selbst die Anmeldung. Ein Neuladen mit F5 ist nicht mehr nötig. Betroffene Komponenten: Softwarefactory 5.3.0.20261109<br /> * Änderung: Die Datenimporte des Backoffice lesen Datumsangaben in den üblichen Schreibweisen, zum Beispiel 30.01.2023 oder 2023-01-30, jeweils auch mit Uhrzeit. Dateien mit deutschem Datum, etwa die Zuordnung von Kunden zu exklusiven Produktgruppen, werden damit ohne Anpassung eingelesen. Ungültige Daten wie der 31.02. und Schreibweisen mit Schrägstrich (01/02/2023) werden wie bisher abgelehnt. Betroffene Komponenten: net.osbee.app.pos.backoffice/net.osbee.app.pos.backoffice.datainterchange, Softwarefactory 5.3.0.20261109<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261109|Softwarefactory 20261109]]<br /> <br /> == Version 4.5.7-V20261103 (OS) ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen.<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261104|Softwarefactory 20261104]]<br /> <br /> == Version 5.3.0-V20261012 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen. Daneben wurde die Verfügbarkeitsprüfung der Webservices auf eine Implementierung zusammengeführt und ein Datumsfehler darin behoben.<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4634 Releasenotes 2026 OS.pos 2026-11-09T13:01:08Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0-V20261109 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist ein '''schnellerer und ruhigerer Start''' der Kasse. <br>Dazu kommen Datenimporte, die Datumsangaben in den üblichen Schreibweisen lesen, nicht nur im Format, das im Modell definiert ist.<br /> <br /> == Änderungen ==<br /> <br /> * Änderung: Die Kasse ist nach dem Start deutlich schneller bereit. Die Datenbank wird angebunden, während die Modelle noch eingelesen werden, statt danach. Betroffene Komponenten: Softwarefactory 5.3.0.20261109<br /> * Fix: Wird die Kasse kurz nach dem Start im Browser geöffnet, erscheint weder eine weiße Seite noch die Meldung „Failed to load the widgetset“. Die Startseite („Starting …“) bleibt stehen, bis die Kasse bereit ist, und lädt dann von selbst die Anmeldung. Ein Neuladen mit F5 ist nicht mehr nötig. Betroffene Komponenten: Softwarefactory 5.3.0.20261109<br /> * Änderung: Die Datenimporte des Backoffice lesen Datumsangaben in den üblichen Schreibweisen, zum Beispiel 30.01.2023 oder 2023-01-30, jeweils auch mit Uhrzeit. Dateien mit deutschem Datum, etwa die Zuordnung von Kunden zu exklusiven Produktgruppen, werden damit ohne Anpassung eingelesen. Ungültige Daten wie der 31.02. und Schreibweisen mit Schrägstrich (01/02/2023) werden wie bisher abgelehnt. Betroffene Komponenten: net.osbee.app.pos.backoffice/net.osbee.app.pos.backoffice.datainterchange, Softwarefactory 5.3.0.20261109<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261109|Softwarefactory 20261109]]<br /> <br /> == Version 4.5.7-V20261103 (OS) ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen.<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261104|Softwarefactory 20261104]]<br /> <br /> == Version 5.3.0-V20261012 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen. Daneben wurde die Verfügbarkeitsprüfung der Webservices auf eine Implementierung zusammengeführt und ein Datumsfehler darin behoben.<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4633 Releasenotes 2026 OS.Softwarefactory 2026-11-09T10:59:24Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261109 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: Wird die Anwendung kurz nach dem Start im Browser geöffnet, erscheint nicht mehr die Meldung „Failed to load the widgetset“. Die Oberflächendateien (Widgetset, Themes, Symbole) werden jetzt gleich mit der Anwendung bereitgestellt und nicht erst, wenn alle Modelle eingelesen sind. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app<br /> ** Fix: Wird die Anwendung kurz nach dem Start im Browser geöffnet, bleibt die Seite nicht mehr weiß. Die Startseite („Starting …“) wird jetzt so lange angezeigt, bis auch alle Modelle eingelesen sind (Hinweis „the DSL models are being loaded“), und lädt danach von selbst die Anmeldung. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app<br /> ** Fix: QR-Codes in Bildfeldern werden jetzt angezeigt, z. B. auf der Kundenanzeige. Bisher blieb das Feld leer. Andere Barcodes und Bilder werden wie bisher angezeigt. Betroffene Komponenten: org.eclipse.osbp.runtime.web/org.eclipse.osbp.runtime.web.ecview.presentation.vaadin<br /> ** Änderung: Die Anwendung ist beim Start schneller bereit. Die Datenbankanbindung wartet nicht mehr, bis alle Modelle vollständig eingelesen sind, sondern startet, sobald die Modelle gefunden sind; das Einlesen läuft parallel weiter. In der Entwicklungsumgebung war die Anwendung dadurch nach etwa 61 statt 111 Sekunden bereit. Betroffene Komponenten: org.eclipse.osbp.ui.api, org.eclipse.osbp.dsl/org.eclipse.osbp.xtext.builder.metadata.services, org.eclipse.osbp.dsl.metadata.service, org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service<br /> <br /> * DSL:<br /> ** Änderung: Auch die Editoren für Datenschnittstellen (Datainterchange) und Signale arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.datainterchange/org.eclipse.osbp.xtext.datainterchange.ui, org.eclipse.osbp.xtext.signal/org.eclipse.osbp.xtext.signal.ui<br /> <br /> == Version 5.3.0.20261106 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Die Seite <code>/showLog</code> zeigt im laufenden Betrieb das Ende des Protokolls (die letzten 500 Zeilen), mit Textfilter, Aktualisieren und Herunterladen der aktuellen Datei. Anmelden können sich nur Benutzer mit der Superuser-Eigenschaft, mit derselben Sperre nach Fehlversuchen wie bei der normalen Anmeldung. Jeder Zugriff wird im Monitoring festgehalten. Die Seite ist standardmäßig ausgeschaltet und wird in der Systemkonfiguration mit <code>GLOBAL_PARAMETERS / showLog</code> eingeschaltet. Da dabei ein Passwort übertragen wird, sollte die Anwendung über HTTPS erreichbar sein. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app, org.eclipse.osbp.ui.api, org.eclipse.osbp.authentication, org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> ** Neu: Auf der Seite <code>/showLog</code> lässt sich die Schrift des Protokolls mit den Schaltflächen A− und A+ verkleinern und vergrößern. Die gewählte Größe bleibt beim Aktualisieren und Filtern erhalten, bis zur nächsten Anmeldung. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app<br /> ** Änderung: Wird eine falsche Adresse aufgerufen, zeigt die Hinweisseite jetzt alle Einstiegspunkte in einer Tabelle: Anwendung, Kundenanzeige (Display), Protokollseite und Dienststeuerung. Die automatische Weiterleitung zur Anwendung erfolgt nach 5 statt 3 Sekunden. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> ** Fix: Änderungen in der Systemkonfiguration wirken nach dem Speichern im Dialog wieder sofort. Seit Juni 2025 wurden Aufgaben, die nach dem Speichern im Hintergrund laufen sollen, nicht mehr ausgeführt; Konfigurationsänderungen wurden dadurch erst nach bis zu einer Stunde wirksam, und auch die Nachbearbeitung nach dem Speichern mancher Daten (z. B. für die Suche) unterblieb. Betroffene Komponenten: org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.postpersistservice<br /> ** Fix: Monitoring-Einträge mit dem Status „Info“ werden korrekt gespeichert. Bisher wurden sie als „Unbekannt“ abgelegt, und im Protokoll erschien ein Fehler. Nach dem Update wird die Datenbankstruktur des Monitorings einmalig geprüft. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Änderung: Die Vorschläge im Editor der Funktionsbibliothek (Strg+Leertaste) erscheinen jetzt auch in großen Dateien ohne spürbare Wartezeit. Bisher wurde bei jedem Aufruf die ganze Datei neu gelesen, was in großen Dateien mehrere Sekunden dauern konnte. Die Gliederung (Outline) wird erst aktualisiert, wenn zwei Sekunden lang nicht getippt wurde, und bremst das Tippen dadurch nicht mehr. Auch das Einfärben und das Ein- und Ausklappen von Abschnitten werden nicht mehr bei jedem Aufruf der Vorschläge für die ganze Datei neu berechnet, sondern nur nach einer Änderung. Ist in der Gliederung „Mit Editor verknüpfen“ eingeschaltet, wartet der Editor nach größeren Änderungen nicht mehr, bis die Datei vollständig geprüft ist. Betroffene Komponenten: org.eclipse.osbp.xtext.functionlibrary/org.eclipse.osbp.xtext.functionlibrarydsl.ui<br /> ** Änderung: Die Editoren für Entitäten, DTOs, Statemachines und Datamarts arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Nur der erste Aufruf der Vorschläge nach dem Start der Entwicklungsumgebung dauert etwas länger. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.oxtype/org.eclipse.osbp.xtext.oxtype.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.xtext.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.dto.xtext.ui, org.eclipse.osbp.xtext.statemachine/org.eclipse.osbp.xtext.statemachine.ui, org.eclipse.osbp.xtext.datamart/org.eclipse.osbp.xtext.datamartdsl.ui<br /> <br /> * Build & Infrastruktur:<br /> ** Änderung: Die Entwicklungsumgebung schreibt bei jedem Bauen nicht mehr die Versionsangaben aus Git in die Projekte. Das hat das Bauen in der Entwicklungsumgebung spürbar verlangsamt und oft eine weitere Baurunde ausgelöst. Die Versionsangaben entstehen weiterhin beim Bauen auf dem Build-Server, die ausgelieferten Stände enthalten sie wie bisher. Entwickler führen danach einmal in der Entwicklungsumgebung „Maven > Update Project“ mit „Force Update of Snapshots“ aus (Alt+F5). Betroffene Komponenten: org.eclipse.osbp.releng.maven, org.eclipse.osbp.releng.maven/org.eclipse.osbp.releng.maven.parent.tycho, org.osbee.releng.maven, org.osbee.releng.maven/org.osbee.releng.maven.parent.tycho, net.osbee.releng.maven, net.osbee.releng.maven/net.osbee.releng.maven.parent.tycho, net.osbee.app.releng.maven, net.osbee.app.releng.maven/net.osbee.app.releng.maven.parent.tycho<br /> <br /> == Version 5.3.0.20261105 ==<br /> <br /> * OSBP Framework:<br /> ** Änderung: Beim Start wird die Datenbankstruktur nur noch geprüft, wenn sich das Datenmodell wirklich geändert hat, auch nach einem Update. Ein neuer Stand der Anwendung ohne Änderung am Datenmodell startet dadurch ohne diese Prüfung. Nach dem Update auf diese Version wird einmalig noch einmal alles geprüft. Bei sehr großen Tabellen kann das viele Minuten dauern. Die Anwendung darf in dieser Zeit nicht beendet werden. Über den echten Update-Fall auf einer Installation ist das noch nicht bestätigt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Der Start wartet jetzt so lange, wie die Prüfung der Datenbankstruktur braucht. Bisher brach er nach 5 Minuten ab, und bei sehr großen Tabellen kam die Anwendung dadurch nicht mehr hoch. Wer weiterhin eine Grenze möchte, setzt <code>-DPersistenceService.startupTimeoutSeconds=&lt;Sekunden&gt;</code>. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Vorhandene Indizes und Fremdschlüssel werden beim Start auf MySQL und MariaDB nicht mehr ein zweites Mal angelegt. Das verkürzt die Prüfung bei großen Tabellen deutlich. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Liegen auf einem Datenbankserver mehrere Datenbanken mit gleichen Tabellen, legt die Prüfung auf MySQL und MariaDB fehlende Spalten nun zuverlässig an. Bisher galt eine Spalte als vorhanden, wenn es sie in einer anderen Datenbank gab. Später erschien dann die Meldung „Unknown column“, zum Beispiel beim Wiederholdruck einer Rechnung. Im Betrieb ist diese Korrektur noch nicht bestätigt. Ohne Verbindungspool (<code>-DPersistenceService.connectionPool=false</code>) greift sie nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Die Startseite zeigt die verstrichene Zeit, damit man sieht, dass der Start noch läuft. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Die Startseite kann das Ende des Protokolls anzeigen, mit <code>-DStartupStatusPage.showLog=true</code> in der <code>eclipse.ini</code>. Die Datei wird automatisch ermittelt, <code>-DStartupStatusPage.logFile=&lt;Pfad&gt;</code> gibt sie fest vor. Die Anzeige ist standardmäßig aus, denn die Startseite ist ohne Anmeldung erreichbar und das Protokoll kann vertrauliche Angaben enthalten. Auf Kassen beim Kunden sollte sie aus bleiben. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> <br /> == Version 5.3.0.20261104 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Beim Start wird die Datenbankstruktur nur noch dort geprüft, wo sich das Datenmodell geändert hat. Auf einer Testinstallation war die Datenbank beim Start dadurch rund 18 Sekunden früher bereit; insgesamt entfallen dort rund 30 Sekunden Prüfarbeit. Der erste Start nach einem Update prüft noch einmal alles. Die Prüfung ergänzt nur und entfernt nichts aus der Datenbank. Betroffene Komponenten: org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration.api, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.base, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service<br /> ** Neu: Eine neue Ansicht zeigt, wann die Datenbankstruktur zuletzt geprüft wurde. Administratoren können dort für einen Bereich eine neue Prüfung beim nächsten Start auslösen. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration<br /> ** Änderung: Der Startparameter <code>-DPersistenceService.NoCache</code> wird nicht mehr gebraucht. Ein vorhandener Eintrag stört nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Ein Bericht wird nach einem Klick nur noch einmal angezeigt. Seit Version 5.3.0.20261103 konnte er sich mehrfach neu aufbauen. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api, org.eclipse.osbp.xtext.report/org.eclipse.osbp.xtext.report.runtime<br /> <br /> <br /> == Version 5.3.0.20261103 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; keine ausgelieferte Anwendung schaltet sie bisher ein''' Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: HikariCP-Verbindungspool vor der Datenquelle des Treibers. Bisher öffnete jede Abfrage eine neue Verbindung zur Datenbank, etwa 3.000 je stündlichem Lauf des Zeitplaners auf einer ruhenden Kasse. Maximum ist <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Jeder Eintrag der Systemüberwachung enthält die Auslastung des Verbindungspools in Prozent und die Zahl der wartenden Threads. Wartende Threads markieren den Eintrag Memorycheck als Warnung. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: <code>db/README.md</code> beschreibt Aufbau, Versions- und Historienkonventionen sowie die Regeln für ein Migrationsskript (nie ein ausgeliefertes Skript ändern, sondern eine neue Version schreiben; jeden Datenbankzustand vertragen, weil das Skript vor dem Anlegen der Tabellen läuft; Objekte an ihrer Struktur statt an ihrem Namen finden). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: Die Tabelle „Flyway info“ im Log richtet ihre Spaltenbreiten nach dem Inhalt. Bisher schnitten feste Breiten Version und Beschreibung ab (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen daher nur innerhalb eines Bundles eindeutig sein; zwei Entwickler können in verschiedenen Bundles dieselbe Versionsnummer vergeben. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Das Grid fragt nach einem Wechsel des Inhalts nicht mehr für jede bekannte Zeile einzeln beim Container nach. Bei einem lazy ladenden Container war das je Zeile ein <code>SELECT COUNT</code>: Ein Lauf des Zeitplaners mit offener Perspektive machte 10.468 Abfragen, danach 787. Die Schlüssel von Zeilen, die der Client nicht mehr anzeigt, werden beim nächsten Zurücksetzen freigegeben. Betroffene Komponenten: org.eclipse.osbp.ecview.extension/org.eclipse.osbp.ecview.extension.grid.presentation<br /> ** Fix: Eine Ansicht zeigt nach einer Folge von Änderungen immer den letzten Stand. Bisher wurden Aktualisierungen während des Zeichnens oder innerhalb der Ruhezeit (<code>RefreshTimeout</code>, Standard 300 ms) verworfen, sodass die letzte Änderung fehlen konnte. Jetzt werden sie zurückgestellt: Die Ansicht zeichnet einmal nach der letzten Anforderung, spätestens 5 Sekunden nach der ersten zurückgestellten. Gilt für alle Ansichten über <code>AbstractHybridVaaclipseView</code> (Tabellen, Diagramme, Berichte). Die Zahl der Abfragen sinkt dadurch nicht zwingend: gemessen am Überwachungsdiagramm 4 statt 3 bei einem Lauf des Zeitplaners, dafür mit dem letzten Stand. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api<br /> ** Fix: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr. Der Lizenzschlüssel für die kommerzielle Flyway-Edition wird nicht mehr gelesen; die Open-Source-Edition genügt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Die Units werden parallel in einem Thread-Pool angelegt; das Lesen der Konfiguration holt DTO-Dienste und Mapper über Declarative Services, deren Sperre der Start-Thread während des gesamten Persistenzstarts hält. Jeder Pool-Thread wartete daher, bis DS nach 20 s aufgab. Die Werte werden nun vorher einmal auf dem Start-Thread gelesen, der die Sperre erneut nehmen darf; die Pool-Threads erhalten sie aus dem Zwischenspeicher der Konfiguration. Die Vorgabewerte (<code>Soft</code>, <code>1000</code>) sind Konstanten, sodass beide Lesestellen dieselben verwenden. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Fix: Der Diagramm-Generator setzt den Zähler je Datenreihe zurück (ab 500 Zeilen passten Reihen und Beschriftung sonst nicht zusammen), Linien verschwinden beim Überfahren nicht mehr, der Tooltip nennt die Kategorie, und die Animation läuft nur noch beim ersten Zeichnen. Betroffene Komponenten: org.eclipse.osbp.xtext.chart<br /> ** Änderung: Das Speicherdiagramm der Überwachung ist mit dem korrigierten Generator neu erzeugt. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt. Ohne das Fragment endet Flyway auf MariaDB mit „Unsupported Database: MySQL 5.5“ (so meldet der alte MySQL-Treiber eine MariaDB). PostgreSQL und Oracle sind weiterhin im Kern enthalten. '''Das per Maven gebaute Fragment ist noch nicht auf einer Installation geprüft'''; '''Build-Reihenfolge:''' dependencies-mbp, dependencies, persistence, system.configuration. Betroffene Komponenten: org.eclipse.osbp.dependencies-mbp/org.eclipse.osbp.dependencies.bundle.flyway.mysql, org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.flyway<br /> ** Neu: HikariCP 4.0.3 wird als Feature mit ausgeliefert. Es ist wie Flyway aus den Quell-Features ausgenommen. Betroffene Komponenten: org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.hikaricp, org.eclipse.osbp.dependencies.p2, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.feature, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.target.feature, org.eclipse.osbp.persistence/org.eclipse.osbp.persistence.feature, org.eclipse.osbp.softwarefactory/org.eclipse.osbp.softwarefactory.runtime.feature<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4632 Releasenotes 2026 OS.Softwarefactory 2026-11-09T09:44:06Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261109 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: QR-Codes in Bildfeldern werden jetzt angezeigt, z. B. auf der Kundenanzeige. Bisher blieb das Feld leer. Andere Barcodes und Bilder werden wie bisher angezeigt. Betroffene Komponenten: org.eclipse.osbp.runtime.web/org.eclipse.osbp.runtime.web.ecview.presentation.vaadin<br /> ** Änderung: Die Anwendung ist beim Start schneller bereit. Die Datenbankanbindung wartet nicht mehr, bis alle Modelle vollständig eingelesen sind, sondern startet, sobald die Modelle gefunden sind; das Einlesen läuft parallel weiter. In der Entwicklungsumgebung war die Anwendung dadurch nach etwa 61 statt 111 Sekunden bereit. Betroffene Komponenten: org.eclipse.osbp.ui.api, org.eclipse.osbp.dsl/org.eclipse.osbp.xtext.builder.metadata.services, org.eclipse.osbp.dsl.metadata.service, org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service<br /> <br /> * DSL:<br /> ** Änderung: Auch die Editoren für Datenschnittstellen (Datainterchange) und Signale arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.datainterchange/org.eclipse.osbp.xtext.datainterchange.ui, org.eclipse.osbp.xtext.signal/org.eclipse.osbp.xtext.signal.ui<br /> <br /> == Version 5.3.0.20261106 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Die Seite <code>/showLog</code> zeigt im laufenden Betrieb das Ende des Protokolls (die letzten 500 Zeilen), mit Textfilter, Aktualisieren und Herunterladen der aktuellen Datei. Anmelden können sich nur Benutzer mit der Superuser-Eigenschaft, mit derselben Sperre nach Fehlversuchen wie bei der normalen Anmeldung. Jeder Zugriff wird im Monitoring festgehalten. Die Seite ist standardmäßig ausgeschaltet und wird in der Systemkonfiguration mit <code>GLOBAL_PARAMETERS / showLog</code> eingeschaltet. Da dabei ein Passwort übertragen wird, sollte die Anwendung über HTTPS erreichbar sein. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app, org.eclipse.osbp.ui.api, org.eclipse.osbp.authentication, org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> ** Neu: Auf der Seite <code>/showLog</code> lässt sich die Schrift des Protokolls mit den Schaltflächen A− und A+ verkleinern und vergrößern. Die gewählte Größe bleibt beim Aktualisieren und Filtern erhalten, bis zur nächsten Anmeldung. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app<br /> ** Änderung: Wird eine falsche Adresse aufgerufen, zeigt die Hinweisseite jetzt alle Einstiegspunkte in einer Tabelle: Anwendung, Kundenanzeige (Display), Protokollseite und Dienststeuerung. Die automatische Weiterleitung zur Anwendung erfolgt nach 5 statt 3 Sekunden. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> ** Fix: Änderungen in der Systemkonfiguration wirken nach dem Speichern im Dialog wieder sofort. Seit Juni 2025 wurden Aufgaben, die nach dem Speichern im Hintergrund laufen sollen, nicht mehr ausgeführt; Konfigurationsänderungen wurden dadurch erst nach bis zu einer Stunde wirksam, und auch die Nachbearbeitung nach dem Speichern mancher Daten (z. B. für die Suche) unterblieb. Betroffene Komponenten: org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.postpersistservice<br /> ** Fix: Monitoring-Einträge mit dem Status „Info“ werden korrekt gespeichert. Bisher wurden sie als „Unbekannt“ abgelegt, und im Protokoll erschien ein Fehler. Nach dem Update wird die Datenbankstruktur des Monitorings einmalig geprüft. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Änderung: Die Vorschläge im Editor der Funktionsbibliothek (Strg+Leertaste) erscheinen jetzt auch in großen Dateien ohne spürbare Wartezeit. Bisher wurde bei jedem Aufruf die ganze Datei neu gelesen, was in großen Dateien mehrere Sekunden dauern konnte. Die Gliederung (Outline) wird erst aktualisiert, wenn zwei Sekunden lang nicht getippt wurde, und bremst das Tippen dadurch nicht mehr. Auch das Einfärben und das Ein- und Ausklappen von Abschnitten werden nicht mehr bei jedem Aufruf der Vorschläge für die ganze Datei neu berechnet, sondern nur nach einer Änderung. Ist in der Gliederung „Mit Editor verknüpfen“ eingeschaltet, wartet der Editor nach größeren Änderungen nicht mehr, bis die Datei vollständig geprüft ist. Betroffene Komponenten: org.eclipse.osbp.xtext.functionlibrary/org.eclipse.osbp.xtext.functionlibrarydsl.ui<br /> ** Änderung: Die Editoren für Entitäten, DTOs, Statemachines und Datamarts arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Nur der erste Aufruf der Vorschläge nach dem Start der Entwicklungsumgebung dauert etwas länger. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.oxtype/org.eclipse.osbp.xtext.oxtype.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.xtext.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.dto.xtext.ui, org.eclipse.osbp.xtext.statemachine/org.eclipse.osbp.xtext.statemachine.ui, org.eclipse.osbp.xtext.datamart/org.eclipse.osbp.xtext.datamartdsl.ui<br /> <br /> * Build & Infrastruktur:<br /> ** Änderung: Die Entwicklungsumgebung schreibt bei jedem Bauen nicht mehr die Versionsangaben aus Git in die Projekte. Das hat das Bauen in der Entwicklungsumgebung spürbar verlangsamt und oft eine weitere Baurunde ausgelöst. Die Versionsangaben entstehen weiterhin beim Bauen auf dem Build-Server, die ausgelieferten Stände enthalten sie wie bisher. Entwickler führen danach einmal in der Entwicklungsumgebung „Maven > Update Project“ mit „Force Update of Snapshots“ aus (Alt+F5). Betroffene Komponenten: org.eclipse.osbp.releng.maven, org.eclipse.osbp.releng.maven/org.eclipse.osbp.releng.maven.parent.tycho, org.osbee.releng.maven, org.osbee.releng.maven/org.osbee.releng.maven.parent.tycho, net.osbee.releng.maven, net.osbee.releng.maven/net.osbee.releng.maven.parent.tycho, net.osbee.app.releng.maven, net.osbee.app.releng.maven/net.osbee.app.releng.maven.parent.tycho<br /> <br /> == Version 5.3.0.20261105 ==<br /> <br /> * OSBP Framework:<br /> ** Änderung: Beim Start wird die Datenbankstruktur nur noch geprüft, wenn sich das Datenmodell wirklich geändert hat, auch nach einem Update. Ein neuer Stand der Anwendung ohne Änderung am Datenmodell startet dadurch ohne diese Prüfung. Nach dem Update auf diese Version wird einmalig noch einmal alles geprüft. Bei sehr großen Tabellen kann das viele Minuten dauern. Die Anwendung darf in dieser Zeit nicht beendet werden. Über den echten Update-Fall auf einer Installation ist das noch nicht bestätigt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Der Start wartet jetzt so lange, wie die Prüfung der Datenbankstruktur braucht. Bisher brach er nach 5 Minuten ab, und bei sehr großen Tabellen kam die Anwendung dadurch nicht mehr hoch. Wer weiterhin eine Grenze möchte, setzt <code>-DPersistenceService.startupTimeoutSeconds=&lt;Sekunden&gt;</code>. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Vorhandene Indizes und Fremdschlüssel werden beim Start auf MySQL und MariaDB nicht mehr ein zweites Mal angelegt. Das verkürzt die Prüfung bei großen Tabellen deutlich. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Liegen auf einem Datenbankserver mehrere Datenbanken mit gleichen Tabellen, legt die Prüfung auf MySQL und MariaDB fehlende Spalten nun zuverlässig an. Bisher galt eine Spalte als vorhanden, wenn es sie in einer anderen Datenbank gab. Später erschien dann die Meldung „Unknown column“, zum Beispiel beim Wiederholdruck einer Rechnung. Im Betrieb ist diese Korrektur noch nicht bestätigt. Ohne Verbindungspool (<code>-DPersistenceService.connectionPool=false</code>) greift sie nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Die Startseite zeigt die verstrichene Zeit, damit man sieht, dass der Start noch läuft. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Die Startseite kann das Ende des Protokolls anzeigen, mit <code>-DStartupStatusPage.showLog=true</code> in der <code>eclipse.ini</code>. Die Datei wird automatisch ermittelt, <code>-DStartupStatusPage.logFile=&lt;Pfad&gt;</code> gibt sie fest vor. Die Anzeige ist standardmäßig aus, denn die Startseite ist ohne Anmeldung erreichbar und das Protokoll kann vertrauliche Angaben enthalten. Auf Kassen beim Kunden sollte sie aus bleiben. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> <br /> == Version 5.3.0.20261104 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Beim Start wird die Datenbankstruktur nur noch dort geprüft, wo sich das Datenmodell geändert hat. Auf einer Testinstallation war die Datenbank beim Start dadurch rund 18 Sekunden früher bereit; insgesamt entfallen dort rund 30 Sekunden Prüfarbeit. Der erste Start nach einem Update prüft noch einmal alles. Die Prüfung ergänzt nur und entfernt nichts aus der Datenbank. Betroffene Komponenten: org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration.api, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.base, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service<br /> ** Neu: Eine neue Ansicht zeigt, wann die Datenbankstruktur zuletzt geprüft wurde. Administratoren können dort für einen Bereich eine neue Prüfung beim nächsten Start auslösen. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration<br /> ** Änderung: Der Startparameter <code>-DPersistenceService.NoCache</code> wird nicht mehr gebraucht. Ein vorhandener Eintrag stört nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Ein Bericht wird nach einem Klick nur noch einmal angezeigt. Seit Version 5.3.0.20261103 konnte er sich mehrfach neu aufbauen. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api, org.eclipse.osbp.xtext.report/org.eclipse.osbp.xtext.report.runtime<br /> <br /> <br /> == Version 5.3.0.20261103 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; keine ausgelieferte Anwendung schaltet sie bisher ein''' Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: HikariCP-Verbindungspool vor der Datenquelle des Treibers. Bisher öffnete jede Abfrage eine neue Verbindung zur Datenbank, etwa 3.000 je stündlichem Lauf des Zeitplaners auf einer ruhenden Kasse. Maximum ist <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Jeder Eintrag der Systemüberwachung enthält die Auslastung des Verbindungspools in Prozent und die Zahl der wartenden Threads. Wartende Threads markieren den Eintrag Memorycheck als Warnung. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: <code>db/README.md</code> beschreibt Aufbau, Versions- und Historienkonventionen sowie die Regeln für ein Migrationsskript (nie ein ausgeliefertes Skript ändern, sondern eine neue Version schreiben; jeden Datenbankzustand vertragen, weil das Skript vor dem Anlegen der Tabellen läuft; Objekte an ihrer Struktur statt an ihrem Namen finden). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: Die Tabelle „Flyway info“ im Log richtet ihre Spaltenbreiten nach dem Inhalt. Bisher schnitten feste Breiten Version und Beschreibung ab (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen daher nur innerhalb eines Bundles eindeutig sein; zwei Entwickler können in verschiedenen Bundles dieselbe Versionsnummer vergeben. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Das Grid fragt nach einem Wechsel des Inhalts nicht mehr für jede bekannte Zeile einzeln beim Container nach. Bei einem lazy ladenden Container war das je Zeile ein <code>SELECT COUNT</code>: Ein Lauf des Zeitplaners mit offener Perspektive machte 10.468 Abfragen, danach 787. Die Schlüssel von Zeilen, die der Client nicht mehr anzeigt, werden beim nächsten Zurücksetzen freigegeben. Betroffene Komponenten: org.eclipse.osbp.ecview.extension/org.eclipse.osbp.ecview.extension.grid.presentation<br /> ** Fix: Eine Ansicht zeigt nach einer Folge von Änderungen immer den letzten Stand. Bisher wurden Aktualisierungen während des Zeichnens oder innerhalb der Ruhezeit (<code>RefreshTimeout</code>, Standard 300 ms) verworfen, sodass die letzte Änderung fehlen konnte. Jetzt werden sie zurückgestellt: Die Ansicht zeichnet einmal nach der letzten Anforderung, spätestens 5 Sekunden nach der ersten zurückgestellten. Gilt für alle Ansichten über <code>AbstractHybridVaaclipseView</code> (Tabellen, Diagramme, Berichte). Die Zahl der Abfragen sinkt dadurch nicht zwingend: gemessen am Überwachungsdiagramm 4 statt 3 bei einem Lauf des Zeitplaners, dafür mit dem letzten Stand. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api<br /> ** Fix: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr. Der Lizenzschlüssel für die kommerzielle Flyway-Edition wird nicht mehr gelesen; die Open-Source-Edition genügt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Die Units werden parallel in einem Thread-Pool angelegt; das Lesen der Konfiguration holt DTO-Dienste und Mapper über Declarative Services, deren Sperre der Start-Thread während des gesamten Persistenzstarts hält. Jeder Pool-Thread wartete daher, bis DS nach 20 s aufgab. Die Werte werden nun vorher einmal auf dem Start-Thread gelesen, der die Sperre erneut nehmen darf; die Pool-Threads erhalten sie aus dem Zwischenspeicher der Konfiguration. Die Vorgabewerte (<code>Soft</code>, <code>1000</code>) sind Konstanten, sodass beide Lesestellen dieselben verwenden. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Fix: Der Diagramm-Generator setzt den Zähler je Datenreihe zurück (ab 500 Zeilen passten Reihen und Beschriftung sonst nicht zusammen), Linien verschwinden beim Überfahren nicht mehr, der Tooltip nennt die Kategorie, und die Animation läuft nur noch beim ersten Zeichnen. Betroffene Komponenten: org.eclipse.osbp.xtext.chart<br /> ** Änderung: Das Speicherdiagramm der Überwachung ist mit dem korrigierten Generator neu erzeugt. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt. Ohne das Fragment endet Flyway auf MariaDB mit „Unsupported Database: MySQL 5.5“ (so meldet der alte MySQL-Treiber eine MariaDB). PostgreSQL und Oracle sind weiterhin im Kern enthalten. '''Das per Maven gebaute Fragment ist noch nicht auf einer Installation geprüft'''; '''Build-Reihenfolge:''' dependencies-mbp, dependencies, persistence, system.configuration. Betroffene Komponenten: org.eclipse.osbp.dependencies-mbp/org.eclipse.osbp.dependencies.bundle.flyway.mysql, org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.flyway<br /> ** Neu: HikariCP 4.0.3 wird als Feature mit ausgeliefert. Es ist wie Flyway aus den Quell-Features ausgenommen. Betroffene Komponenten: org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.hikaricp, org.eclipse.osbp.dependencies.p2, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.feature, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.target.feature, org.eclipse.osbp.persistence/org.eclipse.osbp.persistence.feature, org.eclipse.osbp.softwarefactory/org.eclipse.osbp.softwarefactory.runtime.feature<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4631 Releasenotes 2026 OS.Softwarefactory 2026-11-06T13:50:22Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261106 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Die Seite <code>/showLog</code> zeigt im laufenden Betrieb das Ende des Protokolls (die letzten 500 Zeilen), mit Textfilter, Aktualisieren und Herunterladen der aktuellen Datei. Anmelden können sich nur Benutzer mit der Superuser-Eigenschaft, mit derselben Sperre nach Fehlversuchen wie bei der normalen Anmeldung. Jeder Zugriff wird im Monitoring festgehalten. Die Seite ist standardmäßig ausgeschaltet und wird in der Systemkonfiguration mit <code>GLOBAL_PARAMETERS / showLog</code> eingeschaltet. Da dabei ein Passwort übertragen wird, sollte die Anwendung über HTTPS erreichbar sein. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app, org.eclipse.osbp.ui.api, org.eclipse.osbp.authentication, org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> ** Neu: Auf der Seite <code>/showLog</code> lässt sich die Schrift des Protokolls mit den Schaltflächen A− und A+ verkleinern und vergrößern. Die gewählte Größe bleibt beim Aktualisieren und Filtern erhalten, bis zur nächsten Anmeldung. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app<br /> ** Änderung: Wird eine falsche Adresse aufgerufen, zeigt die Hinweisseite jetzt alle Einstiegspunkte in einer Tabelle: Anwendung, Kundenanzeige (Display), Protokollseite und Dienststeuerung. Die automatische Weiterleitung zur Anwendung erfolgt nach 5 statt 3 Sekunden. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> ** Fix: Änderungen in der Systemkonfiguration wirken nach dem Speichern im Dialog wieder sofort. Seit Juni 2025 wurden Aufgaben, die nach dem Speichern im Hintergrund laufen sollen, nicht mehr ausgeführt; Konfigurationsänderungen wurden dadurch erst nach bis zu einer Stunde wirksam, und auch die Nachbearbeitung nach dem Speichern mancher Daten (z. B. für die Suche) unterblieb. Betroffene Komponenten: org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.postpersistservice<br /> ** Fix: Monitoring-Einträge mit dem Status „Info“ werden korrekt gespeichert. Bisher wurden sie als „Unbekannt“ abgelegt, und im Protokoll erschien ein Fehler. Nach dem Update wird die Datenbankstruktur des Monitorings einmalig geprüft. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Änderung: Die Vorschläge im Editor der Funktionsbibliothek (Strg+Leertaste) erscheinen jetzt auch in großen Dateien ohne spürbare Wartezeit. Bisher wurde bei jedem Aufruf die ganze Datei neu gelesen, was in großen Dateien mehrere Sekunden dauern konnte. Die Gliederung (Outline) wird erst aktualisiert, wenn zwei Sekunden lang nicht getippt wurde, und bremst das Tippen dadurch nicht mehr. Auch das Einfärben und das Ein- und Ausklappen von Abschnitten werden nicht mehr bei jedem Aufruf der Vorschläge für die ganze Datei neu berechnet, sondern nur nach einer Änderung. Ist in der Gliederung „Mit Editor verknüpfen“ eingeschaltet, wartet der Editor nach größeren Änderungen nicht mehr, bis die Datei vollständig geprüft ist. Betroffene Komponenten: org.eclipse.osbp.xtext.functionlibrary/org.eclipse.osbp.xtext.functionlibrarydsl.ui<br /> ** Änderung: Die Editoren für Entitäten, DTOs, Statemachines und Datamarts arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Nur der erste Aufruf der Vorschläge nach dem Start der Entwicklungsumgebung dauert etwas länger. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.oxtype/org.eclipse.osbp.xtext.oxtype.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.xtext.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.dto.xtext.ui, org.eclipse.osbp.xtext.statemachine/org.eclipse.osbp.xtext.statemachine.ui, org.eclipse.osbp.xtext.datamart/org.eclipse.osbp.xtext.datamartdsl.ui<br /> <br /> * Build & Infrastruktur:<br /> ** Änderung: Die Entwicklungsumgebung schreibt bei jedem Bauen nicht mehr die Versionsangaben aus Git in die Projekte. Das hat das Bauen in der Entwicklungsumgebung spürbar verlangsamt und oft eine weitere Baurunde ausgelöst. Die Versionsangaben entstehen weiterhin beim Bauen auf dem Build-Server, die ausgelieferten Stände enthalten sie wie bisher. Entwickler führen danach einmal in der Entwicklungsumgebung „Maven > Update Project“ mit „Force Update of Snapshots“ aus (Alt+F5). Betroffene Komponenten: org.eclipse.osbp.releng.maven, org.eclipse.osbp.releng.maven/org.eclipse.osbp.releng.maven.parent.tycho, org.osbee.releng.maven, org.osbee.releng.maven/org.osbee.releng.maven.parent.tycho, net.osbee.releng.maven, net.osbee.releng.maven/net.osbee.releng.maven.parent.tycho, net.osbee.app.releng.maven, net.osbee.app.releng.maven/net.osbee.app.releng.maven.parent.tycho<br /> <br /> == Version 5.3.0.20261105 ==<br /> <br /> * OSBP Framework:<br /> ** Änderung: Beim Start wird die Datenbankstruktur nur noch geprüft, wenn sich das Datenmodell wirklich geändert hat, auch nach einem Update. Ein neuer Stand der Anwendung ohne Änderung am Datenmodell startet dadurch ohne diese Prüfung. Nach dem Update auf diese Version wird einmalig noch einmal alles geprüft. Bei sehr großen Tabellen kann das viele Minuten dauern. Die Anwendung darf in dieser Zeit nicht beendet werden. Über den echten Update-Fall auf einer Installation ist das noch nicht bestätigt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Der Start wartet jetzt so lange, wie die Prüfung der Datenbankstruktur braucht. Bisher brach er nach 5 Minuten ab, und bei sehr großen Tabellen kam die Anwendung dadurch nicht mehr hoch. Wer weiterhin eine Grenze möchte, setzt <code>-DPersistenceService.startupTimeoutSeconds=&lt;Sekunden&gt;</code>. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Vorhandene Indizes und Fremdschlüssel werden beim Start auf MySQL und MariaDB nicht mehr ein zweites Mal angelegt. Das verkürzt die Prüfung bei großen Tabellen deutlich. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Liegen auf einem Datenbankserver mehrere Datenbanken mit gleichen Tabellen, legt die Prüfung auf MySQL und MariaDB fehlende Spalten nun zuverlässig an. Bisher galt eine Spalte als vorhanden, wenn es sie in einer anderen Datenbank gab. Später erschien dann die Meldung „Unknown column“, zum Beispiel beim Wiederholdruck einer Rechnung. Im Betrieb ist diese Korrektur noch nicht bestätigt. Ohne Verbindungspool (<code>-DPersistenceService.connectionPool=false</code>) greift sie nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Die Startseite zeigt die verstrichene Zeit, damit man sieht, dass der Start noch läuft. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Die Startseite kann das Ende des Protokolls anzeigen, mit <code>-DStartupStatusPage.showLog=true</code> in der <code>eclipse.ini</code>. Die Datei wird automatisch ermittelt, <code>-DStartupStatusPage.logFile=&lt;Pfad&gt;</code> gibt sie fest vor. Die Anzeige ist standardmäßig aus, denn die Startseite ist ohne Anmeldung erreichbar und das Protokoll kann vertrauliche Angaben enthalten. Auf Kassen beim Kunden sollte sie aus bleiben. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager<br /> <br /> == Version 5.3.0.20261104 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Beim Start wird die Datenbankstruktur nur noch dort geprüft, wo sich das Datenmodell geändert hat. Auf einer Testinstallation war die Datenbank beim Start dadurch rund 18 Sekunden früher bereit; insgesamt entfallen dort rund 30 Sekunden Prüfarbeit. Der erste Start nach einem Update prüft noch einmal alles. Die Prüfung ergänzt nur und entfernt nichts aus der Datenbank. Betroffene Komponenten: org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration.api, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.base, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service<br /> ** Neu: Eine neue Ansicht zeigt, wann die Datenbankstruktur zuletzt geprüft wurde. Administratoren können dort für einen Bereich eine neue Prüfung beim nächsten Start auslösen. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration<br /> ** Änderung: Der Startparameter <code>-DPersistenceService.NoCache</code> wird nicht mehr gebraucht. Ein vorhandener Eintrag stört nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Ein Bericht wird nach einem Klick nur noch einmal angezeigt. Seit Version 5.3.0.20261103 konnte er sich mehrfach neu aufbauen. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api, org.eclipse.osbp.xtext.report/org.eclipse.osbp.xtext.report.runtime<br /> <br /> <br /> == Version 5.3.0.20261103 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; keine ausgelieferte Anwendung schaltet sie bisher ein''' Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: HikariCP-Verbindungspool vor der Datenquelle des Treibers. Bisher öffnete jede Abfrage eine neue Verbindung zur Datenbank, etwa 3.000 je stündlichem Lauf des Zeitplaners auf einer ruhenden Kasse. Maximum ist <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Jeder Eintrag der Systemüberwachung enthält die Auslastung des Verbindungspools in Prozent und die Zahl der wartenden Threads. Wartende Threads markieren den Eintrag Memorycheck als Warnung. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: <code>db/README.md</code> beschreibt Aufbau, Versions- und Historienkonventionen sowie die Regeln für ein Migrationsskript (nie ein ausgeliefertes Skript ändern, sondern eine neue Version schreiben; jeden Datenbankzustand vertragen, weil das Skript vor dem Anlegen der Tabellen läuft; Objekte an ihrer Struktur statt an ihrem Namen finden). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: Die Tabelle „Flyway info“ im Log richtet ihre Spaltenbreiten nach dem Inhalt. Bisher schnitten feste Breiten Version und Beschreibung ab (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen daher nur innerhalb eines Bundles eindeutig sein; zwei Entwickler können in verschiedenen Bundles dieselbe Versionsnummer vergeben. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Das Grid fragt nach einem Wechsel des Inhalts nicht mehr für jede bekannte Zeile einzeln beim Container nach. Bei einem lazy ladenden Container war das je Zeile ein <code>SELECT COUNT</code>: Ein Lauf des Zeitplaners mit offener Perspektive machte 10.468 Abfragen, danach 787. Die Schlüssel von Zeilen, die der Client nicht mehr anzeigt, werden beim nächsten Zurücksetzen freigegeben. Betroffene Komponenten: org.eclipse.osbp.ecview.extension/org.eclipse.osbp.ecview.extension.grid.presentation<br /> ** Fix: Eine Ansicht zeigt nach einer Folge von Änderungen immer den letzten Stand. Bisher wurden Aktualisierungen während des Zeichnens oder innerhalb der Ruhezeit (<code>RefreshTimeout</code>, Standard 300 ms) verworfen, sodass die letzte Änderung fehlen konnte. Jetzt werden sie zurückgestellt: Die Ansicht zeichnet einmal nach der letzten Anforderung, spätestens 5 Sekunden nach der ersten zurückgestellten. Gilt für alle Ansichten über <code>AbstractHybridVaaclipseView</code> (Tabellen, Diagramme, Berichte). Die Zahl der Abfragen sinkt dadurch nicht zwingend: gemessen am Überwachungsdiagramm 4 statt 3 bei einem Lauf des Zeitplaners, dafür mit dem letzten Stand. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api<br /> ** Fix: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr. Der Lizenzschlüssel für die kommerzielle Flyway-Edition wird nicht mehr gelesen; die Open-Source-Edition genügt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Die Units werden parallel in einem Thread-Pool angelegt; das Lesen der Konfiguration holt DTO-Dienste und Mapper über Declarative Services, deren Sperre der Start-Thread während des gesamten Persistenzstarts hält. Jeder Pool-Thread wartete daher, bis DS nach 20 s aufgab. Die Werte werden nun vorher einmal auf dem Start-Thread gelesen, der die Sperre erneut nehmen darf; die Pool-Threads erhalten sie aus dem Zwischenspeicher der Konfiguration. Die Vorgabewerte (<code>Soft</code>, <code>1000</code>) sind Konstanten, sodass beide Lesestellen dieselben verwenden. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Fix: Der Diagramm-Generator setzt den Zähler je Datenreihe zurück (ab 500 Zeilen passten Reihen und Beschriftung sonst nicht zusammen), Linien verschwinden beim Überfahren nicht mehr, der Tooltip nennt die Kategorie, und die Animation läuft nur noch beim ersten Zeichnen. Betroffene Komponenten: org.eclipse.osbp.xtext.chart<br /> ** Änderung: Das Speicherdiagramm der Überwachung ist mit dem korrigierten Generator neu erzeugt. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt. Ohne das Fragment endet Flyway auf MariaDB mit „Unsupported Database: MySQL 5.5“ (so meldet der alte MySQL-Treiber eine MariaDB). PostgreSQL und Oracle sind weiterhin im Kern enthalten. '''Das per Maven gebaute Fragment ist noch nicht auf einer Installation geprüft'''; '''Build-Reihenfolge:''' dependencies-mbp, dependencies, persistence, system.configuration. Betroffene Komponenten: org.eclipse.osbp.dependencies-mbp/org.eclipse.osbp.dependencies.bundle.flyway.mysql, org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.flyway<br /> ** Neu: HikariCP 4.0.3 wird als Feature mit ausgeliefert. Es ist wie Flyway aus den Quell-Features ausgenommen. Betroffene Komponenten: org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.hikaricp, org.eclipse.osbp.dependencies.p2, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.feature, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.target.feature, org.eclipse.osbp.persistence/org.eclipse.osbp.persistence.feature, org.eclipse.osbp.softwarefactory/org.eclipse.osbp.softwarefactory.runtime.feature<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4630 Releasenotes 2026 OS.Softwarefactory 2026-11-04T12:11:55Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261103 ==<br /> <br /> * OSBP Framework:<br /> ** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; keine ausgelieferte Anwendung schaltet sie bisher ein''' Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: HikariCP-Verbindungspool vor der Datenquelle des Treibers. Bisher öffnete jede Abfrage eine neue Verbindung zur Datenbank, etwa 3.000 je stündlichem Lauf des Zeitplaners auf einer ruhenden Kasse. Maximum ist <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Jeder Eintrag der Systemüberwachung enthält die Auslastung des Verbindungspools in Prozent und die Zahl der wartenden Threads. Wartende Threads markieren den Eintrag Memorycheck als Warnung. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: <code>db/README.md</code> beschreibt Aufbau, Versions- und Historienkonventionen sowie die Regeln für ein Migrationsskript (nie ein ausgeliefertes Skript ändern, sondern eine neue Version schreiben; jeden Datenbankzustand vertragen, weil das Skript vor dem Anlegen der Tabellen läuft; Objekte an ihrer Struktur statt an ihrem Namen finden). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: Die Tabelle „Flyway info“ im Log richtet ihre Spaltenbreiten nach dem Inhalt. Bisher schnitten feste Breiten Version und Beschreibung ab (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen daher nur innerhalb eines Bundles eindeutig sein; zwei Entwickler können in verschiedenen Bundles dieselbe Versionsnummer vergeben. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Das Grid fragt nach einem Wechsel des Inhalts nicht mehr für jede bekannte Zeile einzeln beim Container nach. Bei einem lazy ladenden Container war das je Zeile ein <code>SELECT COUNT</code>: Ein Lauf des Zeitplaners mit offener Perspektive machte 10.468 Abfragen, danach 787. Die Schlüssel von Zeilen, die der Client nicht mehr anzeigt, werden beim nächsten Zurücksetzen freigegeben. Betroffene Komponenten: org.eclipse.osbp.ecview.extension/org.eclipse.osbp.ecview.extension.grid.presentation<br /> ** Fix: Eine Ansicht zeigt nach einer Folge von Änderungen immer den letzten Stand. Bisher wurden Aktualisierungen während des Zeichnens oder innerhalb der Ruhezeit (<code>RefreshTimeout</code>, Standard 300 ms) verworfen, sodass die letzte Änderung fehlen konnte. Jetzt werden sie zurückgestellt: Die Ansicht zeichnet einmal nach der letzten Anforderung, spätestens 5 Sekunden nach der ersten zurückgestellten. Gilt für alle Ansichten über <code>AbstractHybridVaaclipseView</code> (Tabellen, Diagramme, Berichte). Die Zahl der Abfragen sinkt dadurch nicht zwingend: gemessen am Überwachungsdiagramm 4 statt 3 bei einem Lauf des Zeitplaners, dafür mit dem letzten Stand. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api<br /> ** Fix: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr. Der Lizenzschlüssel für die kommerzielle Flyway-Edition wird nicht mehr gelesen; die Open-Source-Edition genügt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Die Units werden parallel in einem Thread-Pool angelegt; das Lesen der Konfiguration holt DTO-Dienste und Mapper über Declarative Services, deren Sperre der Start-Thread während des gesamten Persistenzstarts hält. Jeder Pool-Thread wartete daher, bis DS nach 20 s aufgab. Die Werte werden nun vorher einmal auf dem Start-Thread gelesen, der die Sperre erneut nehmen darf; die Pool-Threads erhalten sie aus dem Zwischenspeicher der Konfiguration. Die Vorgabewerte (<code>Soft</code>, <code>1000</code>) sind Konstanten, sodass beide Lesestellen dieselben verwenden. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> <br /> * DSL:<br /> ** Fix: Der Diagramm-Generator setzt den Zähler je Datenreihe zurück (ab 500 Zeilen passten Reihen und Beschriftung sonst nicht zusammen), Linien verschwinden beim Überfahren nicht mehr, der Tooltip nennt die Kategorie, und die Animation läuft nur noch beim ersten Zeichnen. Betroffene Komponenten: org.eclipse.osbp.xtext.chart<br /> ** Änderung: Das Speicherdiagramm der Überwachung ist mit dem korrigierten Generator neu erzeugt. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt. Ohne das Fragment endet Flyway auf MariaDB mit „Unsupported Database: MySQL 5.5“ (so meldet der alte MySQL-Treiber eine MariaDB). PostgreSQL und Oracle sind weiterhin im Kern enthalten. '''Das per Maven gebaute Fragment ist noch nicht auf einer Installation geprüft'''; '''Build-Reihenfolge:''' dependencies-mbp, dependencies, persistence, system.configuration. Betroffene Komponenten: org.eclipse.osbp.dependencies-mbp/org.eclipse.osbp.dependencies.bundle.flyway.mysql, org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.flyway<br /> ** Neu: HikariCP 4.0.3 wird als Feature mit ausgeliefert. Es ist wie Flyway aus den Quell-Features ausgenommen. Betroffene Komponenten: org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.hikaricp, org.eclipse.osbp.dependencies.p2, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.feature, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.target.feature, org.eclipse.osbp.persistence/org.eclipse.osbp.persistence.feature, org.eclipse.osbp.softwarefactory/org.eclipse.osbp.softwarefactory.runtime.feature<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4629 Releasenotes 2026 OS.Softwarefactory 2026-11-04T12:05:53Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261103 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: Das Grid fragt nach einem Wechsel des Inhalts nicht mehr für jede bekannte Zeile einzeln beim Container nach. Bei einem lazy ladenden Container war das je Zeile ein <code>SELECT COUNT</code>: Ein Lauf des Zeitplaners mit offener Perspektive machte 10.468 Abfragen, danach 787. Die Schlüssel von Zeilen, die der Client nicht mehr anzeigt, werden beim nächsten Zurücksetzen freigegeben. Betroffene Komponenten: org.eclipse.osbp.ecview.extension/org.eclipse.osbp.ecview.extension.grid.presentation<br /> ** Fix: Eine Ansicht zeigt nach einer Folge von Änderungen immer den letzten Stand. Bisher wurden Aktualisierungen während des Zeichnens oder innerhalb der Ruhezeit (<code>RefreshTimeout</code>, Standard 300 ms) verworfen, sodass die letzte Änderung fehlen konnte. Jetzt werden sie zurückgestellt: Die Ansicht zeichnet einmal nach der letzten Anforderung, spätestens 5 Sekunden nach der ersten zurückgestellten. Gilt für alle Ansichten über <code>AbstractHybridVaaclipseView</code> (Tabellen, Diagramme, Berichte). Die Zahl der Abfragen sinkt dadurch nicht zwingend: gemessen am Überwachungsdiagramm 4 statt 3 bei einem Lauf des Zeitplaners, dafür mit dem letzten Stand. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api<br /> ** Fix: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr. Der Lizenzschlüssel für die kommerzielle Flyway-Edition wird nicht mehr gelesen; die Open-Source-Edition genügt. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Die Units werden parallel in einem Thread-Pool angelegt; das Lesen der Konfiguration holt DTO-Dienste und Mapper über Declarative Services, deren Sperre der Start-Thread während des gesamten Persistenzstarts hält. Jeder Pool-Thread wartete daher, bis DS nach 20 s aufgab. Die Werte werden nun vorher einmal auf dem Start-Thread gelesen, der die Sperre erneut nehmen darf; die Pool-Threads erhalten sie aus dem Zwischenspeicher der Konfiguration. Die Vorgabewerte (<code>Soft</code>, <code>1000</code>) sind Konstanten, sodass beide Lesestellen dieselben verwenden. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Fix: Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Neu: Die Pools sind über JMX sichtbar. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; keine ausgelieferte Anwendung schaltet sie bisher ein''' Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: HikariCP-Verbindungspool vor der Datenquelle des Treibers. Bisher öffnete jede Abfrage eine neue Verbindung zur Datenbank, etwa 3.000 je stündlichem Lauf des Zeitplaners auf einer ruhenden Kasse. Maximum ist <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Flyway verwendet weiter die Datenquelle des Treibers. In der Entwicklungsumgebung gemessen: keine neuen Verbindungen im Ruhezustand, beim stündlichen Lauf und bei Verkäufen. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Neu: Jeder Eintrag der Systemüberwachung enthält die Auslastung des Verbindungspools in Prozent und die Zahl der wartenden Threads. Wartende Threads markieren den Eintrag Memorycheck als Warnung. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: <code>db/README.md</code> beschreibt Aufbau, Versions- und Historienkonventionen sowie die Regeln für ein Migrationsskript (nie ein ausgeliefertes Skript ändern, sondern eine neue Version schreiben; jeden Datenbankzustand vertragen, weil das Skript vor dem Anlegen der Tabellen läuft; Objekte an ihrer Struktur statt an ihrem Namen finden). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base<br /> ** Änderung: Die Tabelle „Flyway info“ im Log richtet ihre Spaltenbreiten nach dem Inhalt. Bisher schnitten feste Breiten Version und Beschreibung ab (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence<br /> ** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen daher nur innerhalb eines Bundles eindeutig sein; zwei Entwickler können in verschiedenen Bundles dieselbe Versionsnummer vergeben. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence<br /> <br /> * DSL:<br /> ** Fix: Der Diagramm-Generator setzt den Zähler je Datenreihe zurück (ab 500 Zeilen passten Reihen und Beschriftung sonst nicht zusammen), Linien verschwinden beim Überfahren nicht mehr, der Tooltip nennt die Kategorie, und die Animation läuft nur noch beim ersten Zeichnen. Betroffene Komponenten: org.eclipse.osbp.xtext.chart<br /> ** Änderung: Das Speicherdiagramm der Überwachung ist mit dem korrigierten Generator neu erzeugt. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt. Ohne das Fragment endet Flyway auf MariaDB mit „Unsupported Database: MySQL 5.5“ (so meldet der alte MySQL-Treiber eine MariaDB). PostgreSQL und Oracle sind weiterhin im Kern enthalten. '''Das per Maven gebaute Fragment ist noch nicht auf einer Installation geprüft'''; '''Build-Reihenfolge:''' dependencies-mbp, dependencies, persistence, system.configuration. Betroffene Komponenten: org.eclipse.osbp.dependencies-mbp/org.eclipse.osbp.dependencies.bundle.flyway.mysql, org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.flyway<br /> ** Neu: HikariCP 4.0.3 wird als Feature mit ausgeliefert. Es ist wie Flyway aus den Quell-Features ausgenommen. Betroffene Komponenten: org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.hikaricp, org.eclipse.osbp.dependencies.p2, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.feature, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.target.feature, org.eclipse.osbp.persistence/org.eclipse.osbp.persistence.feature, org.eclipse.osbp.softwarefactory/org.eclipse.osbp.softwarefactory.runtime.feature<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4628 Releasenotes 2026 OS.pos 2026-11-04T10:47:29Z

<p>Mollik: /* Version 4.5.7-V20261103 (OS) */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 4.5.7-V20261103 (OS) ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen.<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261104|Softwarefactory 20261104]]<br /> <br /> == Version 5.3.0-V20261012 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen. Daneben wurde die Verfügbarkeitsprüfung der Webservices auf eine Implementierung zusammengeführt und ein Datumsfehler darin behoben.<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4627 Releasenotes 2026 OS.Softwarefactory 2026-11-04T10:46:39Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261104 ==<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4626 Releasenotes 2026 OS.pos 2026-11-04T10:46:13Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 4.5.7-V20261103 (OS) ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen.<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261012 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen. Daneben wurde die Verfügbarkeitsprüfung der Webservices auf eine Implementierung zusammengeführt und ein Datumsfehler darin behoben.<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4625 Releasenotes 2026 OS.Softwarefactory 2026-10-29T10:41:17Z

<p>Mollik: /* Version 5.3.0.20261029 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4624 Releasenotes 2026 OS.Softwarefactory 2026-10-29T10:39:59Z

<p>Mollik: /* Version 5.3.0.20261029 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen)<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4623 Releasenotes 2026 OS.Softwarefactory 2026-10-29T10:39:31Z

<p>Mollik: /* Version 5.3.0.20261029 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>;'''<br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen)<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4622 Releasenotes 2026 OS.Softwarefactory 2026-10-29T10:38:35Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.<br /> <br /> ** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>;'''<br /> <br /> ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht<br /> <br /> ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (<code>outOfOrder</code>), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.<br /> <br /> ** Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. '''Die PostgreSQL- und Oracle-Skripte sind ungetestet.''' Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken <code>shipment</code> und <code>pos</code> geschehen)<br /> <br /> * Allgemein:<br /> ** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre<br /> <br /> <br /> * Build & Infrastruktur:<br /> ** Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.<br /> <br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4621 Releasenotes 2026 OS.Interchange 2026-10-29T10:26:55Z

<p>Mollik: /* Version 5.3.0.20261029 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist der '''Speicherverbrauch von BDI''': Mit einer Testrechnung wurden XRechnung und ZUGFeRD wiederholt erzeugt und der Speicher nach jeder Anfrage vermessen. Gefunden und behoben wurden ein Rechnungsdatensatz, den FreeMarker festhalten konnte, und offene Transaktionen nach abgewiesenen oder fehlgeschlagenen Anfragen. Daneben startete BDI an einer Konsole zeitweise ohne REST-Dienste, und Überwachungseinträge gingen auf älteren Datenbanken verloren. Zum Abschluss wurden XRechnung und ZUGFeRD mit den offiziellen Validatoren (KoSIT, Mustang/veraPDF) geprüft; die dabei gefundenen Fehler sind behoben, beide Formate werden nun angenommen. <br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261029 OS.Softwarefactory 5.3.0.20261029] und früher<br /> * Fix: Anhänge in der XRechnung leer<br /> * Fix: Rechnungs-XML im ZUGFeRD-PDF falsch benannt - es wurde der vollständig Pfad der Datei eingetragen. (<code>factur-x.xml</code>) wird nun wie erwartet verwendet<br /> * Fix: verschiedene Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität<br /> * Fix: offene Transaktionen verbleiben in verschiedenen Bearbeitungssituationen. Betroffen sind <br /> ** abgewiesene Anfrage<br /> ** bei XRechnung-Import: wenn Problem beim Speichern der empfangenen Daten auftritt<br /> ** bei unerwarteten Fehlern wurden Transaktionen nicht zurückgerollt<br /> * Fix: Rest Dienste wurden gelegentlich nicht gestartet. Ein Reihenfolgproblem beim Start der OSGI Bundles wurde gefixt.<br /> * Fix: Falsche Gesamtsteuer in ZUGFeRD / Factur-X: Das Feld <code>TaxTotalAmount</code> wurde aus dem ersten Steuer-Teilbetrag statt aus der Gesamtsteuer gefüllt. Bei einer Rechnung mit mehreren Steuersätzen stand dort die Steuer nur eines Satzes (Testrechnung: 3,50 € statt 22,50 €), was die Regel BR-CO-14 der EN 16931 verletzt. Nun wird die gespeicherte Gesamtsteuer übernommen, wie es die XRechnung bereits tat. In beiden Vorlagen wird kein Wert berechnet; alle Beträge kommen unverändert aus der Datenbank.<br /> * Fix: Zahlenformate: Das Format der Vorlagen wirkte bisher nur auf den Ersatzwert 0, gespeicherte Werte erschienen im allgemeinen Format (19 statt 19.00, 171.5 statt 171.50). Beträge, Steuersätze und Faktoren stehen nun mit zwei Nachkommastellen, Einzelpreise mit vier, Mengen wie gespeichert ohne Auffüllen.<br /> * Fix: Steuerkategorie der Rechnungszeilen in Factur-X: Das Pflichtfeld <code>CategoryCode</code> einer Zeile wurde ausgelassen, wenn <code>ProductTaxCategoryCode</code> leer war; die Datei war dann schemaungültig. Ersatzweise wird nun die Steuerkategorie des Artikels verwendet, wie in der XRechnung.<br /> * Fix: USt-IdNr. und Steuernummer fehlten: Die Vorlagen lasen die Umsatzsteuer-Identifikationsnummer von Verkäufer und Käufer nur aus den Steuerschema-Zeilen der Partei und übergingen die Felder <code>VAT_ID</code> und <code>TAX_ID</code> der Partei selbst; im Factur-X-XML fehlte die USt-IdNr. des Käufers ganz. Der KoSIT-Validator wies solche Rechnungen mit BR-S-02, BR-CO-26 und BR-DE-16 zurück. Gibt es keine Steuerschema-Zeilen, werden nun <code>VAT_ID</code> (BT-31 bzw. BT-48, Schema VAT/VA) und <code>TAX_ID</code> (BT-32, Schema FC) der Partei übernommen.<br /> * Fix: Name von Verkäufer und Käufer fehlte in der XRechnung: Die Pflichtfelder BT-27 und BT-44 (<code>PartyLegalEntity/RegistrationName</code>) wurden nur geschrieben, wenn ein Registername gepflegt war (BR-06, BR-07). Fehlt er, steht nun der Name der Partei darin.<br /> * Fix: Kontakt: Als Ansprechpartner des Verkäufers erschien der Firmenname und als Kontakt-E-Mail die Adresse der Partei. Verwendet werden nun <code>C_NAME</code> und <code>C_EMAIL</code>, ersatzweise Name und Adresse der Partei.<br /> * Fix: ZUGFeRD-PDF war kein PDF/A: Das Farbprofil <code>sRGB.icc</code> für den OutputIntent lag nicht im Bundle, und der Kontext-Classloader eines OSGi-Threads hätte es auch nicht gefunden. Das PDF blieb ohne Meldung ohne OutputIntent und damit nicht PDF/A-3-konform (veraPDF: „DeviceRGB/DeviceGray … without output intent“). Das Bundle enthält nun das zlib-lizenzierte sRGB-Profil von Apache FOP (<code>resources/icc/</code>) und lädt es über den eigenen Classloader; fehlt es, wird eine Warnung protokolliert.<br /> * Start steht für 20: Im Log erschien bei jedem Start „Getting a lock required more than 20000 ms“, an zwei Stellen. Behoben<br /> <br /> * ToDo: aus früheren Installationen können DB Indizes vorhanden sein, die das Schreiben von Monitoringeinträgen der aktuellen Version verhindern.<br /> ** vor Update: Die Datenbank muss bereinigt werden:<br /> <syntaxhighlight lang="sql"><br /> ALTER TABLE monitor_sub_category DROP INDEX MONITOR_SUB_CATEGORYMSC_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYMCA_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYDK_INDEX;<br /> ALTER TABLE monitor_main_category DROP INDEX MONITOR_MAIN_CATEGORYMMCA_NAME_INDEX;<br /> ALTER TABLE monitor_component DROP INDEX MONITOR_COMPONENTI1;<br /> CREATE UNIQUE INDEX MONITOR_COMPONENTI1 ON monitor_component (MCO_NAME, MCO_INSTALLATION);<br /> </syntaxhighlight><br /> ** alternativ in der Eclipse.ini der Installation vor dem Update im Verzeichnis bdi-conf den Eintrag <code>-DFlyway.active=true</code> ergänzen.<br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4620 Releasenotes 2026 OS.Interchange 2026-10-29T10:26:22Z

<p>Mollik: /* Version 5.3.0.20261029 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist der '''Speicherverbrauch von BDI''': Mit einer Testrechnung wurden XRechnung und ZUGFeRD wiederholt erzeugt und der Speicher nach jeder Anfrage vermessen. Gefunden und behoben wurden ein Rechnungsdatensatz, den FreeMarker festhalten konnte, und offene Transaktionen nach abgewiesenen oder fehlgeschlagenen Anfragen. Daneben startete BDI an einer Konsole zeitweise ohne REST-Dienste, und Überwachungseinträge gingen auf älteren Datenbanken verloren. Zum Abschluss wurden XRechnung und ZUGFeRD mit den offiziellen Validatoren (KoSIT, Mustang/veraPDF) geprüft; die dabei gefundenen Fehler sind behoben, beide Formate werden nun angenommen. <br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012 OS.Softwarefactory 5.3.0.20261012] und früher<br /> * Fix: Anhänge in der XRechnung leer<br /> * Fix: Rechnungs-XML im ZUGFeRD-PDF falsch benannt - es wurde der vollständig Pfad der Datei eingetragen. (<code>factur-x.xml</code>) wird nun wie erwartet verwendet<br /> * Fix: verschiedene Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität<br /> * Fix: offene Transaktionen verbleiben in verschiedenen Bearbeitungssituationen. Betroffen sind <br /> ** abgewiesene Anfrage<br /> ** bei XRechnung-Import: wenn Problem beim Speichern der empfangenen Daten auftritt<br /> ** bei unerwarteten Fehlern wurden Transaktionen nicht zurückgerollt<br /> * Fix: Rest Dienste wurden gelegentlich nicht gestartet. Ein Reihenfolgproblem beim Start der OSGI Bundles wurde gefixt.<br /> * Fix: Falsche Gesamtsteuer in ZUGFeRD / Factur-X: Das Feld <code>TaxTotalAmount</code> wurde aus dem ersten Steuer-Teilbetrag statt aus der Gesamtsteuer gefüllt. Bei einer Rechnung mit mehreren Steuersätzen stand dort die Steuer nur eines Satzes (Testrechnung: 3,50 € statt 22,50 €), was die Regel BR-CO-14 der EN 16931 verletzt. Nun wird die gespeicherte Gesamtsteuer übernommen, wie es die XRechnung bereits tat. In beiden Vorlagen wird kein Wert berechnet; alle Beträge kommen unverändert aus der Datenbank.<br /> * Fix: Zahlenformate: Das Format der Vorlagen wirkte bisher nur auf den Ersatzwert 0, gespeicherte Werte erschienen im allgemeinen Format (19 statt 19.00, 171.5 statt 171.50). Beträge, Steuersätze und Faktoren stehen nun mit zwei Nachkommastellen, Einzelpreise mit vier, Mengen wie gespeichert ohne Auffüllen.<br /> * Fix: Steuerkategorie der Rechnungszeilen in Factur-X: Das Pflichtfeld <code>CategoryCode</code> einer Zeile wurde ausgelassen, wenn <code>ProductTaxCategoryCode</code> leer war; die Datei war dann schemaungültig. Ersatzweise wird nun die Steuerkategorie des Artikels verwendet, wie in der XRechnung.<br /> * Fix: USt-IdNr. und Steuernummer fehlten: Die Vorlagen lasen die Umsatzsteuer-Identifikationsnummer von Verkäufer und Käufer nur aus den Steuerschema-Zeilen der Partei und übergingen die Felder <code>VAT_ID</code> und <code>TAX_ID</code> der Partei selbst; im Factur-X-XML fehlte die USt-IdNr. des Käufers ganz. Der KoSIT-Validator wies solche Rechnungen mit BR-S-02, BR-CO-26 und BR-DE-16 zurück. Gibt es keine Steuerschema-Zeilen, werden nun <code>VAT_ID</code> (BT-31 bzw. BT-48, Schema VAT/VA) und <code>TAX_ID</code> (BT-32, Schema FC) der Partei übernommen.<br /> * Fix: Name von Verkäufer und Käufer fehlte in der XRechnung: Die Pflichtfelder BT-27 und BT-44 (<code>PartyLegalEntity/RegistrationName</code>) wurden nur geschrieben, wenn ein Registername gepflegt war (BR-06, BR-07). Fehlt er, steht nun der Name der Partei darin.<br /> * Fix: Kontakt: Als Ansprechpartner des Verkäufers erschien der Firmenname und als Kontakt-E-Mail die Adresse der Partei. Verwendet werden nun <code>C_NAME</code> und <code>C_EMAIL</code>, ersatzweise Name und Adresse der Partei.<br /> * Fix: ZUGFeRD-PDF war kein PDF/A: Das Farbprofil <code>sRGB.icc</code> für den OutputIntent lag nicht im Bundle, und der Kontext-Classloader eines OSGi-Threads hätte es auch nicht gefunden. Das PDF blieb ohne Meldung ohne OutputIntent und damit nicht PDF/A-3-konform (veraPDF: „DeviceRGB/DeviceGray … without output intent“). Das Bundle enthält nun das zlib-lizenzierte sRGB-Profil von Apache FOP (<code>resources/icc/</code>) und lädt es über den eigenen Classloader; fehlt es, wird eine Warnung protokolliert.<br /> * Start steht für 20: Im Log erschien bei jedem Start „Getting a lock required more than 20000 ms“, an zwei Stellen. Behoben<br /> <br /> * ToDo: aus früheren Installationen können DB Indizes vorhanden sein, die das Schreiben von Monitoringeinträgen der aktuellen Version verhindern.<br /> ** vor Update: Die Datenbank muss bereinigt werden:<br /> <syntaxhighlight lang="sql"><br /> ALTER TABLE monitor_sub_category DROP INDEX MONITOR_SUB_CATEGORYMSC_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYMCA_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYDK_INDEX;<br /> ALTER TABLE monitor_main_category DROP INDEX MONITOR_MAIN_CATEGORYMMCA_NAME_INDEX;<br /> ALTER TABLE monitor_component DROP INDEX MONITOR_COMPONENTI1;<br /> CREATE UNIQUE INDEX MONITOR_COMPONENTI1 ON monitor_component (MCO_NAME, MCO_INSTALLATION);<br /> </syntaxhighlight><br /> ** alternativ in der Eclipse.ini der Installation vor dem Update im Verzeichnis bdi-conf den Eintrag <code>-DFlyway.active=true</code> ergänzen.<br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4619 Releasenotes 2026 OS.Interchange 2026-10-29T10:25:15Z

<p>Mollik: /* Version 5.3.0.20261028 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261029 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist der '''Speicherverbrauch von BDI''': Mit einer Testrechnung wurden XRechnung und ZUGFeRD wiederholt erzeugt und der Speicher nach jeder Anfrage vermessen. Gefunden und behoben wurden ein Rechnungsdatensatz, den FreeMarker festhalten konnte, und offene Transaktionen nach abgewiesenen oder fehlgeschlagenen Anfragen. Daneben startete BDI an einer Konsole zeitweise ohne REST-Dienste, und Überwachungseinträge gingen auf älteren Datenbanken verloren. Zum Abschluss wurden XRechnung und ZUGFeRD mit den offiziellen Validatoren (KoSIT, Mustang/veraPDF) geprüft; die dabei gefundenen Fehler sind behoben, beide Formate werden nun angenommen. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht. Die Korrekturen im Framework (Flyway-Migrationen, Monitoring-Indizes) beschreiben die Release Notes der Softwarefactory für denselben Zeitraum.<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012 OS.Softwarefactory 5.3.0.20261012] und früher<br /> * Fix: Anhänge in der XRechnung leer<br /> * Fix: Rechnungs-XML im ZUGFeRD-PDF falsch benannt - es wurde der vollständig Pfad der Datei eingetragen. (<code>factur-x.xml</code>) wird nun wie erwartet verwendet<br /> * Fix: verschiedene Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität<br /> * Fix: offene Transaktionen verbleiben in verschiedenen Bearbeitungssituationen. Betroffen sind <br /> ** abgewiesene Anfrage<br /> ** bei XRechnung-Import: wenn Problem beim Speichern der empfangenen Daten auftritt<br /> ** bei unerwarteten Fehlern wurden Transaktionen nicht zurückgerollt<br /> * Fix: Rest Dienste wurden gelegentlich nicht gestartet. Ein Reihenfolgproblem beim Start der OSGI Bundles wurde gefixt.<br /> * Fix: Falsche Gesamtsteuer in ZUGFeRD / Factur-X: Das Feld <code>TaxTotalAmount</code> wurde aus dem ersten Steuer-Teilbetrag statt aus der Gesamtsteuer gefüllt. Bei einer Rechnung mit mehreren Steuersätzen stand dort die Steuer nur eines Satzes (Testrechnung: 3,50 € statt 22,50 €), was die Regel BR-CO-14 der EN 16931 verletzt. Nun wird die gespeicherte Gesamtsteuer übernommen, wie es die XRechnung bereits tat. In beiden Vorlagen wird kein Wert berechnet; alle Beträge kommen unverändert aus der Datenbank.<br /> * Fix: Zahlenformate: Das Format der Vorlagen wirkte bisher nur auf den Ersatzwert 0, gespeicherte Werte erschienen im allgemeinen Format (19 statt 19.00, 171.5 statt 171.50). Beträge, Steuersätze und Faktoren stehen nun mit zwei Nachkommastellen, Einzelpreise mit vier, Mengen wie gespeichert ohne Auffüllen.<br /> * Fix: Steuerkategorie der Rechnungszeilen in Factur-X: Das Pflichtfeld <code>CategoryCode</code> einer Zeile wurde ausgelassen, wenn <code>ProductTaxCategoryCode</code> leer war; die Datei war dann schemaungültig. Ersatzweise wird nun die Steuerkategorie des Artikels verwendet, wie in der XRechnung.<br /> * Fix: USt-IdNr. und Steuernummer fehlten: Die Vorlagen lasen die Umsatzsteuer-Identifikationsnummer von Verkäufer und Käufer nur aus den Steuerschema-Zeilen der Partei und übergingen die Felder <code>VAT_ID</code> und <code>TAX_ID</code> der Partei selbst; im Factur-X-XML fehlte die USt-IdNr. des Käufers ganz. Der KoSIT-Validator wies solche Rechnungen mit BR-S-02, BR-CO-26 und BR-DE-16 zurück. Gibt es keine Steuerschema-Zeilen, werden nun <code>VAT_ID</code> (BT-31 bzw. BT-48, Schema VAT/VA) und <code>TAX_ID</code> (BT-32, Schema FC) der Partei übernommen.<br /> * Fix: Name von Verkäufer und Käufer fehlte in der XRechnung: Die Pflichtfelder BT-27 und BT-44 (<code>PartyLegalEntity/RegistrationName</code>) wurden nur geschrieben, wenn ein Registername gepflegt war (BR-06, BR-07). Fehlt er, steht nun der Name der Partei darin.<br /> * Fix: Kontakt: Als Ansprechpartner des Verkäufers erschien der Firmenname und als Kontakt-E-Mail die Adresse der Partei. Verwendet werden nun <code>C_NAME</code> und <code>C_EMAIL</code>, ersatzweise Name und Adresse der Partei.<br /> * Fix: ZUGFeRD-PDF war kein PDF/A: Das Farbprofil <code>sRGB.icc</code> für den OutputIntent lag nicht im Bundle, und der Kontext-Classloader eines OSGi-Threads hätte es auch nicht gefunden. Das PDF blieb ohne Meldung ohne OutputIntent und damit nicht PDF/A-3-konform (veraPDF: „DeviceRGB/DeviceGray … without output intent“). Das Bundle enthält nun das zlib-lizenzierte sRGB-Profil von Apache FOP (<code>resources/icc/</code>) und lädt es über den eigenen Classloader; fehlt es, wird eine Warnung protokolliert.<br /> * Start steht für 20: Im Log erschien bei jedem Start „Getting a lock required more than 20000 ms“, an zwei Stellen. Behoben<br /> <br /> * ToDo: aus früheren Installationen können DB Indizes vorhanden sein, die das Schreiben von Monitoringeinträgen der aktuellen Version verhindern.<br /> ** vor Update: Die Datenbank muss bereinigt werden:<br /> <syntaxhighlight lang="sql"><br /> ALTER TABLE monitor_sub_category DROP INDEX MONITOR_SUB_CATEGORYMSC_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYMCA_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYDK_INDEX;<br /> ALTER TABLE monitor_main_category DROP INDEX MONITOR_MAIN_CATEGORYMMCA_NAME_INDEX;<br /> ALTER TABLE monitor_component DROP INDEX MONITOR_COMPONENTI1;<br /> CREATE UNIQUE INDEX MONITOR_COMPONENTI1 ON monitor_component (MCO_NAME, MCO_INSTALLATION);<br /> </syntaxhighlight><br /> ** alternativ in der Eclipse.ini der Installation vor dem Update im Verzeichnis bdi-conf den Eintrag <code>-DFlyway.active=true</code> ergänzen.<br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4618 Releasenotes 2026 OS.Interchange 2026-10-28T13:49:40Z

<p>Mollik: /* Version 5.3.0.20261028 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261028 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012 OS.Softwarefactory 5.3.0.20261012] und früher<br /> * Fix verschiedener Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität<br /> * ToDo vor Update: Die Datenbank muss bereinigt werden:<br /> <syntaxhighlight lang="sql"><br /> ALTER TABLE monitor_sub_category DROP INDEX MONITOR_SUB_CATEGORYMSC_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYMCA_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYDK_INDEX;<br /> ALTER TABLE monitor_main_category DROP INDEX MONITOR_MAIN_CATEGORYMMCA_NAME_INDEX;<br /> ALTER TABLE monitor_component DROP INDEX MONITOR_COMPONENTI1;<br /> CREATE UNIQUE INDEX MONITOR_COMPONENTI1 ON monitor_component (MCO_NAME, MCO_INSTALLATION);<br /> </syntaxhighlight><br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4617 Releasenotes 2026 OS.Interchange 2026-10-28T13:49:04Z

<p>Mollik: /* Version 5.3.0.20261028 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261028 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012 OS.Softwarefactory 5.3.0.20261012] und früher<br /> * Fix verschiedener Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität<br /> * ToDo vor Update: Die Datenbank muss bereinigt werden:<br /> <syntaxhighlight lang="sql"><br /> ALTER TABLE monitor_sub_category DROP INDEX MONITOR_SUB_CATEGORYMSC_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYMCA_NAME_INDEX;<br /> ALTER TABLE monitor_category DROP INDEX MONITOR_CATEGORYDK_INDEX;<br /> ALTER TABLE monitor_main_category DROP INDEX MONITOR_MAIN_CATEGORYMMCA_NAME_INDEX;<br /> ALTER TABLE monitor_component DROP INDEX MONITOR_COMPONENTI1;<br /> CREATE UNIQUE INDEX MONITOR_COMPONENTI1 ON monitor_component (MCO_NAME, MCO_INSTALLATION);<br /> </syntaxhighlight><br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4616 Releasenotes 2026 OS.Interchange 2026-10-28T13:44:55Z

<p>Mollik: /* Version 5.3.0.20261028 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261028 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012 OS.Softwarefactory 5.3.0.20261012] und früher<br /> * Fix verschiedener Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität<br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4615 Releasenotes 2026 OS.Interchange 2026-10-28T09:57:19Z

<p>Mollik: /* Version 5.3.0.20261028 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261028 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012 OS.Softwarefactory 5.3.0.20261012] und früher<br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4614 Releasenotes 2026 OS.Interchange 2026-10-28T09:56:30Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.3.0.20261028 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4613 Releasenotes 2026 OS.Softwarefactory 2026-10-12T14:30:24Z

<p>Mollik: /* Version 5.3.0.20261012 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.peripheralssetup&diff=4612 Releasenotes 2026 OS.peripheralssetup 2026-10-12T09:23:46Z

<p>Mollik: /* Version 5.2.0.2026???? */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.2.0.20261012 ==<br /> <br /> * Installation des TSE Mockers, nicht aktiviert. Muss manuell aktiviert werden.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.peripherals&diff=4611 Releasenotes 2026 OS.peripherals 2026-10-12T09:22:52Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 1.2 vom 12.10.2026 ==<br /> <br /> === TSE Implementierung ===<br /> <br /> * Einführung eines TSE Mockers für Testzwecke<br /> <br /> == Version 1.2 vom 07.07.2026 ==<br /> <br /> === Virtuelle Peripheriegeräte und Diagnose ===<br /> * Erfassung des zuletzt gedruckten Belegs und der zuletzt angezeigten Zeilen über '''/lastSlip''' und '''/lastDisplay'''; rollierende 10-Zeilen-Historie der Kundenanzeige. <br /> * Das '''Tray-Icon''' zeigt die letzten Anzeigezeilen (neueste zuerst) als Ballon-Info. <br /> * Neue Schalter in der application.yml der Standardinstallation: '''virtualPrinter''', '''captureLastSlip''', '''virtualLineDisplay''', '''captureLastDisplay'''.<br /> <br /> * '''Verbindungsprobleme''' im HTTP-Client zwischen Tray/POS und Dienst behoben; die Verbindungslast wurde reduziert.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4610 Releasenotes 2026 OS.pos 2026-10-12T09:21:25Z

<p>Mollik: /* Version 5.3.0-V20261006 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261012 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen. Daneben wurde die Verfügbarkeitsprüfung der Webservices auf eine Implementierung zusammengeführt und ein Datumsfehler darin behoben.<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4609 Releasenotes 2026 OS.pos 2026-10-12T09:21:09Z

<p>Mollik: /* Version 5.3.0-V20261006 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist das '''Speicherwachstum des Kassendienstes''' über einen Verkaufstag: Ursachen gefunden, behoben und an einer Kasse nachgemessen. Daneben wurde die Verfügbarkeitsprüfung der Webservices auf eine Implementierung zusammengeführt und ein Datumsfehler darin behoben.<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4608 Releasenotes 2026 OS.pos 2026-10-12T09:20:01Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261012|Softwarefactory 20261012]]<br /> <br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4607 Releasenotes 2026 OS.Softwarefactory 2026-10-12T09:18:13Z

<p>Mollik: /* Version 5.3.0.20261012 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl (Entity,DTO):<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs. Da <code>src-gen</code> versioniert ist und der Jenkins-Build die eingecheckten Quellen übersetzt, müssen neu generierte DTOs eingecheckt werden.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4606 Releasenotes 2026 OS.Softwarefactory 2026-10-12T09:17:37Z

<p>Mollik: /* Version 5.3.0.20261012 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** org.eclipse.osbp.dsl:<br /> *** Fix: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> *** Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs. Da <code>src-gen</code> versioniert ist und der Jenkins-Build die eingecheckten Quellen übersetzt, müssen neu generierte DTOs eingecheckt werden.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> *** <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> *** Fix: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> *** Fix: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s<br /> ** Fix: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** org.eclipse.osbp.persistence: <br /> *** Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> *** Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4605 Releasenotes 2026 OS.Softwarefactory 2026-10-12T09:11:30Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261012 ==<br /> <br /> * OSBP Framework:<br /> ** Fix: org.eclipse.osbp.dsl: Speicherwachstum durch DTOs behoben (1) – <code>AbstractOppositeDtoList</code> und <code>MappingContext</code> deklarieren kein <code>finalize()</code> mehr. Jede <code>OppositeDtoList</code> und <code>OppositeContainmentDtoList</code> war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in <code>clear()</code>, <code>remove()</code> und <code>resolve()</code> abgemeldet<br /> ** Fix: org.eclipse.osbp.dsl: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse <code>DetachedEntityRef</code> in <code>org.eclipse.osbp.dsl.dto.lib</code>). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (<code>RepeatableWriteUnitOfWork</code> samt aller darin geklonten Entitäten), obwohl <code>LazyManyToOneResolver</code> nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper <code>initialize(entity)</code> vor <code>setId</code> aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. '''Der Generator (<code>DtoTypesBuilder</code>) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs. Da <code>src-gen</code> versioniert ist und der Jenkins-Build die eingecheckten Quellen übersetzt, müssen neu generierte DTOs eingecheckt werden.''' Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein <code>dto.lib</code> ab dem 07.10.2026 voraus<br /> ** org.eclipse.osbp.dsl: <code>LazyManyToOneResolver</code> meldet nun, welche Zeile er nicht nachladen konnte. Liefert <code>em.find</code> kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine <code>IllegalStateException</code> geworfen. Bisher erschien an dieser Stelle nur eine <code>NullPointerException</code> ohne Hinweis auf die Ursache<br /> ** Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) <code>SessionManager.removeSession()</code> gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (<code>ISession</code> hat kein <code>toString()</code>), das Sicherheitsnetz griff also nie. (b) <code>disposeTransactionHandler</code> entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. <code>ITransactionHandler</code> erhält dafür <code>isDisposable()</code> als Default-Methode. (c) Die Freigabe nach <code>transactionBegin</code>/<code>Commit</code>/<code>Rollback</code> steht nun in einem <code>finally</code>; ein <code>Error</code>, insbesondere ein <code>OutOfMemoryError</code>, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) <code>txnIsOpen</code> wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt<br /> ** Fix: org.eclipse.osbp.dsl: <code>AbstractDTOService.closeEntityManager()</code> fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung <code>dispose() refused</code> erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)<br /> ** Fix: org.eclipse.osbp.dsl: Mit <code>-DsendTransactionEventAsync=true</code> wartete <code>TransactionHandler.dispose()</code> nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während <code>SessionManager</code> die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. <code>dispose()</code> übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nichts<br /> ** Fix: org.eclipse.osbp.dsl: <code>MetadataBuilder</code> macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header <code>OSBP-RuntimeBuilder-BundleSpace</code> oder <code>Factory-Model</code> im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus <code>org.eclipse.osbp.system.configuration</code> nennt ein DTO aus <code>org.eclipse.osbp.system.configuration.base</code> mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte <code>activate()</code>, der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben<br /> ** org.eclipse.osbp.persistence: Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente <code>PersistenceStartupStatus</code> hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts<br /> ** org.eclipse.osbp.persistence: Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“<br /> ** Fix: org.eclipse.osbp.ecview.extension: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige <code>dropRows</code> frei; nach einem allgemeinen <code>ItemSetChange</code>, wie ihn <code>removeAllItems()</code> und <code>addAll()</code> auslösen, blieben sie im <code>KeyMapper</code> stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. <code>GridPresentation.CustomGrid</code> merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen<br /> ** Fix: org.osbee.datainterchange: FreeMarkers gemeinsam genutzte <code>InvalidReferenceException</code> hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs<br /> ** Fix: org.eclipse.osbp.display: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread<br /> ** org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft <code>barcode</code> für String-Attribute. Ein Attribut mit <code>key="barcode" value="QRCode-128"</code> wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über <code>BlobComponent</code> und <code>BlobUploadComponent</code> (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter<br /> ** org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * DSL:<br /> ** org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft <code>barcode</code> wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt<br /> <br /> * POS Framework:<br /> ** net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet <code>getCertificationId</code> in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch<br /> ** net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (<code>DetachedEntityRef</code>)<br /> <br /> * Build & Infrastruktur:<br /> ** net.osbee.installer.allinone: Die virtuelle TSE (Mock) wird zusammen mit dem Abschnitt „cryptovision TSE“ installiert – '''ausgeschaltet'''. Einen eigenen Installer-Abschnitt gibt es dafür nicht. <code>tse-config.txt</code> enthält die Connector-Zeile des Mocks als Kommentar sowie <code>mock.stateDir</code> unter <code>&lt;INSTDIR&gt; se�irtual-tse</code>, damit der Mock nie auf das Laufwerk einer echten TSE schreibt. Ist bei der Installation keine TSE angeschlossen und wird die Rückfrage „Unable to find TSE drive“ mit Nein beantwortet, bleibt eine vorhandene Konfiguration unverändert; gibt es noch keine, wird eine angelegt, die nur den ausgeschalteten Mock enthält<br /> ** net.osbee.installer.allinone: '''Der Mock läuft ausschließlich mit <code>tse.api-version: "MOCK"</code> in <code>application.yml</code>, und dieser Wert wird nur von Hand gesetzt''' – nicht mit <code>auto</code>, <code>2</code> oder <code>3</code>, und der Installer setzt ihn nie (auch <code>-Dtse.api-version</code> wird nicht mehr in <code>launch.bat</code> geschrieben). Eine Kasse kann damit nicht versehentlich auf ein Gerät geraten, dessen Signaturen keine Fiskaldaten sind. Der Peripherie-Server macht die Connector-Zeile beim Start nur bei <code>MOCK</code> aktiv und kommentiert sie bei jedem anderen Wert wieder aus (mit Datum und Grund, auch im Log); <code>VirtualTSE</code> verweigert außerdem die eigene Erzeugung, solange der Server nicht mit <code>MOCK</code> gestartet wurde. Mit <code>MOCK</code> arbeitet der Server direkt auf SE-API 2; der Umweg über die automatische Erkennung, der den ersten Start um etwa zwei Minuten verlängerte, entfällt. <code>application.yml</code> beschreibt die vier Werte<br /> ** net.osbee.installer.allinone: <code>tse/README.txt</code> beschreibt Betrieb, Ein- und Ausschalten sowie die Fehlersimulation der virtuellen TSE<br /> <br /> * Allgemein:<br /> ** net.osbee.softwarefactory: <code>CLAUDE.md</code> an den aktuellen Stand der Features angeglichen<br /> <br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4604 Releasenotes 2026 OS.pos 2026-10-12T09:10:23Z

<p>Mollik: /* Aktualisierungen */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4603 Releasenotes 2026 OS.pos 2026-10-12T09:09:20Z

<p>Mollik: /* Fehlerbehebungen */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB.<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> * '''Entitäten werden in der Entwicklungsumgebung auch bei inkrementellen Builds gewebt''' (<code>runOnIncremental</code> in <code>net.osbee.app.pos.common.entity/pom.xml</code>). Eine ohne Weaving neu übersetzte Entität führt zu einem leeren Dialog und zu Fehlern bei der nächsten Aktualisierung.<br /> * '''Nachweise zu den Speicherkorrekturen:''' Eigenständig lauffähige Tests unter <code>tools/</code> – <code>finalizer-proof</code>, <code>detached-entity-ref</code> (Verträglichkeit alter und neuer DTOs mit <code>dto.lib</code>), <code>grid-key-leak</code> und <code>freemarker-pin</code>.<br /> * '''Dokumentation:''' <code>MEMORY_GROWTH_FINDING.md</code> beschreibt Herkunft, Messwerte, verworfene Annahmen und Korrekturen des Speicherwachstums.<br /> <br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4602 Releasenotes 2026 OS.pos 2026-10-12T09:07:15Z

<p>Mollik: /* Neue Funktionen */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB. Nachgemessen in der Entwicklungsumgebung am 9. Oktober und an einer per Jenkins gebauten Installation am 12. Oktober (17 Verkäufe in zwei Messfenstern, Zähler im zweiten Fenster gleichbleibend bis fallend).<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten (<code>expectedclose</code>, <code>todos</code>, <code>lastfinished</code>, <code>tobefinished</code>) entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> * '''Entitäten werden in der Entwicklungsumgebung auch bei inkrementellen Builds gewebt''' (<code>runOnIncremental</code> in <code>net.osbee.app.pos.common.entity/pom.xml</code>). Eine ohne Weaving neu übersetzte Entität führt zu einem leeren Dialog und zu Fehlern bei der nächsten Aktualisierung.<br /> * '''Nachweise zu den Speicherkorrekturen:''' Eigenständig lauffähige Tests unter <code>tools/</code> – <code>finalizer-proof</code>, <code>detached-entity-ref</code> (Verträglichkeit alter und neuer DTOs mit <code>dto.lib</code>), <code>grid-key-leak</code> und <code>freemarker-pin</code>.<br /> * '''Dokumentation:''' <code>MEMORY_GROWTH_FINDING.md</code> beschreibt Herkunft, Messwerte, verworfene Annahmen und Korrekturen des Speicherwachstums.<br /> <br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4601 Releasenotes 2026 OS.pos 2026-10-12T09:06:40Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> === Neue Funktionen ===<br /> * '''NF 525 – Neustart durch den Bediener im Ereignisjournal:''' Ein über die Dienststeuerungsseite (<code>/restartService</code>) ausgelöster Neustart wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben, mit dem auslösenden Bediener. Bisher zeigte das Journal nur „System gestoppt“ und „System gestartet“, nicht aber, wer den Neustart veranlasst hat.<br /> * '''Speicher-Snapshot für den Kassendienst:''' Neues Werkzeug <code>tools/memory-snapshot</code> zur Weitergabe an Kunden. Es nimmt am selben Tag zwei Messungen desselben Prozesses (morgens und abends) und zeigt, was nach einer vollständigen Garbage Collection noch gehalten wird; der Vergleich benennt, welche Objektarten zwischen zwei Messungen gewachsen sind. Die Größe im Task-Manager sagt dazu nichts aus, weil der Dienst seinen Speicher beim Start reserviert.<br /> * '''Prüfung einer Installation vor der Messung:''' <code>tools/detached-entity-ref/verify-install.ps1</code> prüft lesend, ob eine installierte Kasse die Speicherkorrekturen tatsächlich enthält (Stand von <code>dto.lib</code>, Schalter, Anzahl der neu generierten DTOs je Bundle).<br /> <br /> === Fehlerbehebungen ===<br /> * '''Speicherwachstum je Verkauf:''' Die DTOs von <code>net.osbee.app.pos.common</code> wurden neu generiert und halten nur noch Klasse und ID ihrer Entität statt der Entität selbst. Zusammen mit den Korrekturen im Framework (siehe Releasenotes der Softwarefactory, Version 5.3.0.20261012) hält eine Kasse je Verkauf praktisch keinen Persistenzkontext mehr fest; vorher waren es rund 42 je Verkauf, etwa 1 MB. Nachgemessen in der Entwicklungsumgebung am 9. Oktober und an einer per Jenkins gebauten Installation am 12. Oktober (17 Verkäufe in zwei Messfenstern, Zähler im zweiten Fenster gleichbleibend bis fallend).<br /> * '''Kassenabschluss gibt seine Daten wieder frei:''' Nach dem Speichern eines Kassenabschlusses werden die dafür im Zustandsautomaten abgelegten Daten (<code>expectedclose</code>, <code>todos</code>, <code>lastfinished</code>, <code>tobefinished</code>) entfernt. Sie hielten über ihre Mapping-Kontexte alle Bons und Zahlungen der abgeschlossenen Periode bis zum nächsten Abschluss fest.<br /> * '''NF 525 – Ereignisjournal:''' Beim Anhängen eines Eintrags wird nicht mehr das gesamte Journal gelesen, um dessen letzten Eintrag zu finden. Der Aufwand je Eintrag wuchs bisher mit der Länge des Journals.<br /> * '''Webservice-Verfügbarkeitsprüfung über Mitternacht:''' Ein als nicht erreichbar vermerkter Webservice wurde nach Mitternacht zu spät oder gar nicht mehr erneut geprüft, weil der Zeitstempel als Millisekunden des Tages abgelegt war. Ein Ausfall um 20:00 Uhr hielt den Webservice bis 21:00 Uhr des Folgetags abgeschaltet, ein Ausfall ab 23:00 Uhr dauerhaft. Der Zeitstempel ist nun fortlaufend.<br /> <br /> === Aktualisierungen ===<br /> * '''Webservice-Verfügbarkeitsprüfung zusammengeführt:''' Die Prüfung existierte viermal (zweimal in <code>net.osbee.app.pos.common</code>, zweimal in <code>net.osbee.sample.pos</code>). Einzige Implementierung ist nun <code>WebService.check(sm, ws)</code> in <code>posbase</code>; die übrigen delegieren dorthin. Der Zustand wird je Webservice in <code>ws.accesible</code> geführt, der gemeinsame Speicherschlüssel entfällt.<br /> * '''Entitäten werden in der Entwicklungsumgebung auch bei inkrementellen Builds gewebt''' (<code>runOnIncremental</code> in <code>net.osbee.app.pos.common.entity/pom.xml</code>). Eine ohne Weaving neu übersetzte Entität führt zu einem leeren Dialog und zu Fehlern bei der nächsten Aktualisierung.<br /> * '''Nachweise zu den Speicherkorrekturen:''' Eigenständig lauffähige Tests unter <code>tools/</code> – <code>finalizer-proof</code>, <code>detached-entity-ref</code> (Verträglichkeit alter und neuer DTOs mit <code>dto.lib</code>), <code>grid-key-leak</code> und <code>freemarker-pin</code>.<br /> * '''Dokumentation:''' <code>MEMORY_GROWTH_FINDING.md</code> beschreibt Herkunft, Messwerte, verworfene Annahmen und Korrekturen des Speicherwachstums.<br /> <br /> <br /> == Version 5.3.0-V20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4600 Releasenotes 2026 OS.pos 2026-10-06T12:41:48Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Ergänzung bei Kundenkartenverarbeitung<br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. <br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4599 Releasenotes 2026 OS.Interchange 2026-10-06T12:39:15Z

<p>Mollik: /* Version 5.2.0.20261006 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4598 Releasenotes 2026 OS.Interchange 2026-10-06T12:38:31Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> <br /> == Version 5.2.0.20261006 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20261006 OS.Softwarefactory 5.3.20261006] und früher<br /> <br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4597 Releasenotes 2026 OS.Softwarefactory 2026-10-06T12:37:11Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20261006 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.<br /> ** Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.<br /> ** Das eingebettete <code>shiro-all-1.2.3.jar</code> wurde durch <code>shiro-core</code> und <code>shiro-web</code> in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. <code>encoder-1.2.3.jar</code> kommt hinzu, weil <code>shiro-web</code> 1.13 <code>org.owasp.encoder</code> zwingend importiert.<br /> ** Anmeldung: <br /> *** Fix: <code>LDAPRealm</code> löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (<code>invalidDNSyntax</code>), sodass ein <code>userDnTemplate</code> von <code>{0}</code> zwar anmeldete, dann aber an den Attributen scheiterte. <code>resolveUserDn</code> sucht nun über <code>userPrincipalName</code>, <code>sAMAccountName</code> oder <code>mail</code>; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form <code>cn={0},ou=...</code> verhalten sich unverändert. Zugleich behoben: eine <code>StringIndexOutOfBoundsException</code> im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als <code>{0}</code>, von JNDI maskiert)<br /> *** Fix: <code>LDAPRealm.getUserDn</code> maskierte nur das Komma. <code>escapeDnValue</code> deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann<br /> *** Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.<br /> *** Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, <code>SameSite=Lax</code> und unter https mit <code>Secure</code> geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt<br /> *** Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in <code>AuthenticationProvider.check()</code> (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde<br /> *** Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: <code>Userinterface/showResetPasswordOnScreen</code>, standardmäßig aus, mit Protokollierung auf WARN. '''Installationen ohne Mailserver müssen den Parameter einmalig setzen'''<br /> *** Fix: <code>doResetPassword</code> hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über <code>doUnlock</code><br /> ** System Configuration: <br /> *** Parameter <code>RememberMeSecret</code> in <code>IConfigurationService</code> ergänzt (<code>GLOBAL_PARAMETERS/RememberMeSecret</code>). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.<br /> *** Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. <code>ConfigurationService.getConfigurationString</code> speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass <code>addConfiguration</code> stets eine weitere Zeile anhängte. <code>addConfiguration</code> entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. <code>deleteConfigurations</code> setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder<br /> <br /> * Build & Infrastruktur:<br /> ** Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle <code>org.eclipse.osbp.dependencies.bundle.activemq.all.osgi</code> enthält kein Log4j und kein eingebettetes slf4j mehr. <code>activemq-all</code> brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter <code>JDBCAppender</code>, <code>JMSAppender</code>, <code>JMSSink</code> und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und <code>slf4j-log4j12</code>. <code>Include-Resource</code> bindet das Hersteller-Jar nun ohne <code>org.apache.log4j</code>, <code>org.slf4j</code>, deren Maven-Koordinaten, die <code>log4j.properties</code> und Springs <code>Log4jConfigurer</code> ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (<code>org.slf4j.api</code> 1.7.36)<br /> <br /> * UI & Themes:<br /> ** Neue Dienststeuerungsseite unter <code>/restartService</code>. <br /> *** Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg<br /> *** Alle Aktionen der Dienststeuerungsseite werden im <code>MonitoringService</code> unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren<br /> <br /> <br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4596 Releasenotes 2026 OS.pos 2026-09-07T19:16:21Z

<p>Mollik: /* Version 5.3.0-V20260907 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht.<br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> * '''Kennwort vergessen?:''' Zurücksetzen des Kennworts löst eine Benutzersperre nicht mehr automatisch auf. Dies muss aktiv durch den Administrator geschehen.<br /> * '''showResetPasswordOnScreen:''' neuer Konfigurationsschlüssel. Default: false. Bei true wird das neue Passwort im Log angezeigt, falls lein Mailserver kongiguriert ist.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4595 Releasenotes 2026 OS.pos 2026-09-07T13:58:26Z

<p>Mollik: /* Änderungen / Neue Funktionen */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht.<br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''remember me Anmeldefunktion:''' überarbeitet, Cookieverwendung sicherer gemacht.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4594 Releasenotes 2026 OS.pos 2026-09-07T13:56:43Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht.<br /> <br /> === Änderungen / Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> <br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> <br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4593 Releasenotes 2026 OS.pos 2026-09-07T13:55:36Z

<p>Mollik: /* Aktualisierungen */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht.<br /> <br /> === Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> <br /> === Fehlerbehebungen ===<br /> <br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> <br /> === Aktualisierungen ===<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> * '''Bondruck:''' NF-525-Daten ergänzt<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4592 Releasenotes 2026 OS.pos 2026-09-07T13:54:47Z

<p>Mollik: /* Neue Funktionen */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht.<br /> <br /> === Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis:''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate:''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade:''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> <br /> === Fehlerbehebungen ===<br /> <br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> <br /> === Aktualisierungen ===<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4591 Releasenotes 2026 OS.pos 2026-09-07T13:53:34Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> Schwerpunkt dieses Zeitraums ist die französische Fiskalkonformität '''NF 525''' (WORM-Sicherungseinrichtung, Write-once-Nachweis, Geräte-Lebenszyklus) sowie die Auslagerung des '''DSFinV-K'''-Datenmodells. Alle Änderungen liegen auf dem Branch <code>development</code> und sind nach <code>origin/development</code> gepusht.<br /> <br /> === Neue Funktionen ===<br /> <br /> * '''Ausgeschlossene Zahlarten:''' Die Perspektive für ausgeschlossene Zahlungsarten wurde zur Kundenpflege verschoben.<br /> * '''Benutzerverwaltung:''' Die automatische Synchronisierung der einzelnen views in der Benutzerverwaltungsperspektive wurde abgeschaltet.<br /> <br /> * '''NF 525 – WORM Write-once-Nachweis (v16):''' Ein zertifiziertes WORM-Gerät darf Fiskalverkäufe erst nach einem signierten <code>PROTECTED</code>-Verdikt tragen. Ein asynchroner Probe-Lauf weist die Write-once-Eigenschaft nach (das Medium nimmt eine Teständerung zurück); der Verdikt wird signiert und ist „sticky". ''(cache-defeat probe, verbreiterte Signaturspalte)''<br /> * '''NF 525 – Zertifizierungs-Gate (v17):''' Auf einem zertifizierten Gerät führen Struktur-/Integritätsfehler zu einem harten Verkaufsstopp (STOP_SALES); auf einem nicht-zertifizierten Gerät wird die Anomalie nur als Warnung protokolliert (warn-only) und dem Kassierer als Hinweis am Verkauf angezeigt.<br /> * '''NF 525 – Reaktivierung der Write-once-Bestätigung:''' Der zuvor pausierte Bestätigungs-Block wurde wieder aktiviert; der Scheduler führt ein zertifiziertes Gerät nun wieder von <code>PENDING</code> nach <code>PROTECTED</code>.<br /> * '''NF 525 – Schutz gegen Zertifizierungs-Downgrade (§7.3):''' Eine bereits fiskalisch aktive, zertifizierte Kasse kann nicht mehr auf ein nicht-zertifiziertes oder entferntes Sicherungsgerät umgestellt werden (Geräte-Tausch), und ein zertifiziertes Gerät kann nicht mehr in-place ent-zertifiziert werden. Beide Wege werden abgewiesen (Umgehung der zertifizierten Durchsetzung verhindert).<br /> * '''NF 525 – Auditierung von Geräte-Konfigurationsänderungen:''' Eine Änderung an der zertifizierungsrelevanten WORM-Konfiguration wird als signiertes Ereignis in das Ereignisjournal (JET) geschrieben.<br /> * '''NF 525 – Retention/Archivierung beim Geräte-Tausch:''' Perioden ohne Fiskaldatensätze werden nicht mehr als leeres ZIP archiviert, sondern als schlanker „abgedeckt"-Marker vermerkt (kein Medium-Scan) – die „Gespeichert"-Rückmeldung nach einem Geräte-Tausch kommt dadurch deutlich schneller. Zum Abschluss wird eine Zusammenfassung protokolliert.<br /> <br /> === Fehlerbehebungen ===<br /> <br /> * '''Authentifizierung:''' Die Authentifizierungs-Logger wurden zusammengefasst und schreiben wieder in eine Datei.<br /> * '''NF 525 – Write-once-Probe:''' Die Anwesenheit der Probe-Datei wird nun über eine frische Verzeichnis-Enumeration gelesen (behebt eine Fehlerkennung durch veraltete Verzeichnis-Zwischenstände).<br /> <br /> === Aktualisierungen ===<br /> * '''Internationalisierung:''' Neue NF-525-WORM-Schlüssel (Write-once, worm_protection, warn-only) in das zentrale Übersetzungsbündel gespiegelt; allgemeine Vokabular-Erweiterungen.<br /> * '''Rechnungsdruck (Invoice2p):''' NF-525-Daten in der Rechnungsvorlage berücksichtigt.<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Softwarefactory&diff=4590 Releasenotes 2026 OS.Softwarefactory 2026-09-07T13:47:46Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0.20260907 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles<br /> ** Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.<br /> ** Verbesserung der Übersetzungen<br /> ** Anpassungen für frz. Fiskalanforderungen<br /> <br /> == Version 5.3.0.20260707 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.<br /> ** Verbesserungen bei der frz. Tastaturunterstützung<br /> ** Verbesserungen der Übersetzungen<br /> <br /> == Version 5.3.0.20260618 ==<br /> <br /> * OSBP Framework (Allgemein):<br /> ** Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.<br /> ** Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt<br /> ** Login bezieht Build-Version und Hersteller nun aus den <code>BundleUtilities</code> (einheitliche Quelle)<br /> ** Neue gemeinsame Hilfsmethoden <code>getBuildVersion()</code>/<code>getVendor()</code> in <code>BundleUtilities</code> zur Ermittlung der Build-Identität<br /> ** <code>MonitoringService</code> setzt die Zeitstempel von <code>lastError</code> und <code>lastWarning</code> nicht mehr zurück<br /> ** Fix: NPE in <code>org.eclipse.osbp.xtext.dialog.AutowireUiFactory</code> behoben<br /> ** Version von 5.2.0 auf 5.3.0 angehoben<br /> <br /> * UI & Themes:<br /> ** Neues Icon <code>action-reverify</code> (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung<br /> ** Neues Icon <code>action-refresh.png</code> ergänzt<br /> ** Grid – horizontale Bildlaufleiste wiederhergestellt<br /> ** Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)<br /> ** französische Übersetzungen überarbeitet<br /> <br /> * Grammatiken/Generierung:<br /> ** org.eclipse.osbp.dsl: Benutzerdefinierte <code>@PreRemove</code>-Hooks werden in der generierten <code>preRemove()</code>-Methode zusammengeführt<br /> ** org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format<br /> <br /> * POS Framework für franz. Fiskalanforderungen eingeführt<br /> <br /> == Version 5.2.0.20260410 ==<br /> <br /> * POS Framework: <br /> ** Performanceverbesserung beim Kassieren<br /> ** Multi-Protokoll Unterstützung für Paymentterminal <br /> *** frz. Protokolle "Concert", "Protocol E"<br /> *** "Mock" für Tests<br /> *** Statemachine DSL erweitert: protocol Parameter für Paymentterminal<br /> *** "Shared Payment Terminal"<br /> **** locking im PaymentTerminalService implementiert<br /> **** pro Terminal über ConfigService einstellbar<br /> <br /> == Version 5.2.0.20260402 ==<br /> <br /> Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm<br /> <br /> * OSBP Framework:<br /> ** Anzeige des Persistenzservice-Status auf dem Login-Bildschirm<br /> ** Information über den Persistenzservice auf der Fehlerseite hinzugefügt<br /> ** Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet<br /> <br /> * BPM:<br /> ** Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben<br /> <br /> * POS Framework:<br /> ** Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben<br /> <br /> == Version 5.2.0.20260305 ==<br /> <br /> === Report Anzeige ===<br /> <br /> Diese Version konzentriert sich auf '''Stabilitätsverbesserungen''' für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.<br /> <br /> * Race Condition beim Report-Rendering<br /> ** '''Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden'''<br /> *** Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen<br /> *** Filteränderungen werden blockiert, während ein Render-Vorgang läuft<br /> *** Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet<br /> *** Reports mit <code>selectById</code> werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist<br /> <br /> * PDF-Anzeigeskalierungsproblem <br /> ** '''Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering'''<br /> <br /> === Anmeldebildschirm ===<br /> <br /> Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.<br /> <br /> * Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services<br /> * Deaktivierung aller Anmeldesteuerelemente während der Wartezeit<br /> <br /> === Start der Anwendung ===<br /> <br /> * Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert. <br>Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.pos&diff=4589 Releasenotes 2026 OS.pos 2026-09-07T13:44:47Z

<p>Mollik: </p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.3.0-V20260907 ==<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260907|Softwarefactory 5.2.0.20260907]]<br /> <br /> == Version 5.3.0-V20260707 ==<br /> <br /> Diese Ausgabe bringt vor allem die Unterstützung französischer Kassen voran: eine<br /> vollständige AZERTY-Tastaturunterstützung (physisch und als Bildschirmtastatur), das<br /> französische Zahlungsterminal-Protokoll CAISSE-AP inklusive Simulator sowie virtuelle<br /> Peripheriegeräte für Test und Diagnose. Ergänzt wird dies durch NF525-Härtungen,<br /> Fehlerbehebungen bei Kartenzahlungen und eine durchgängige Vereinheitlichung der<br /> Übersetzungsdateien.<br /> <br /> * Die '''physische französische AZERTY-Tastatur''' wird nun vollständig unterstützt. Der komplette Zeichensatz wurde auf realer Hardware getestet; die zuvor fehlende '''ù-Taste''' wurde ergänzt.<br /> * Die '''Bildschirmtastatur''' (On-Screen-Keypad) <br /> ** bildet nun eine echte französische AZERTY-Belegung über alle drei Ebenen ab (Grundebene, Umschalt, AltGr) inklusive Akzentkomposition über die Tottasten ^ und ¨.<br /> ** folgt jetzt '''einheitlich der Oberflächensprache''': Französisch → AZERTY, Englisch → englische Belegung, alle übrigen Sprachen → deutsches QWERTZ. Die Belegung wird beim Öffnen des Dialogs in der aktiven Sprache neu aufgebaut.<br /> * Neue Konfiguration '''Hardware/&lt;host&gt;-KeyboardCountry''' zur Auswahl der physischen Tastaturbelegung je Kasse.<br /> <br /> * '''CAISSE-AP – französisches Zahlungsterminal'''<br /> ** Unterstützung des '''Tagesabschlusses (télécollecte)''' für Concert/CAISSE-AP-Terminals; die obligatorischen Felder CB und CE werden nun sowohl in der Abschluss- als auch in der Abbruch-Anfrage übertragen.<br /> <br /> * NF525 / Fiskalkonformität<br /> ** Die '''Persistierung des Grand-Totals''' ist nun zwingende Vorbedingung für die Signatur eines Belegs – verhindert eine Signatur bei unvollständig gespeichertem Umsatzzähler. ''(net.osbee.app.pos.common d5a4578ec)''<br /> <br /> * Kartenzahlung<br /> ** Eine Kartenzahlung kann nun korrekt '''storniert''' werden: das Belegfeld (receipt) wird aus dem CJ-Feld der Concert-Antwort befüllt.<br /> ** Das '''Löschen einer nicht stornierbaren Terminal-Zahlung''' wird blockiert, um inkonsistente Zustände zu vermeiden. <br /> ** setPaymentTerminalReversal stürzt bei einer fehlerhaften Anfrage nicht mehr ab. <br /> <br /> * Oberfläche / Internationalisierung ===<br /> ** Die '''Laufzeit-Sprachumschaltung''' funktioniert nun in der Kassierperspektive<br /> ** Zentrale Übersetzungen aktualisiert<br /> <br /> * Systemvoraussetzungen ===<br /> ** Für den französischen Markt: Zahlungsterminal mit CAISSE-AP-/Concert-Protokoll (CB-Port 8888, konfigurierbae), physische AZERTY-Tastatur optional<br /> ** Konfiguration je Kasse über Hardware/&lt;host&gt;-KeyboardCountry und Hardware/&lt;host&gt;-KeyboardLayout<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260707|Softwarefactory 5.2.0.20260707]]<br /> <br /> == Version 5.3.0-V20260618 ==<br /> <br /> * Version von 5.2 auf 5.3<br /> * frz. Fiskalanforderungen: erste Implementierung<br /> * frz. Übersetzungen aktualisiert<br /> * Verwendung frz. Tastatur in Kassiersicht<br /> <br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260618|Softwarefactory 5.3.0.20260618]]<br /> <br /> == Version 4.5.7-V20260410 (OS) ==<br /> <br /> * Allgemein:<br /> ** Fix Performanceproblem ( eingeführt mit 4.5.7-V20260402 (OS) ), dbcaching Einstellungen<br /> <br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260410|Softwarefactory 5.2.0.20260410]]<br /> <br /> == Version 4.5.7-V20260402 (OS) ==<br /> <br /> * Kassiervorgang:<br /> ** Automatischer Wechsel zum Status <code>PAYMENTTERMINAL_REPEATRECEIPT</code> im Modus 'store' (statt 'print') bei leeren Bonzeilen<br /> ** Neue Funktion <code>attachRemarks</code> zum Zeichnen von Bonbemerkungen und deren Verknüpfung mit dem Kassenbon<br /> ** Möglichkeit zur Eingabe von freien Bemerkungen zum Kassenbon<br /> ** Bonbemerkungen: <code>observeFocus</code> von remark1/2 an Events gebunden<br /> <br /> * Kassenkonfiguration:<br /> ** Menüeintrag für Stammdaten der Bonbemerkungen hinzugefügt<br /> <br /> * Datenmodell:<br /> ** Neue Entitäten für Bonbemerkungen (SlipRemarks)<br /> ** Neue Spalten <code>remark_1</code> und <code>remark_2</code> für CashSlip-Entität<br /> ** Dialoge, Tabellen und Perspektive für Bonbemerkungen implementiert<br /> <br /> <br /> == Version 4.5.7.20260305 (OS) ==<br /> * Verwendung der aktuellen [[Releasenotes_2026_OS.Softwarefactory#Version_5.2.0.20260305|Softwarefactory 5.2.0.20260305]]<br /> <br /> * Berichtanzeige<br /> ** Fix: Probleme bei der Berichtsanzeige mit schneller Klickfolge in Auswahltabelle behoben.<br /> <br /> * Kassenschluss:<br /> ** Fix: <code>determineCloseExpectation</code> - Sortierung von CashPaymentTermData nach traceNumber absteigend, um den letzten Eintrag zu erhalten<br /> <br /> * Kassenentsorgung:<br /> ** Neues Systemprodukt "fee" aktiviert<br /> <br /> * Datenmodell:<br /> ** Einige Entitäten auf <code>cacheable=false</code> gesetzt<br /> ** Entitäten mit escaped Spaltennamen aktualisiert<br /> ** Generierte Entitäten und DTOs aktualisiert<br /> ** Entitäten mit neuem Service Framework aktualisiert<br /> <br /> * Kassiervorgang:<br /> ** Fix: <code>canUnparkSelected</code> - Ablehnung eines Slips mit Zahlungen an einer SiS-Kasse<br /> ** Fix: PRINT_SLIP - <code>onOK</code> verlässt nicht, wenn Slip änderbar ist<br /> ** Neue Eingabeaktion für MODIFY_FLD, setzt <code>cashposiupdate</code> auf ausgewählte Position<br /> <br /> * Archivierung:<br /> ** <code>archivDescription xml-os</code> für XML-Format der Beschreibungsdatei für Archiv hinzugefügt</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4588 Releasenotes 2026 OS.Interchange 2026-08-04T15:14:33Z

<p>Mollik: /* Version 5.2.0.20260707 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707] und früher</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4587 Releasenotes 2026 OS.Interchange 2026-08-04T15:13:54Z

<p>Mollik: /* Version 5.2.0.20260707 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 OS.Softwarefactory 5.3.20260707]</div>

Mollik https://download.osbee.org/documentation/index.php?title=Releasenotes_2026_OS.Interchange&diff=4586 Releasenotes 2026 OS.Interchange 2026-08-04T15:13:30Z

<p>Mollik: /* Version 5.2.0.20260707 */</p> <hr /> <div>__TOC__<br /> <br /> == [[Releasenotes | --> zurück zu Releasenotes ]] ==<br /> <br /> == Version 5.2.0.20260707 ==<br /> <br /> * Build mit aktueller Softwarefactory <br>Änderung siehe [https://download.osbee.org/documentation/index.php/Releasenotes_2026_OS.Softwarefactory#Version_5.3.0.20260707 5.3.20260707]</div>

Mollik