StefanMoCoAt 9195cdb14d ### feat: verbessere Wizard-Validierung und UI-Feedback

- Integriere Fortschrittsanzeige während der Veranstalter-Suche (`isCheckingStats`).
- Zeige Fehlermeldungen bei Suchfehlern im `EventWizardScreen`.
- Füge `hasSelectedVeranstalter`-Guard und zugehörige Tests hinzu.
- Präzisiere `DemoEventFlow` mit expliziter Guard-Logik.
- Aktualisiere Unit-Tests zur Abdeckung neuer Guard-Szenarien.

2026-04-21 21:26:06 +02:00

3.6 KiB

Raw Blame History

🧹 [Curator] Session-Log – ZNS-Validierung & UI-Fixes

Datum: 2026-04-21 · Kontext: Desktop-First, Offline-First · Initiative: Masterdata-Validierung & ZNS-Importer

Zusammenfassung

In dieser Session wurde die Brücke zwischen der Wizard-Runtime und dem ZNS-Importer geschlagen. Wir haben die Validierungs-Logik für Stammdaten professionalisiert und einen kritischen UI-Bug im Login-Flow behoben.

Erreichte Ergebnisse

UI-Fix (Frontend):
- Behebung des "Anmelden"-Buttons im ConnectivityCheck-Screen. Der Callback wurde in der ContentArea.kt korrekt an das PingScreen durchgereicht.
Validierungs-Logik (Lead Architect & Rulebook Expert):
- Erhöhung der Guard-Präzision in DemoEventFlow: Der hasZns-Guard prüft nun nicht mehr nur auf die reine Existenz von Daten, sondern auch auf das Vorhandensein eines gültigen Import-Datums (lastImport).
Wizard-Integration (Frontend):
- EventWizardViewModel: Einführung von reEvaluateCurrentStep(), um den Wizard-Status reaktiv auf Daten-Eingaben und Stammdaten-Updates zu aktualisieren.
- Automatischer Step-Forward: Sobald neue Stammdaten erkannt werden (z. B. nach einem ZNS-Import), springt der Wizard automatisch zum nächsten Schritt.
- EventWizardScreen: Der eingebettete StammdatenImportScreen nutzt nun reEvaluateCurrentStep(), um einen nahtlosen Übergang nach dem Import zu ermöglichen.
Stabilität:
- Erfolgreiche Kompilierung des Desktop-Shell-Moduls (:frontend:shells:meldestelle-desktop).
- Wizard-Unit-Tests (JVM/Common) sind vollständig grün (10/10).
Fehlerbehebung (QA):
- Korrektur von WizardRuntimeJvmTest.selection_goes_to_ansprechperson_when_guard_true_by_default, der aufgrund unvollständiger Testdaten (fehlendes ORG- Präfix) fehlschlug.

Verifikation

Gradle: ./gradlew :frontend:shells:meldestelle-desktop:compileKotlinJvm läuft fehlerfrei durch.
Logic: Reaktivität des ViewModels durch Einbindung von reEvaluateCurrentStep() in alle relevanten State-Änderungen sichergestellt.

Nächste Schritte

Implementierung der "Veranstalter-Validierung" gegen den lokalen Store im zweiten Wizard-Schritt (Prüfung der OEBS-Nummer).
Vorbereitung der Delta-Sync-Logik für den Abgleich mit der Cloud.
Optimierung der ZNS-Importer-Performance für große Datensätze.

🏗️ [Lead Architect] | 👷 [Backend Developer] | 🎨 [Frontend Expert] | 🧹 [Curator]

Repository-Strategie & Veranstalter-Validierung

Um die Veranstalter-Wahl im Wizard robust zu gestalten, nutzen wir eine zweistufige Repository-Strategie:

VereinRepository (Lokal): Primäre Quelle für bereits bekannte oder manuell angelegte Vereine. Wenn ein Verein hier gefunden wird, gilt er als "validiert" für den Wizard.
MasterdataRepository / ZnsImportProvider (Global/Remote): Fallback-Quelle. Falls die OEPS-Nummer lokal unbekannt ist, wird in den (offline verfügbaren) ZNS-Stammdaten gesucht. Ein Fund hier führt zur Übernahme der Daten in den lokalen Kontext.

Wizard-Guards

hasZns: Stellt sicher, dass überhaupt Stammdaten vorhanden sind (Initial-Check).
hasSelectedVeranstalter: Verhindert das Voranschreiten im Wizard, solange kein gültiger Veranstalter (lokale ID) ausgewählt wurde.
needsContactPerson: Dynamische Weiche; erzwingt die manuelle Eingabe einer Ansprechperson, wenn der Veranstalter-Datensatz unvollständig ist (z.B. neue ZNS-Importe ohne hinterlegte Kontaktperson).

Diese Strategie sichert die Datenqualität beim Erstellen neuer Veranstaltungen, während sie dem User maximale Flexibilität (Import vs. Neuanlage) bietet.

3.6 KiB Raw Blame History Unescape Escape