StefanMoCoAt
4b6a242372
Some checks failed
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Failing after 59s
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Successful in 6m6s
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Successful in 6m10s
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Failing after 1m13s
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Successful in 1m51s
Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
40 lines
2.0 KiB
Markdown
40 lines
2.0 KiB
Markdown
# Journal: 16. April 2026 - Veranstalter-Wizard Integration
|
|
|
|
## 🏗️ Status Quo
|
|
|
|
Nach dem erfolgreichen ZNS-Import (ZIP und .dat) wurde der "Neue Veranstaltung" Wizard erweitert. Im ersten Schritt ("
|
|
Daten-Akquise & Veranstalter") wurde die Möglichkeit geschaffen, direkt einen neuen Veranstalter manuell anzulegen,
|
|
falls dieser nicht in den ZNS-Daten oder im Bestand gefunden wurde.
|
|
|
|
## ✅ Änderungen
|
|
|
|
### 1. Frontend: Veranstaltung-Wizard (V2)
|
|
|
|
- **Datei:** `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/VeranstaltungScreens.kt`
|
|
- **Feature:** Implementierung des Buttons `+ Neuen Veranstalter anlegen` in Schritt 1 des
|
|
Veranstaltungs-Konfigurations-Wizards.
|
|
- **Workflow:**
|
|
- Der Button öffnet den bereits existierenden `VeranstalterAnlegenWizard` in einem Modal-Dialog.
|
|
- Nach erfolgreicher Anlage des Vereins/Veranstalters wird dessen ID automatisch als `selectedVereinId` gesetzt.
|
|
- Der Wizard springt sofort zu Schritt 2 ("Basisdaten"), um den Flow für den User zu beschleunigen.
|
|
- **UI/UX:** Design-konforme Umsetzung mit `OutlinedButton`, Icon und primärer Akzentfarbe.
|
|
|
|
### 2. Backend: Masterdata Service Check
|
|
|
|
- **Verifizierung:** Der `masterdata-service` (Ktor/Spring Hybrid) verfügt bereits über den `VereinController` mit
|
|
`POST /verein`.
|
|
- **Datenmodell:** Das `Verein`-Domainmodell und die `VereinTable` (Exposed) unterstützen alle für die Vision 03
|
|
relevanten Felder (OEPS-Nummer, Kontakt, Adresse, istVeranstalter).
|
|
- **Status:** Keine weiteren Backend-Änderungen notwendig, da die API bereits für manuelle Erfassungen (Datenquelle:
|
|
`MANUAL`) ausgelegt ist.
|
|
|
|
## 🧹 Curator Hinweis
|
|
|
|
Die Session wurde mit der erfolgreichen Verknüpfung der beiden Wizard-Flows abgeschlossen. Der ZNS-First Ansatz wird nun
|
|
durch eine einfache manuelle Ausweichoption für neue Veranstalter ergänzt.
|
|
|
|
**Nächste Schritte:**
|
|
|
|
- Test des vollständigen "Happy Path": Manueller Veranstalter -> Veranstaltungs-Basisdaten -> Finalisierung.
|
|
- Validierung der Login-Daten-Versendung (Identity/Mail Service) nach der manuellen Anlage.
|