chore: entferne veraltete Architekturdokumente
Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -1,24 +0,0 @@
|
||||
# Session Log: Behebung Flyway Migrations-Fehler im Ping-Service
|
||||
**Datum:** 2026-04-03
|
||||
**Agent:** Backend Developer / Curator
|
||||
|
||||
## Problembeschreibung
|
||||
Der `ping-service` ließ sich via Docker nicht starten und warf eine `FlywayMigrateException` mit der Ursache `ERROR: relation "ping" does not exist`.
|
||||
Die Log-Analyse zeigte, dass die Datenbankmigration `V2__seed_data.sql` fehlgeschlagen ist, weil die vorausgehende Migration `V1__init_ping.sql` (in der die Tabelle `ping` erstellt wird) offensichtlich nicht ausgeführt wurde.
|
||||
|
||||
## Ursachenanalyse
|
||||
Die `application.yaml` des `ping-service` enthielt die Konfiguration `baseline-on-migrate: true`. Wenn mehrere Services (z. B. `masterdata-service`, `ping-service` etc.) dieselbe PostgreSQL-Datenbank (`pg-meldestelle-db`) und standardmäßig das Schema `public` nutzen, teilen sie sich ohne weitere Konfiguration die gleiche Flyway-Historientabelle (`flyway_schema_history`).
|
||||
|
||||
Wenn ein anderer Service bereits Migrationen ausgeführt oder die Datenbank initialisiert hatte, setzte Flyway für den `ping-service` eine Baseline mit Version `1`. Infolgedessen ignorierte Flyway die Datei `V1__init_ping.sql` und versuchte direkt, `V2__seed_data.sql` auszuführen. Dies führte zum Scheitern der Migration, da die notwendige Struktur aus `V1` fehlte.
|
||||
|
||||
## Lösung
|
||||
1. **Isolierung der Flyway-Historientabelle:** In der `application.yaml` des `ping-service` wurde die Property `spring.flyway.table: flyway_schema_history_ping` hinzugefügt. Dadurch verwaltet der `ping-service` seinen eigenen Migrationsstatus unabhängig von anderen Services in der gleichen Datenbank.
|
||||
2. **Anpassung der Baseline-Version:** Es wurde explizit `spring.flyway.baseline-version: "0"` konfiguriert, um sicherzustellen, dass V1-Skripte stets als Teil der Historie betrachtet werden, selbst falls Flyway in einer nicht leeren Datenbank ansetzt.
|
||||
|
||||
## Geänderte Dateien
|
||||
* `/mocode/Meldestelle/backend/services/ping/ping-service/src/main/resources/application.yaml`
|
||||
* `/mocode/Meldestelle/docs/05_Backend/Services/PingService_Reference.md` (Dokumentation aktualisiert)
|
||||
|
||||
## Nächste Schritte
|
||||
* Die Infrastruktur sollte nun stabil hochfahren. (Ggf. Ping Service im Docker Stack neustarten).
|
||||
* Diese Best Practice (spezifische `flyway.table` pro Service) sollte zukünftig auch bei anderen Microservices angewandt werden, die sich dasselbe DB-Schema teilen, um Konflikte zu vermeiden.
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: Curator
|
||||
last_update: 2026-04-10
|
||||
---
|
||||
# Journal Entry: 2026-04-10 - Billing Service Setup & ZNS Importer Hardening
|
||||
|
||||
## 👷 [Backend Developer] / 🏗️ [Lead Architect] / 🧹 [Curator]
|
||||
|
||||
### Zusammenfassung der Session
|
||||
In dieser Session wurde das Fundament für den Kassa-Service (`billing-context`) gelegt und die Robustheit des ZNS-Importers durch zusätzliche Integrationstests für Funktionäre gesteigert.
|
||||
|
||||
### Wichtigste Ergebnisse
|
||||
1. **Billing Service Initialisierung & API:**
|
||||
* `billing-service` Modul erstellt, konfiguriert und mit `core-domain` (Serialisierung) verknüpft.
|
||||
* Exposed-Tabellendefinitionen (v1) für `TeilnehmerKonto` und `Buchung` implementiert.
|
||||
* `BillingController` mit REST-Endpunkten für Konten, Buchungen und Historie erstellt.
|
||||
* `TeilnehmerKontoService` um API-Methoden (`getKontoById`, `getKonto`, `getBuchungsHistorie`, `buche`) erweitert.
|
||||
* Integrationstests (`TeilnehmerKontoServiceTest`) erfolgreich mit H2-In-Memory-DB durchgeführt.
|
||||
* **OpenAPI-Dokumentation:** `documentation.yaml` für `billing-service` erstellt und CRUD-Endpunkte für Konten und Buchungen dokumentiert.
|
||||
2. **Entries-Integration (Neu):**
|
||||
* Automatische Buchung von Nenngeld und Nachnenngebühren bei Einreichung einer Nennung implementiert.
|
||||
* Erweiterung der `Bewerb`-Entität um Finanzfelder (`nenngeld_cent`, `nachnenngebuehr_cent`).
|
||||
* Neue Flyway-Migration `V8__add_bewerb_financial_fields.sql` im `entries-service` hinzugefügt.
|
||||
* `NennungUseCases` nutzt nun den `TeilnehmerKontoService` zur automatischen Belastung der Teilnehmerkonten (negativer Saldo).
|
||||
* `EntriesServiceApplication` scannt nun auch `at.mocode.billing` Pakete für die Cross-Context Integration.
|
||||
3. **ZNS-Importer Hardening:**
|
||||
* Erweiterung von `ZnsImportServiceTest` um Tests für mehrfache Qualifikationen und die Update-Strategie (Delete+Insert) bei Funktionären (`RICHT01.dat`).
|
||||
* Alle 11 Integrationstests sind erfolgreich durchgelaufen.
|
||||
4. **Kompilations-Fixes (Billing):**
|
||||
* `billing-service` auf korrekte Exposed DSL Syntax (`selectAll().where { ... }`) umgestellt.
|
||||
* Explizite `transaction { ... }` Blöcke in `TeilnehmerKontoService` eingeführt.
|
||||
* Typ-Konsistenz für `Instant` (kotlin.time) in `billing-domain` zur Übereinstimmung mit `core-domain` hergestellt.
|
||||
|
||||
### Betroffene Dateien
|
||||
- `backend/services/billing/` (Neuer SCS-Kontext)
|
||||
- `backend/infrastructure/zns-importer/src/test/kotlin/at/mocode/zns/importer/ZnsImportServiceTest.kt`
|
||||
|
||||
### Nächste Schritte
|
||||
- [x] Integration des Billing-Services in den `entries-context` (automatische Buchung bei Nennung).
|
||||
- [x] Fix von Kompilationsfehlern und Test-Regressionen (H2/Exposed Kompatibilität).
|
||||
- UI-Anbindung im Frontend für Kontenübersicht und manuelle Buchungen.
|
||||
- Erweiterung der Abrechnungs-Logik (z.B. Rechnungserstellung als PDF).
|
||||
|
||||
### Technische Details & Fixes
|
||||
- **Exposed / H2:** `TIMESTAMPTZ` in Flyway-Migrationen auf `TIMESTAMP WITH TIME ZONE` umgestellt, um H2-Kompatibilität in Integrationstests zu gewährleisten.
|
||||
- **Multi-Tenancy:** `ExposedTenantTransactions` unterstützt nun sowohl PostgreSQL (`SET search_path`) als auch H2 (`SET SCHEMA`).
|
||||
- **Billing Config:** `BillingDatabaseConfiguration` ist nun robust gegen fehlende JDBC-URLs (wichtig für modularisierte Tests).
|
||||
|
||||
---
|
||||
*Co-authored-by: Junie <junie@jetbrains.com>*
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-04-14
|
||||
---
|
||||
|
||||
# Session Log: Fix Kotlin Wasm JS Compilation OOM
|
||||
|
||||
## Problem
|
||||
Die Kompilierung des Moduls `:frontend:features:billing-feature` für `wasmJs` schlug mit einem `java.lang.OutOfMemoryError: GC overhead limit exceeded` fehl.
|
||||
|
||||
Ursache war die Verwendung von `material-icons-extended` in Kombination mit den bisherigen JVM-Speichereinstellungen (6GB). Da `material-icons-extended` tausende generierte Icon-Dateien enthält, stößt der Kotlin/Wasm-Compiler bei der IR-Lowering-Phase an seine Grenzen.
|
||||
|
||||
## Lösung
|
||||
1. **Speichererhöhung:** Die JVM-Heap-Einstellungen in `gradle.properties` wurden von 6GB auf 8GB erhöht.
|
||||
- `kotlin.daemon.jvmargs` wurde auf `-Xmx8g` gesetzt.
|
||||
- `org.gradle.jvmargs` wurde auf `-Xmx8g` gesetzt, wobei die Optionen für den Kotlin-Daemon (`-Dkotlin.daemon.jvm.options`) auf `-Xmx6g` erhöht wurden.
|
||||
2. **Verifizierung:** Die Kompilierung von `:frontend:features:billing-feature:compileProductionLibraryKotlinWasmJs` wurde nach einem Daemon-Restart erfolgreich durchgeführt.
|
||||
|
||||
## Betroffene Dateien
|
||||
- `gradle.properties`: Erhöhung der Speicherlimits.
|
||||
- `frontend/features/billing-feature/build.gradle.kts`: (Kurzzeitig getestet ohne `materialIconsExtended`, aber wieder aktiviert, da Icons daraus benötigt werden).
|
||||
|
||||
## Handover
|
||||
- Zukünftig sollte bei weiteren OOM-Problemen im Wasm-Bereich geprüft werden, ob `material-icons-extended` durch eine selektive Icon-Einbindung (z.B. als Ressourcen) ersetzt werden kann, um den Compiler zu entlasten.
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-04-14
|
||||
---
|
||||
|
||||
# Session Log: Finalize and Enable Entries Isolation Integration Test
|
||||
|
||||
## Problem
|
||||
Der Test `EntriesIsolationIntegrationTest` im Modul `:backend:services:entries:entries-service` war deaktiviert (`@Disabled`). Er hatte Probleme mit der Daten-Isolierung zwischen verschiedenen Tenants, wenn Exposed mit mehreren Schemas und PostgreSQL-Containern verwendet wurde.
|
||||
|
||||
Zusätzlich gab es IDE-Warnungen bezüglich nicht auflösbarer Symbole in SQL-Strings, redundantem `runBlocking` und ungenutzten Variablen.
|
||||
|
||||
## Lösung
|
||||
1. **Test-Bereinigung:**
|
||||
- Entfernung der `@Disabled` Annotation.
|
||||
- Behebung der `runBlocking` Redundanz durch Verwendung von `runBlocking` auf Test-Methoden-Ebene.
|
||||
- Entfernung ungenutzter Variablen (`saved`).
|
||||
- Bereitstellung einer `@TestConfiguration` mit einem Mock `JwtDecoder`, um ApplicationContext-Ladefehler durch Security-Abhängigkeiten zu vermeiden.
|
||||
|
||||
2. **Schema-Isolierung fixiert:**
|
||||
- Umstellung der Tabellen-Erstellung im `setup` auf JDBC, um zu verhindern, dass Exposed's `Table`-Singletons frühzeitig an ein falsches Schema gebunden werden.
|
||||
- Sicherstellung, dass `tenantTransaction` den `search_path` in PostgreSQL korrekt setzt.
|
||||
- Explizite Verwendung von `SET search_path` innerhalb der Transaktionen im Isolationstest, um Leaks zu vermeiden.
|
||||
- Verifizierung der Isolation: Schreibzugriffe in `event_a` landen nun nachweislich nicht mehr in `event_b`.
|
||||
|
||||
3. **Verifizierung & Cleanup:**
|
||||
- Alle 10 Tests im Modul (inkl. der neu aktivierten Isolation-Tests) laufen erfolgreich durch.
|
||||
- IDE-Warnungen in `EntriesIsolationIntegrationTest` und `JdbcTenantRegistryTest` wurden durch `@Suppress("SqlResolve")`, Verwendung von String-Konstanten/Interpolation (`$CONTROL_SCHEMA`) und Entfernung ungenutzter Code-Fragmente (`nennungRepository`, `random()`, `registerDataSource`) behoben.
|
||||
- Typos wie "testdb" -> "test_db" und "Produktions" -> "Production" wurden korrigiert.
|
||||
- Behebung von IDE-Warnungen in `NennungBillingIntegrationTest`, `BewerbeZeitplanIntegrationTest` und `DomainHierarchyMigrationTest` durch Entfernung ungenutzter Variablen (`result`), Ersetzen von Umlauten in Funktionsnamen/Strings durch ASCII-Zeichen und Verwendung von Konstanten für Schema-Namen (`TEST_SCHEMA`).
|
||||
- Fehlende Spring-Konfigurations-Metadaten für `multitenancy.*` wurden in `additional-spring-configuration-metadata.json` ergänzt.
|
||||
|
||||
## Betroffene Dateien
|
||||
- `backend/services/entries/entries-service/src/test/kotlin/at/mocode/entries/service/tenant/EntriesIsolationIntegrationTest.kt`: Reaktiviert und repariert.
|
||||
- `backend/services/entries/entries-service/src/test/kotlin/at/mocode/entries/service/tenant/JdbcTenantRegistryTest.kt`: Bereinigt und optimiert.
|
||||
- `backend/services/entries/entries-service/src/main/resources/META-INF/additional-spring-configuration-metadata.json`: Metadaten ergänzt.
|
||||
|
||||
## Handover
|
||||
- Der `EntriesIsolationIntegrationTest` dient nun als Referenz für Multi-Tenancy Tests mit echten PostgreSQL-Containern. Bei weiteren Tests dieser Art sollte auf das Exposed-Schema-Caching geachtet werden.
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-04-14
|
||||
---
|
||||
|
||||
# Session Log: Fix Entries Service Integration Tests (EOFException / PostgreSQL Connection)
|
||||
|
||||
## Problem
|
||||
Die Integrationstests im Modul `:backend:services:entries:entries-service` (`BewerbeZeitplanIntegrationTest`, `NennungBillingIntegrationTest`) schlugen mit einer `FlywaySqlUnableToConnectToDbException` (verursacht durch `PSQLException: EOFException`) fehl.
|
||||
|
||||
Ursache war das Fehlen einer `application-test.yaml`. Dadurch wurden die Standardwerte aus `application.yaml` geladen, welche eine aktive PostgreSQL-Instanz auf `localhost:5432` sowie Consul und Flyway-Migrationen erwarteten. In der CI/Test-Umgebung ohne diese Infrastruktur führte der Verbindungsversuch zum Abbruch.
|
||||
|
||||
## Lösung
|
||||
1. **Test-Konfiguration erstellt:** Eine neue Datei `backend/services/entries/entries-service/src/test/resources/application-test.yaml` wurde angelegt.
|
||||
- Umstellung auf H2 In-Memory Datenbank (`jdbc:h2:mem:entries-test`).
|
||||
- Deaktivierung von Flyway (`spring.flyway.enabled=false`), da die Tests Tabellen manuell via Exposed `SchemaUtils` anlegen.
|
||||
- Deaktivierung von Consul Discovery (`spring.cloud.consul.enabled=false`).
|
||||
- Umstellung der Multitenancy-Registry auf `inmem`.
|
||||
2. **Verifizierung:** Die Tests im Modul wurden mit `./gradlew :backend:services:entries:entries-service:test` erfolgreich durchgeführt (5 Tests bestanden, 1 übersprungen/disabled).
|
||||
|
||||
## Betroffene Dateien
|
||||
- `backend/services/entries/entries-service/src/test/resources/application-test.yaml`: Neue Konfiguration für das `test` Profil.
|
||||
|
||||
## Handover
|
||||
- Die `EntriesIsolationIntegrationTest` bleibt weiterhin `@Disabled`, da sie Testcontainers benötigt und laut Quellcode-Kommentar noch weitere Fixes für die Exposed-Metadaten-Isolierung erfordert.
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
agent: 🏗️ Lead Architect & 🧐 QA Specialist
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
# 📜 Session-Abschluss: Stabilisierung & Security-Fix Ping-Service (Update)
|
||||
|
||||
## 🎯 Zusammenfassung
|
||||
|
||||
In dieser Session wurde die fehlerhafte Authentifizierung des **Ping-Service (ConnectivityCheck)** bei Zugriffen via Postman und externen Clients behoben. Die Hauptursache war ein **Issuer-Mismatch** im JWT-Token zwischen der internen Docker-Infrastruktur (`keycloak:8080`) und der externen Sicht des Clients (`localhost:8180`).
|
||||
|
||||
## ✅ Erreichte Meilensteine
|
||||
|
||||
### 1. Diagnose & Ursachenanalyse
|
||||
- **Issuer-Mismatch:** Spring Security validiert standardmäßig den `iss` Claim. Da Keycloak im Docker-Netzwerk einen anderen Hostnamen hat als für den externen Client, schlug die Validierung fehl (401 Unauthorized), obwohl der Token an sich gültig war.
|
||||
- **Autorisierungs-Lücke:** Der Ping-Service (Resource Server) und das Gateway lehnten Token ab, deren Issuer nicht exakt der konfigurierten `issuer-uri` entsprach.
|
||||
|
||||
### 2. Flexibilisierung der Security-Validierung
|
||||
- **Custom JWT Decoder (Gateway):** Implementierung eines `ResilienceReactiveJwtDecoder`, der die Issuer-Validierung überspringt, aber weiterhin Signatur und Zeitstempel prüft. Dies ermöglicht den nahtlosen Wechsel zwischen Docker-internen und externen Aufrufen.
|
||||
- **Custom JWT Decoder (Ping-Service):** Analog wurde in der `GlobalSecurityConfig` ein `JwtDecoder` konfiguriert, der auf die strikte Issuer-Prüfung verzichtet.
|
||||
|
||||
### 3. Security Hardening & Konsistenz
|
||||
- **CORS-Fix:** Die `allowedHeaders` im Gateway wurden auf `*` gesetzt, um Inkompatibilitäten mit Postman-Headern zu vermeiden.
|
||||
- **Endpunkt-Konsistenz:** Die Postman-Tests für `secure`, `sync` (authentifiziert) und `enhanced` (authentifiziert) sind nun wieder erfolgreich, da das Gateway und der Service den Token korrekt akzeptieren.
|
||||
|
||||
## 🛠️ Technische Änderungen
|
||||
|
||||
- `backend/infrastructure/gateway/src/main/kotlin/at/mocode/infrastructure/gateway/security/SecurityConfig.kt`: Neuer `ResilienceReactiveJwtDecoder` mit deaktiviertem Issuer-Check.
|
||||
- `backend/infrastructure/security/src/main/kotlin/at/mocode/infrastructure/security/GlobalSecurityConfig.kt`: Explizite `JwtDecoder` Bean zur Umgehung des Issuer-Mismatches hinzugefügt.
|
||||
- `backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json`: Refactoring und Erweiterung der Connectivity-Tests.
|
||||
|
||||
## 🚀 Status-Report
|
||||
|
||||
Alle Connectivity-Endpunkte (Simple, Health, Public, Sync, Secure, Enhanced) sind nun sowohl öffentlich als auch authentifiziert (je nach Anforderung) erreichbar. Die Infrastruktur ist robuster gegenüber Umgebungsunterschieden (Local vs. Docker) geworden.
|
||||
|
||||
**Status:** Authentifizierung stabilisiert und Issuer-Mismatch behoben. 🟢
|
||||
@@ -1,28 +0,0 @@
|
||||
# Journal: 19. April 2026 - Backend Stabilität & Desktop UX-Refinement
|
||||
|
||||
## 🏗️ Backend: Infrastruktur & Mail-Service
|
||||
|
||||
* **Mail-Service:** Konflikt beim Request-Mapping behoben. Der redundante `NennungController` wurde entfernt und seine Funktionalität (Status-Update, Erstellung) in den zentralen `MailController` integriert.
|
||||
* **Health-Checks:** `spring-boot-starter-actuator` zum `entries-service` hinzugefügt, um die 404-Fehler in der Consul-Überwachung zu eliminieren.
|
||||
* **Mail-Features:** Neuer Endpunkt `POST /send-reply` im `MailController` implementiert, um Bestätigungs-Mails an Nenner mit dynamischer Absenderadresse (Turnier-spezifisch) zu senden.
|
||||
|
||||
## 💻 Desktop-App: Navigation & UI
|
||||
|
||||
* **Veranstaltungs-Konfiguration:** White-Screen Fix durch Korrektur der Navigation im `DesktopMainLayout.kt`. Es wird nun korrekt auf den `VeranstaltungKonfigScreen` aus dem Feature-Modul verwiesen.
|
||||
* **Device-Setup:** UX-Verbesserung durch Entfernung blockierender `onKeyEvent` Handler. Die Navigation zwischen Feldern mittels **Tab** und **Enter** funktioniert nun reibungslos über den Standard-Fokus-Flow.
|
||||
* **Design-System:**
|
||||
* Suchfeld-Höhe in `MsFilterBar.kt` auf `44.dp` erhöht, um abgeschnittenen Text bei kleinen Schriftarten zu verhindern.
|
||||
* `MsMasterDetailLayout` im Vereins-Bereich um einen **Preview-Bereich** (Card-Ansicht) erweitert.
|
||||
|
||||
## 🚀 Neue Features
|
||||
|
||||
### Nennungs-Eingang
|
||||
* **Antwort-Funktion:** Ein neuer Button "Antwort & Übernahme" im Detail-Dialog ermöglicht das direkte Versenden einer Bestätigungs-Mail an den Nenner.
|
||||
* **Sortierung:** Die Liste wird nun standardmäßig mit neuen Nennungen (`NEU`) zuerst sortiert.
|
||||
|
||||
### Vereins-Verwaltung
|
||||
* **Card-Preview:** Der obere Teil des Detail-Bereichs zeigt nun eine visuelle Vorschau des Vereins (Name, Status, Ort).
|
||||
* **Logo-Support:** Das Domain-Modell und der Editor wurden um ein `logoUrl` Feld erweitert, um Vereinslogos (z.B. für nicht registrierte Vereine) zu hinterlegen.
|
||||
|
||||
## 🧹 Curator Hinweis
|
||||
Alle gemeldeten Start-Fehler im Backend wurden behoben. Die Desktop-App ist nun voll navigierbar und bietet verbesserte Effizienz für die Meldestellen-Mitarbeiter.
|
||||
@@ -1,30 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Billing-Feature Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 🎨 [Frontend Expert] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `billing-feature` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`) unter Verwendung von `device-initialization` als Referenz.
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` von `at.mocode.clients` auf `at.mocode.frontend.features` geändert (Alignment mit neuem Namensraum).
|
||||
* `wasmJsMain` Source-Set explizit mit `kotlin.stdlib.wasm.js` Dependency konfiguriert.
|
||||
* Struktur der Source-Sets an die Referenz angepasst.
|
||||
|
||||
2. **Strukturelle Anpassungen:**
|
||||
* Verzeichnisse `src/jvmMain/kotlin/at/mocode/frontend/features/billing/` und `src/wasmJsMain/kotlin/at/mocode/frontend/features/billing/` erstellt, um die Blueprint "Consistency Rule" zu erfüllen.
|
||||
* Die Paketstruktur in `commonMain` war bereits konsistent (`at.mocode.frontend.features.billing`).
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:features:billing-feature:assemble` wurde erfolgreich ausgeführt.
|
||||
* Sowohl JVM- als auch WasmJS-Targets kompilieren fehlerfrei.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Fortführung der Feature-Migration mit dem nächsten Modul in der Liste (z.B. `pferde-feature` oder `profile-feature`).
|
||||
* Sicherstellen, dass alle Referenzen auf das `billing-feature` (z.B. im `turnier-feature`) weiterhin funktionieren (ggf. Gradle-Projektpfade prüfen, falls diese sich ändern würden, was hier nicht der Fall war, da nur die `group` ID in Gradle geändert wurde, nicht der Pfad).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,29 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Core-Domain Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `frontend/core/domain` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`, da Plattform-spezifische `PlatformType` Implementierungen vorhanden sind).
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit `auth` & `design-system`).
|
||||
* `version` auf `1.0.0` gesetzt.
|
||||
* `wasmJsMain` Source-Set explizit mit `kotlin.stdlib.wasm.js` Dependency konfiguriert, um die KMP-Web-Infrastruktur zu vervollständigen.
|
||||
|
||||
2. **Strukturelle Analyse:**
|
||||
* Die Paketstruktur `at.mocode.frontend.core.domain` war bereits vorbildlich und konsistent über alle Source-Sets (`commonMain`, `jvmMain`, `wasmJsMain`) hinweg.
|
||||
* `PlatformType` nutzt das `expect/actual` Pattern korrekt.
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:core:domain:assemble` wurde erfolgreich ausgeführt.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Migration der weiteren Core-Module (`network`, `sync`, `localDb`).
|
||||
* Anpassung der Feature-Module (Batch 1: Source-Set Topologie).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,30 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Core-LocalDb Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `frontend/core/local-db` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`, da es KMP-spezifische Treiber-Implementierungen für JVM und WasmJS enthält).
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit anderen Core-Modulen).
|
||||
* `version` auf `1.0.0` gesetzt.
|
||||
* SqlDelight Konfiguration und Source-Sets waren bereits korrekt für Multiplatform (JVM & WasmJS) vorbereitet.
|
||||
|
||||
2. **Strukturelle Analyse:**
|
||||
* Die Paketstruktur `at.mocode.frontend.core.localdb` ist konsistent über alle Source-Sets hinweg.
|
||||
* `DatabaseDriverFactory` nutzt das `expect/actual` Pattern korrekt.
|
||||
* `src/wasmJsMain` ist vorhanden und enthält die notwendige `sqlite.worker.js` und Web-Treiber Implementierung.
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:core:local-db:assemble` wurde erfolgreich ausgeführt.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Migration der verbleibenden Core-Module (`network`, `sync`).
|
||||
* Batch-Update der Feature-Module (Source-Set Struktur & Group-IDs).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,30 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Core-Navigation Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 🎨 [Frontend Expert] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `frontend/core/navigation` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`, da es die Navigationslogik für die UI-Shells bereitstellt).
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit anderen Core-Modulen).
|
||||
* `version` auf `1.0.0` gesetzt.
|
||||
* `jvmMain` und `wasmJsMain` Source-Sets konfiguriert.
|
||||
* `kotlin.stdlib.wasm.js` als Dependency für WasmJS hinzugefügt.
|
||||
|
||||
2. **Strukturelle Anpassungen:**
|
||||
* Verzeichnisse `src/jvmMain/kotlin/at/mocode/frontend/core/navigation/` und `src/wasmJsMain/kotlin/at/mocode/frontend/core/navigation/` erstellt, um die Blueprint "Consistency Rule" zu erfüllen.
|
||||
* Die Paketstruktur war bereits vorbildlich konsistent.
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:core:navigation:assemble` wurde erfolgreich ausgeführt.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Migration der verbleibenden Core-Module (`network`, `sync`).
|
||||
* Batch-Anpassung der Group-IDs in den Feature-Modulen (`at.mocode.frontend.features`).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,30 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Core-Network Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `frontend/core/network` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`).
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit anderen Core-Modulen).
|
||||
* `version` auf `1.0.0` gesetzt.
|
||||
* Die bestehende Multiplatform-Konfiguration (KMP) wurde als bereits blueprint-konform verifiziert.
|
||||
|
||||
2. **Strukturelle Analyse:**
|
||||
* Die Paketstruktur `at.mocode.frontend.core.network` ist bereits konsistent über alle Source-Sets (`commonMain`, `jvmMain`, `wasmJsMain`) hinweg.
|
||||
* Plattform-spezifische Implementierungen (z.B. `PlatformConfig`, `JmDnsDiscoveryService`) sind korrekt in den jeweiligen Source-Sets platziert.
|
||||
* WasmJS-Unterstützung ist strukturell und in Gradle bereits vorbereitet.
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:core:network:assemble` wurde erfolgreich ausgeführt.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Migration des letzten verbleibenden Core-Moduls (`sync`).
|
||||
* Anschließend Batch-Anpassung der Feature-Module (Topologie & Group-IDs).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,30 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Core-Sync Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `frontend/core/sync` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`, da es KMP-spezifische Sync-Strategien unterstützen soll).
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit anderen Core-Modulen).
|
||||
* `version` auf `1.0.0` gesetzt.
|
||||
* `jvmMain` und `wasmJsMain` Source-Sets konfiguriert.
|
||||
* `kotlin.stdlib.wasm.js` als Dependency für WasmJS hinzugefügt.
|
||||
|
||||
2. **Strukturelle Anpassungen:**
|
||||
* Verzeichnisse `src/jvmMain/kotlin/at/mocode/frontend/core/sync/` und `src/wasmJsMain/kotlin/at/mocode/frontend/core/sync/` erstellt, um die Blueprint "Consistency Rule" zu erfüllen.
|
||||
* Die Paketstruktur war bereits vorbildlich konsistent (`at.mocode.frontend.core.sync`).
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:core:sync:assemble` wurde erfolgreich ausgeführt.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Die Migration der Core-Module (`frontend/core/*`) ist hiermit weitgehend abgeschlossen.
|
||||
* Nächster großer Block: Batch-Anpassung der Feature-Module (`frontend/features/*`) bezüglich Topologie (WasmJS-Ordner) und Group-IDs (`at.mocode.frontend.features`).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,33 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Design-System Blueprint Migration
|
||||
|
||||
## 🏗️ [Lead Architect] | 🎨 [Frontend Expert] | 🧹 [Curator]
|
||||
**Datum:** 2026-04-19
|
||||
**Status:** ✅ Abgeschlossen
|
||||
|
||||
### 🎯 Ziel
|
||||
Migration des `design-system` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`).
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Gradle Konfiguration (`build.gradle.kts`):**
|
||||
* `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit `auth` Referenz).
|
||||
* `wasmJsMain` Source-Set explizit mit `kotlin.stdlib.wasm.js` Dependency konfiguriert.
|
||||
* Version auf `1.0.0` fixiert.
|
||||
|
||||
2. **Strukturelle Anpassungen:**
|
||||
* Verzeichnis `src/wasmJsMain/kotlin/at/mocode/frontend/core/designsystem/` erstellt, um die Blueprint "Consistency Rule" zu erfüllen.
|
||||
* Paket-Migration in `jvmMain`:
|
||||
* `at.mocode.wui.preview` -> `at.mocode.frontend.core.designsystem.preview`
|
||||
* `Multipreview.kt` verschoben und Package-Deklaration aktualisiert.
|
||||
* Damit ist die Paketstruktur nun konsistent über alle Source-Sets hinweg.
|
||||
|
||||
3. **Verifizierung:**
|
||||
* `./gradlew :frontend:core:design-system:assemble` wurde erfolgreich ausgeführt.
|
||||
* Alle Ziel-Plattformen (JVM & WasmJS) kompilieren fehlerfrei.
|
||||
|
||||
### 🚩 Nächste Schritte
|
||||
* Fortsetzung der Migration mit den nächsten Core-Modulen (z.B. `network`, `domain`) oder den Feature-Modulen.
|
||||
* Batch-Anpassung der Group-IDs in den Feature-Modulen.
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,33 +0,0 @@
|
||||
# Journal: Finalisierung der Frontend-Blueprint-Migration
|
||||
|
||||
**Datum:** 19. April 2026
|
||||
**Status:** Abgeschlossen
|
||||
**Agent:** 🏗️ [Lead Architect] | 🧹 [Curator]
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
Nach der großflächigen Migration der Core- und Feature-Module wurden im letzten Schritt verbleibende strukturelle Inkonsistenzen in den Modulen `ping-feature` und `turnier-feature` bereinigt. Ziel war die vollständige Einhaltung des **Module Structure Blueprint** (Klasse B).
|
||||
|
||||
## 🛠️ Durchgeführte Änderungen
|
||||
|
||||
### 1. Paket-Synchronisierung (`ping-feature`)
|
||||
* Das veraltete Paket `at.mocode.ping.feature` wurde konsistent in `at.mocode.frontend.features.ping` umbenannt.
|
||||
* Dies betraf die Source-Sets `commonMain`, `jvmMain` und `commonTest`.
|
||||
* Die physische Verzeichnisstruktur wurde von `at/mocode/ping/feature/` nach `at/mocode/frontend/features/ping/` verschoben.
|
||||
|
||||
### 2. Paket-Synchronisierung (`turnier-feature`)
|
||||
* Das veraltete Paket `at.mocode.turnier.feature` wurde konsistent in `at.mocode.frontend.features.turnier` umbenannt.
|
||||
* Betroffen waren alle Ebenen (`commonMain`, `jvmMain`, `wasmJsMain`) inklusive Unterpakete für `data`, `domain` und `presentation`.
|
||||
* Die physische Verzeichnisstruktur wurde analog zum Standard angepasst.
|
||||
|
||||
### 3. Shell-Integration
|
||||
* Die Importe in `frontend/shells/meldestelle-desktop` wurden an die neuen Paketnamen angepasst, um die Lauffähigkeit der Desktop-App sicherzustellen.
|
||||
* Die `meldestelle-web` Shell wurde ebenfalls verifiziert.
|
||||
|
||||
## ✅ Verifizierung
|
||||
* `./gradlew :frontend:features:ping-feature:assemble`: **ERFOLGREICH**
|
||||
* `./gradlew :frontend:features:turnier-feature:assemble`: **ERFOLGREICH**
|
||||
* `./gradlew :frontend:shells:meldestelle-desktop:assemble`: **ERFOLGREICH**
|
||||
* `./gradlew :frontend:shells:meldestelle-web:assemble`: **ERFOLGREICH**
|
||||
|
||||
## 🧹 Fazit
|
||||
Mit diesem Schritt ist die strukturelle Bereinigung des Frontends abgeschlossen. Alle Module (Core, Features, Shells) folgen nun einem einheitlichen Namens- und Struktur-Schema. Die "Consistency Rule" des Blueprints ist somit im gesamten Frontend-Projekt erfüllt.
|
||||
@@ -1,29 +0,0 @@
|
||||
# Journal: Fehlerbehebung PingSyncIntegrationTest nach Blueprint-Migration
|
||||
|
||||
**Datum:** 19. April 2026
|
||||
**Status:** Abgeschlossen
|
||||
**Agent:** 🧐 [QA Specialist] | 🏗️ [Lead Architect]
|
||||
|
||||
## 🎯 Problemstellung
|
||||
Nach der großflächigen Umbenennung der Pakete und der Migration der Feature-Module auf den neuen Blueprint traten Kompilierfehler im Modul `ping-feature` auf, speziell im `PingSyncIntegrationTest.kt`.
|
||||
|
||||
### Fehlermeldungen:
|
||||
* `Unresolved reference 'FakePingEventRepository'`: Die Mock-Klasse für den Test fehlte.
|
||||
* `Unresolved reference 'it'`: Typ-Inferenz-Fehler aufgrund der fehlenden Repository-Klasse.
|
||||
|
||||
## 🛠️ Durchgeführte Änderungen
|
||||
|
||||
### 1. Wiederherstellung der Test-Infrastruktur
|
||||
* Die Klasse `FakePingEventRepository` wurde im Verzeichnis `frontend/features/ping-feature/src/commonTest/kotlin/at/mocode/frontend/features/ping/integration/` neu erstellt.
|
||||
* Sie implementiert das `SyncableRepository<PingEvent>` Interface und ermöglicht die Verifizierung der synchronisierten Daten im Integrationstest.
|
||||
|
||||
### 2. Korrektur des Integrationstests
|
||||
* In `PingSyncIntegrationTest.kt` wurden die fehlenden Importe (insbesondere `at.mocode.ping.api.PingEvent`) hinzugefügt.
|
||||
* Die Lambda-Ausdrücke in den Assertions wurden verifiziert; durch die Anwesenheit der `FakePingEventRepository` Klasse funktioniert die Typ-Inferenz von Kotlin nun wieder korrekt, und die Referenzen auf `it.id` und `it.message` werden aufgelöst.
|
||||
|
||||
## ✅ Verifizierung
|
||||
* `./gradlew :frontend:features:ping-feature:compileTestKotlinJvm`: **ERFOLGREICH**
|
||||
* `./gradlew :frontend:features:ping-feature:jvmTest`: **ERFOLGREICH** (Alle Tests bestanden)
|
||||
|
||||
## 🧹 Fazit
|
||||
Die Test-Suite für das `ping-feature` ist nun wieder vollständig und blueprint-konform. Die Entkopplung durch das `SyncableRepository` wurde im Test erfolgreich durch das Fake-Repository validiert.
|
||||
@@ -1,44 +0,0 @@
|
||||
# Journal: Behebung von 500er Fehlern im Ping-Service & Security-Fixes
|
||||
|
||||
**Datum:** 19. April 2026
|
||||
**Status:** Abgeschlossen
|
||||
**Agent:** 🏗️ [Lead Architect] | 🧐 [QA Specialist] | 🧹 [Curator]
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
Nach der gestrigen Umstrukturierung traten beim `ping-service` HTTP 500 Fehler bei autorisierten API-Aufrufen auf. Ziel war die Identifikation der Ursachen (Security, Parameter-Mapping, Resilience) und deren Behebung sowie die Aktualisierung der Testsuite.
|
||||
|
||||
## 🛠️ Durchgeführte Änderungen
|
||||
|
||||
### 1. Security-Mapping & Rollen-Korrektur
|
||||
* Im `PingController` wurden die `@PreAuthorize`-Annotationen korrigiert. Da der `KeycloakRoleConverter` das Präfix `ROLE_` hartkodiert hinzufügt und die Rollen in Großbuchstaben umwandelt, wurden die Prüfungen von `MELD_USER` auf `ROLE_MELD_USER` (bzw. `ROLE_MELD_ADMIN`) angepasst.
|
||||
* Der Import der `AccessDeniedException` im `PingExceptionHandler` wurde auf die korrekte Spring Security Klasse fixiert, um 403-Fehler sauber zu fangen und nicht in 500er zu verwandeln.
|
||||
|
||||
### 2. API-Konsistenz & Parameter-Mapping
|
||||
* Der Query-Parameter für `/api/ping/sync` wurde explizit auf `lastSyncTimestamp` gemappt, um mit dem Postman-Aufruf und den Anforderungen des Frontends konsistent zu sein.
|
||||
|
||||
### 3. Resilience4j & Coroutines
|
||||
* Die Bibliothek `resilience4j-kotlin` wurde in die `libs.versions.toml` aufgenommen und im `ping-service` eingebunden. Dies stellt sicher, dass der `@CircuitBreaker` korrekt mit Kotlin `suspend` Funktionen zusammenarbeitet und Exceptions nicht unkontrolliert durchschlagen.
|
||||
|
||||
### 4. Test-Aktualisierung
|
||||
* `PingControllerTest.kt` wurde angepasst, um den neuen Parameter-Namen `lastSyncTimestamp` zu verwenden.
|
||||
* Alle 5 Tests im `PingControllerTest` verlaufen nun erfolgreich.
|
||||
|
||||
## ✅ Verifizierung
|
||||
* `./gradlew :backend:services:ping:ping-service:test`: **ERFOLGREICH** (5/5 Tests passed)
|
||||
* Manueller Check der Parameter-Namen gegen Postman-Anforderungen: **ERFOLGREICH**
|
||||
* Verifizierung des Rollen-Mappings im `KeycloakRoleConverter` gegen Controller-Annotationen: **KONSISTENT**
|
||||
|
||||
## 🧹 Fazit
|
||||
Die "letzte Meile" der Service-Kommunikation ist nun stabil. Durch das verbesserte Exception-Handling und die korrekte Resilience-Integration liefert der Service nun aussagekräftige HTTP-Statuscodes statt generischer 500er Fehler.
|
||||
|
||||
### Nachtrag 20:30
|
||||
* **Networking-Fix:** `GlobalSecurityConfig` angepasst, um `jwk-set-uri` primär aus Spring-Properties oder Environment-Variables zu lesen. Default auf `localhost:8180` für IDE-Betrieb korrigiert, um `UnknownHostException: keycloak` zu vermeiden.
|
||||
* **Exception-Handling:** `PingExceptionHandler` um generischen `Exception`-Handler erweitert, um auch Security-Initialisierungsfehler (wie JWT-Decoder-Probleme) sauber abzufangen und zu loggen.
|
||||
|
||||
### Nachtrag 21:25
|
||||
* **Re-Fix Circuit Breaker Fallback:** Nachdem ein fehlerhafter Zwischenversuch (möglicherweise durch einen anderen Agenten) die `suspend`-Markierung wieder eingeführt hatte, wurde diese nun final entfernt. Die Signatur `fallbackPing(simulate: Boolean, ex: Throwable)` ohne `suspend` ist die einzig stabile Variante für Resilience4j in Kombination mit Spring Boot 3 AOP-Proxies und Kotlin Coroutines. Tests bestätigen die strukturelle Korrektheit.
|
||||
|
||||
### Nachtrag 21:45
|
||||
* **Stochastic Simulation:** Die Zufallskomponente (`Random.nextDouble() < 0.6`) wurde in der `enhancedPing`-Methode wieder eingeführt.
|
||||
* **Logik:** Wenn `simulate=true` übergeben wird, tritt der Fehler nun nur noch in ca. 60% der Fälle auf, was ein realistisches "intermittierendes" Fehlerszenario für den Circuit Breaker Test darstellt. In den restlichen 40% wird die Anfrage trotz Simulationsmodus erfolgreich verarbeitet.
|
||||
* **Logging:** Zusätzliches Log-Statement für den "Lucky Pass" Fall hinzugefügt, um die Simulationstransparenz in der Konsole zu wahren.
|
||||
@@ -1,38 +0,0 @@
|
||||
# 🧹 [Curator] Journal: Session-Abschluss 19. April 2026
|
||||
|
||||
## 📋 Zusammenfassung der Session
|
||||
Die heutige Session stand im Zeichen der **Code-Hygiene** und der **funktionalen Härtung** der Kernbereiche (Veranstaltung, Nennung, ZNS-Sync). Durch radikale Modularisierung konnte die Wartbarkeit massiv erhöht werden, während gleichzeitig kritische UX-Mängel behoben wurden.
|
||||
|
||||
## ✅ Erledigte Aufgaben
|
||||
|
||||
### 1. Radikale Modularisierung (Clean Code)
|
||||
* **Veranstaltung-Context:** Die `VeranstaltungScreens.kt` (ca. 2000 Zeilen) wurde in eine saubere Paketstruktur unter `at.mocode.desktop.screens.veranstaltung` aufgeteilt.
|
||||
* `VeranstaltungVerwaltung.kt` (Liste/Haupt-Screen)
|
||||
* `wizards/` (Turnier- & Veranstalter-Wizards)
|
||||
* `details/` (Profil & Konfig)
|
||||
* `components/` (Wiederverwendbare UI-Atome)
|
||||
* **Nennung-Context:** Die `NennungsMaske.kt` wurde analog dazu modularisiert und unter `at.mocode.frontend.features.nennung.presentation` neu strukturiert.
|
||||
* `NennungManagementScreen.kt` (Integrations-Screen)
|
||||
* `tabs/` (Nennungs-Tabellen, Verkauf/Buchung)
|
||||
* `online/` (Online-Nennung/Mail-Import)
|
||||
|
||||
### 2. ZNS-Import & Masterdata-Sync
|
||||
* **Stabilität:** Das `ZnsImportViewModel` wurde um detailliertes Terminal-Logging und robustes Error-Handling erweitert.
|
||||
* **Persistenz:** Einführung des `MasterdataRepository`-Patterns. Die Desktop-Shell persistiert nun synchronisierte Reiter, Pferde, Vereine und Funktionäre direkt in den reaktiven `Store`.
|
||||
* **UX:** Implementierung von Scrolling-Support (Scrollbars) in allen Stammdaten-Listen.
|
||||
|
||||
### 3. UX & Tastatur-Navigation
|
||||
* **Fokus-Kette:** In der `DeviceInitialization` wurden die Blockaden bei TAB und ENTER in Schritt 2 vollständig behoben.
|
||||
* **Logging:** Konsolen-Logs für die Initialisierung und den Sync-Prozess sind nun auch in der lokalen Umgebung via Gradle-Run sichtbar.
|
||||
|
||||
## 🛠️ Technische Details (ADR-0024 Plug-and-Play)
|
||||
* **Navigation:** Alle Referenzen in `DesktopMainLayout.kt` wurden auf die neuen Modul-Pfade aktualisiert.
|
||||
* **Build:** `./gradlew :frontend:shells:meldestelle-desktop:compileKotlinJvm` läuft fehlerfrei durch.
|
||||
|
||||
## 🚀 Ausblick für die nächste Session
|
||||
1. **Sync-Validierung:** Testlauf des initialen Masterdata-Syncs unter Realbedingungen (Backend-Anbindung).
|
||||
2. **Bewerb-Verwaltung:** Vertiefung der Modularisierung für die Bewerb-Konfiguration innerhalb der Turnier-Details.
|
||||
3. **Druck-Engine:** Erste Prototypen für ÖTO-konforme Starterlisten (PDF/Export).
|
||||
|
||||
**Status:** Projekt ist in einem stabilen und sauberen Zustand.
|
||||
**Signatur:** 🧹 [Curator] - 19. April 2026, 00:52 Uhr
|
||||
@@ -1,27 +0,0 @@
|
||||
# Journal Eintrag - 19. April 2026
|
||||
|
||||
## 📦 Migration: frontend/features/turnier-feature
|
||||
|
||||
Das Modul `frontend/features/turnier-feature` wurde erfolgreich auf den neuen **Module Architecture Blueprint** (Klasse B: `UI_COMPONENT`) migriert.
|
||||
|
||||
### 🏗️ Änderungen
|
||||
|
||||
1. **Gradle Konfiguration:**
|
||||
* `group` von `at.mocode.clients` auf `at.mocode.frontend.features` geändert (Synchronisation mit Referenzmodul `auth`).
|
||||
* `wasmJsMain` Source-Set in `build.gradle.kts` vervollständigt (inkl. `kotlin.stdlib.wasm.js`).
|
||||
* `compose.uiTooling` in `jvmMain` für konsistente IDE-Previews hinzugefügt.
|
||||
|
||||
2. **Struktur-Check:**
|
||||
* Die physische Verzeichnisstruktur für `commonMain`, `jvmMain` und `wasmJsMain` war bereits vorhanden und paket-konsistent (`at.mocode.turnier.feature`).
|
||||
|
||||
### 🧪 Verifikation
|
||||
|
||||
* **Build:** `./gradlew :frontend:features:turnier-feature:assemble` lief erfolgreich durch (JVM & WasmJS).
|
||||
* **Checklist:**
|
||||
* [x] Klasse B Identifikation
|
||||
* [x] Verzeichnisstruktur geprüft
|
||||
* [x] `build.gradle.kts` angepasst
|
||||
* [x] Kompilierung erfolgreich
|
||||
|
||||
### 🧹 Curator Status
|
||||
* Das `turnier-feature` ist nun blueprint-konform und bereit für die weitere plattformübergreifende Entwicklung.
|
||||
@@ -1,22 +0,0 @@
|
||||
# Journal-Eintrag: Blueprint-Migration `veranstaltung-feature`
|
||||
|
||||
**Datum:** 19. April 2026
|
||||
**Status:** ✅ Abgeschlossen
|
||||
**Agent:** 🏗️ [Lead Architect] | 🧹 [Curator]
|
||||
|
||||
## 🎯 Ziel
|
||||
Migration des Moduls `frontend/features/veranstaltung-feature` auf den neuen **Module Architecture Blueprint** (Klasse B: `UI_COMPONENT`).
|
||||
|
||||
## 🛠️ Durchgeführte Änderungen
|
||||
1. **Gradle-Konfiguration:**
|
||||
- `group` von `at.mocode.clients` auf `at.mocode.frontend.features` geändert (Synchronisation mit Referenz-Modul `auth`).
|
||||
- `wasmJsMain` Source-Set vervollständigt (Zusatz von `kotlin.stdlib.wasm.js`).
|
||||
2. **Struktur-Anpassungen:**
|
||||
- Erstellung der zwingend erforderlichen Verzeichnisse für `commonMain` und `wasmJsMain` unter dem neuen Namensraum `at.mocode.frontend.features.veranstaltung`.
|
||||
- Hinweis: Der bestehende Code in `jvmMain` (Paket `at.mocode.veranstaltung.feature`) bleibt vorerst erhalten, um die Abwärtskompatibilität der Shells zu gewährleisten, bis ein vollständiger Paket-Refactor durchgeführt wird.
|
||||
3. **Validierung:**
|
||||
- Erfolgreicher Cross-Platform Build via `./gradlew :frontend:features:veranstaltung-feature:assemble`.
|
||||
|
||||
## 📌 Nächste Schritte
|
||||
- Paket-Migration von `at.mocode.veranstaltung.feature` nach `at.mocode.frontend.features.veranstaltung` in einer koordinierten Aktion (zusammen mit den Shells).
|
||||
- Verschiebung der UI-Logik von `jvmMain` nach `commonMain`, um die Web-Lauffähigkeit (WasmJS) tatsächlich herzustellen.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Journal-Eintrag: Architektonische Bereinigung turnier-feature (Plug-and-Play)
|
||||
|
||||
**Datum:** 20. April 2026
|
||||
**Agent:** Junie (Lead Architect / Backend Developer)
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
Vollständige Umsetzung der Plug-and-Play Architektur gemäß **ADR-0024** im `turnier-feature`. Dies umfasst die Entfernung von Reflection-Altlasten und die Entkoppelung von Feature-Komponenten von der Shell.
|
||||
|
||||
## 🛠 Durchgeführte Änderungen
|
||||
|
||||
### 1. Entfernung von Reflection-Altlasten
|
||||
* **Problem:** `TurnierStammdatenTab.kt` griff via Reflection auf den `TurnierStore` in der Desktop-Shell zu.
|
||||
* **Lösung:**
|
||||
* Neues `TurnierStammdatenViewModel` im Feature-Modul erstellt.
|
||||
* Anbindung an das `TurnierRepository` (Interface-basiert).
|
||||
* `StammdatenTabContent` nutzt nun dieses ViewModel für State-Management und Persistenz.
|
||||
|
||||
### 2. ViewModel-Hoisting im TurnierDetailScreen
|
||||
* **Problem:** `TurnierDetailScreen` nutzte `koinInject` direkt in der Composable-Struktur, was die Testbarkeit erschwerte und eine harte Abhängigkeit zu Koin innerhalb der UI-Komponente schuf.
|
||||
* **Lösung:**
|
||||
* Refactoring von `TurnierDetailScreen`: ViewModels (`BewerbViewModel`, `TurnierNennungViewModel`, `TurnierStammdatenViewModel`) werden nun als Parameter übergeben.
|
||||
* Die Desktop-Shell (`DesktopMainLayout.kt`) übernimmt die Injektion und Delegation der ViewModels.
|
||||
|
||||
### 3. DI-Konfiguration
|
||||
* **Änderung:** Das `TurnierStammdatenViewModel` wurde im `TurnierFeatureModule.kt` als Factory registriert.
|
||||
|
||||
### 4. Code-Hygiene & Previews
|
||||
* **Änderung:** Die `ScreenPreviews.kt` in der Desktop-Shell wurden aktualisiert, um mit den neuen Parameter-Anforderungen des `TurnierDetailScreen` kompatibel zu sein (Mock-Injektion).
|
||||
|
||||
## ✅ Verifizierung
|
||||
* **Build:** `./gradlew :frontend:shells:meldestelle-desktop:compileKotlinJvm` erfolgreich.
|
||||
* **Architektur:** Keine direkten Koppelungen von `turnier-feature` zur Shell mehr vorhanden.
|
||||
|
||||
## 🧹 Curator-Check
|
||||
* ADR-0024 Konformität: **Erreicht**.
|
||||
* V2-Altlasten: **Vollständig entfernt**.
|
||||
* MASTER_ROADMAP Status: **Aktualisiert**.
|
||||
@@ -1,31 +0,0 @@
|
||||
# Journal: 20. April 2026 - Abschluss der Abend-Session (Curator)
|
||||
|
||||
## 🏁 Session-Abschluss (00:15)
|
||||
|
||||
Die Abend-Session am 20. April 2026 wurde erfolgreich abgeschlossen. Im Fokus stand die Professionalisierung der Desktop-App für den bevorstehenden Einsatz im Turnier-Betrieb.
|
||||
|
||||
### ✅ Erreichte Meilensteine
|
||||
|
||||
1. **Device-Setup ("Lock-and-Edit"):**
|
||||
* Das Setup-System ist nun robust gegen versehentliche Änderungen.
|
||||
* Ein Review-Modus erlaubt die administrative Einsicht (z.B. Security-Key für Richter), während die Bearbeitung durch einen Warn-Dialog geschützt ist.
|
||||
* Integration der Drucker-Auswahl (`PrintServiceLookup`) vervollständigt das Hardware-Onboarding.
|
||||
|
||||
2. **Veranstaltungs-Wizard (SCS Organizer & Tournament):**
|
||||
* Ein neuer, geführter 6-Stufen-Prozess ersetzt die alten fragmentierten Screens.
|
||||
* **ZNS-Guard:** Verhindert die Anlage ohne aktuelle Stammdaten (OEPS-Datenstand).
|
||||
* **WYSIWYG-Preview:** Eine Sticky Preview-Card am oberen Rand gibt sofortiges Feedback.
|
||||
* **Domain-Mapping:** Die OEPS-Satznummer aus der `LIZENZ01.dat` wird als Anker für Ansprechpersonen genutzt.
|
||||
|
||||
3. **Architektur & Routing:**
|
||||
* Kritische Routing-Fehler (Setup-Loopback, falsche Navigations-Whitelists) wurden behoben.
|
||||
* Die Koin-DI-Konfiguration wurde für den `HttpClient` und feature-übergreifende Repositories stabilisiert.
|
||||
* Vollständige Eliminierung von "V2"-Relikten in den betroffenen Modulen.
|
||||
|
||||
### 📋 Status der MASTER_ROADMAP
|
||||
* **PHASE 13** wurde um die Punkte "Device-Setup" und "Veranstaltungs-Wizard" erweitert und als **ABGESCHLOSSEN** markiert.
|
||||
|
||||
### 🚀 Ausblick
|
||||
Die App ist nun in einem Zustand, der die Anlage realer Veranstaltungen (wie das Neumarkt-Turnier 6-009) mit hoher Datenintegrität ermöglicht. Der nächste logische Schritt ist die Vertiefung der Nennungserfassung und die Finalisierung des XML-Exports für den OEPS.
|
||||
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,28 +0,0 @@
|
||||
# Journal: 20. April 2026 - Desktop UX & Navigation Refinement
|
||||
|
||||
## 🏗️ Desktop-App: UX & Eingabe-Optimierung (Update)
|
||||
|
||||
* **Tastatur-Navigation (Fokus-Flow):**
|
||||
* **Device-Setup:** Vollständiges Refactoring von `DeviceInitializationConfig.jvm.kt`. Ersetzung von `OutlinedTextField` durch `MsTextField`. Entfernung störender `onKeyEvent`-Handler zugunsten des nativen `ImeAction`-Flows. Tab und Enter funktionieren nun reibungslos.
|
||||
* **Standardisierung:** Konsistente Nutzung von `MsTextField` in allen neuen Screens (`VeranstalterNeu`, `ZnsImport`).
|
||||
|
||||
* **MsFilePicker (Zentrale Komponente):**
|
||||
* Einführung einer plattformübergreifenden `MsFilePicker`-Komponente.
|
||||
* **Desktop (JVM):** Nutzt den nativen `FileDialog` für Dateiauswahlen (Look & Feel) und `JFileChooser` für Verzeichnisse.
|
||||
* **Integration:** Ersetzt manuelle Picker-Logik im Device-Setup und ZNS-Importer.
|
||||
|
||||
* **ZNS-Importer Refinement:**
|
||||
* Implementierung einer Fortschrittsanzeige (`LinearProgressIndicator`) mit Prozent- und Status-Details.
|
||||
* Klarstellung der Dateiformate: Unterstützung sowohl für `ZNS.zip` als auch für einzelne `.dat` Dateien.
|
||||
|
||||
## 🧭 Navigation & Stabilität
|
||||
|
||||
* **Veranstalter-Profil (Vereins-Integration):**
|
||||
* Integration einer detaillierten Vereins-Vorschau (Card) im `VeranstalterDetailScreen`.
|
||||
* Navigation zum Vereins-Editor direkt aus dem Veranstalter-Profil ("Bearbeiten"-Button).
|
||||
* **UI-Konsistenz:**
|
||||
* Einführung eines einheitlichen "Zurück"-Buttons (Pfeil-Icon) in der Header-Zeile aller Detail- und Konfigurations-Screens.
|
||||
* Kompakte Darstellung von Suchergebnissen in der Vereins-Suche (inkl. Logo-Vorschau).
|
||||
|
||||
## 🧹 Curator Hinweis
|
||||
Die gemeldeten UX-Blocker in der Geräte-Konfiguration und bei der Veranstaltungs-Neuanlage sind behoben. Der neue Date-Picker erfüllt den Wunsch nach einer komfortableren Datumsauswahl und verhindert Tippfehler im Zeitraum-Format.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Journal: 20. April 2026 - Bugfix Koin DI & HttpClient Injektion
|
||||
|
||||
## 🛠️ Bugfix (00:45)
|
||||
* **Problem:** Absturz der Desktop-App mit `NoDefinitionFoundException` für `io.ktor.client.HttpClient`.
|
||||
* **Ursache:** Das `networkModule` stellt den `HttpClient` nur als benannte Instanzen (`"apiClient"`, `"baseHttpClient"`) zur Verfügung. Das `VeranstaltungWizardViewModel`, `ProfileApiClient` und `OnlineNennungViewModel` forderten jedoch eine unbenannte Instanz an.
|
||||
* **Lösung:**
|
||||
* Anpassung des `VeranstaltungModule.kt`, `ProfileModule.kt` und `NennungModule.kt` zur Nutzung von `get(named("apiClient"))`.
|
||||
* Behebung eines Kompilierfehlers in `ProfileModule.kt` (fehlender `AuthTokenManager` im Konstruktor-Aufruf).
|
||||
* Vorbereitung des `VereinFeatureModule.kt` für den Wechsel von Fake- auf Ktor-Repository (auskommentiert als Option).
|
||||
|
||||
## 🧐 Curator Abschluss
|
||||
Der Koin-Graph ist wieder konsistent. Alle Features, die Netzwerkausrufe tätigen, nutzen nun explizit den vorkonfigurierten `apiClient`. Dies stellt sicher, dass Authentifizierungs-Header und Basis-URLs korrekt gesetzt werden.
|
||||
|
||||
*Gezeichnet durch den Curator.*
|
||||
@@ -1,27 +0,0 @@
|
||||
# Journal: 20. April 2026 - Setup-Optimierung & Profi-Veranstaltungs-Wizard
|
||||
|
||||
## 🛠️ Bugfix & Optimierung (23:50)
|
||||
* **Scope-Korrektur:** Behebung von `Unresolved reference` Fehlern in `DeviceInitializationScreen.kt`.
|
||||
* **State-Hoisting:** Migration der Dialog-States (`showRoleChangeWarning`, `pendingRole`) vom Screen in den `DeviceInitializationUiState` und das `ViewModel`. Dies verbessert die Testbarkeit und Konsistenz bei UI-Rekonfigurationen.
|
||||
* **Zentralisierte Logik:** Die Entscheidung, ob eine Warnung beim Rollenwechsel angezeigt werden soll, liegt nun im ViewModel.
|
||||
|
||||
## 🏗️ Device-Setup: Verlässlichkeit & Administration
|
||||
* **Review-Modus ("Lock-and-Edit"):** Die Geräte-Initialisierung wechselt nach Abschluss in einen Read-only Modus. Änderungen erfordern eine explizite Bestätigung via Warn-Dialog, um Sync-Probleme zu vermeiden.
|
||||
* **Drucker-Integration:** Auswahl eines Standard-Druckers direkt im Setup (Schritt 2).
|
||||
* **Security-Transparenz:** Der `sharedKey` ist im Review-Modus maskiert, kann aber per Klick (Auge-Icon) für Richter-Devices sichtbar gemacht werden.
|
||||
* **Rollen-Schutz:** Wechsel der Netzwerk-Rolle triggert nun einen Warn-Dialog, da dies bestehende Schritt-2-Konfigurationen ungültig machen kann.
|
||||
|
||||
## 🚀 "Neue Veranstaltung"-Wizard: Profi-Workflow
|
||||
* **ZNS-Guard:** Automatischer Check der Stammdaten-Verfügbarkeit beim Start. Führt bei fehlenden Daten direkt zum ZNS-Importer.
|
||||
* **Sticky Preview-Card:** Eine Echtzeit-Vorschau der Veranstaltung (Logo, Name, Ort, Datum) am oberen Bildschirmrand gibt sofortiges visuelles Feedback ("What You See Is What You Get").
|
||||
* **OEPS-Mapping (Satznummer):** Integration der Satznummer-Logik für Ansprechpersonen (z.B. Ursula Stroblmair). Vorbereitung für nahtlose Verknüpfung mit Reiter-Stammdaten.
|
||||
* **Turnier-Struktur & PDF-Ausschreibung:**
|
||||
* Unterstützung für mehrere Turniere pro Veranstaltung.
|
||||
* Integration des `MsFilePicker` für den PDF-Upload der Ausschreibung direkt bei der Turnier-Anlage.
|
||||
* Pfad-Validierung: Alle Felder müssen befüllt sein, bevor die Zusammenfassung erreicht wird.
|
||||
* **Finaler Review:** Kompakter 6. Schritt zur Kontrolle aller Parameter vor dem Speichern.
|
||||
|
||||
## 🧐 Curator Abschluss
|
||||
Die Desktop-App wurde heute Abend massiv professionalisiert. Das Setup schützt nun die Systemintegrität, während der neue Veranstaltungs-Wizard durch "Smart Defaults" (Vereinssitz als Ort, Vereinslogo als Platzhalter) und die Sticky-Preview ein effizientes Arbeiten ermöglicht. Die Grundlage für den realen Turnier-Betrieb am 25. April 2026 ist gelegt.
|
||||
|
||||
*Gezeichnet durch den Curator.*
|
||||
@@ -1,39 +0,0 @@
|
||||
# Journal-Eintrag: Bereinigung der V2-Altlasten und UI-Konsolidierung
|
||||
|
||||
**Datum:** 20. April 2026
|
||||
**Agent:** 🧹 [Curator] & 🏗️ [Lead Architect]
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
Vollständige Eliminierung aller verbliebenen "V2"-Suffixe im Frontend (Feature-Module) und Überführung der "Vision_03"-Verbesserungen in die finalen Produktions-Screens.
|
||||
|
||||
## 🛠️ Durchgeführte Änderungen
|
||||
|
||||
### 1. Turnier-Management (`turnier-feature`)
|
||||
* **Gelöscht:** `TurnierWizardV2.kt` (und zugehöriges ViewModel).
|
||||
* **Konsolidiert:** `TurnierNeuScreen.kt` wurde zum primären Wizard für die Turnieranlage ausgebaut.
|
||||
* Übernahme des **Stepper-Designs** (StepCircle) für die Tab-Leiste.
|
||||
* Beibehaltung der **nicht-linearen Tab-Navigation** für maximale Effizienz bei Profi-Usern.
|
||||
* Integration einer **Footer-Navigation** (Abbrechen, Zurück, Weiter, Finalisieren).
|
||||
* Visuelles Alignment auf das **PrimaryBlue (#1E3A8A)**.
|
||||
|
||||
### 2. Veranstalter-Management (`veranstalter-feature`)
|
||||
* **Gelöscht:** `VeranstalterAuswahlV2.kt`.
|
||||
* **Konsolidiert:** `VeranstalterAuswahlScreen.kt` modernisiert.
|
||||
* Kombination der **dichten Tabellenansicht** (Profi-Anforderung) mit dem modernen Card-Styling aus V2.
|
||||
* Einführung von **Radio-Buttons** zur expliziten Auswahl eines Veranstalters.
|
||||
* Integration der fachlichen **Hinweis-Box** (OEPS-Registrierung, Login-Generierung).
|
||||
* Alignment der Top-Bar und Footer-Aktionen auf Vision_03 Standards.
|
||||
|
||||
### 3. Code-Hygiene
|
||||
* Bereinigung veralteter Kommentare in `TurnierStammdatenTab.kt`, die auf `StoreV2` oder `TurnierStoreV2` verwiesen.
|
||||
* Fix von Unchecked-Casts im `TurnierStammdatenTab.kt` zur Verbesserung der Typsicherheit beim Zugriff auf Mock-Daten.
|
||||
|
||||
## ✅ Verifikation
|
||||
* **Build:** `:frontend:shells:meldestelle-desktop:compileKotlinJvm` erfolgreich durchgelaufen.
|
||||
* **Struktur:** Keine Dateien mit `*V2.kt` mehr in den Feature-Modulen vorhanden.
|
||||
|
||||
## 📝 Hinweis
|
||||
Die Einstellung `enableWasm=false` in `gradle.properties` bleibt vorerst aktiv, um die Iterationsgeschwindigkeit für die Desktop-Entwicklung hoch zu halten. Vor dem Release der Web-App muss dieser Flag wieder auf `true` gesetzt werden.
|
||||
|
||||
---
|
||||
*Gezeichnet: Junie (KI-Agent)*
|
||||
@@ -1,53 +0,0 @@
|
||||
# Journal-Eintrag: Vereins-Verwaltung Erweiterung (Logo & Adresse)
|
||||
|
||||
**Datum:** 20. April 2026
|
||||
**Status:** Abgeschlossen (Bugfix & Feature-Integration)
|
||||
**Beteiligte Agenten:** 🏗️ [Lead Architect], 🎨 [Frontend Expert], 🧹 [Curator], 🧐 [QA Specialist]
|
||||
|
||||
## 📝 Zusammenfassung
|
||||
Die Vereins-Verwaltung wurde um detaillierte Adressdaten und ein funktionales Logo-Management erweitert. Ein kritischer Bug, der zum Einfrieren der App beim Datei-Import führte, wurde behoben. Logos werden nun in der Vorschau korrekt gerendert.
|
||||
|
||||
## 🛠️ Technische Änderungen
|
||||
|
||||
### 0. Bugfix: Logo-Picker UI-Freeze
|
||||
* **Problem:** Der `FileDialog` (AWT) blockierte den Main-Thread, was zum Einfrieren der App führte.
|
||||
* **Lösung:** Auslagerung des Dialog-Aufrufs in einen asynchronen `Dispatchers.IO` Kontext in `LogoUploadZone.jvm.kt`.
|
||||
* **Stabilität:** Integration von Try-Catch Blöcken und detailliertem Logging für den Datei-Import-Prozess.
|
||||
|
||||
### 1. Feature: Logo-Rendering (Base64)
|
||||
* **Implementation:** Einführung einer `expect/actual` Funktion `decodeBase64ToImage`.
|
||||
* **JVM-Logic:** Nutzung von `org.jetbrains.skia.Image` zur Dekodierung der Base64-Bytes in eine `ImageBitmap`.
|
||||
* **UI-Integration:** Die `VereinCardPreview` rendert nun das Vereinslogo direkt aus dem gespeicherten Base64-String mittels `androidx.compose.foundation.Image`.
|
||||
|
||||
### 2. Domain-Modell (`Verein.kt`)
|
||||
* Erweiterung um Felder: `strasse`, `hausnummer`, `bundesland` (Enum).
|
||||
* Neues Feld `logoBase64` für die Offline-Speicherung von optimierten Vereinslogos.
|
||||
* Einführung des Enums `Bundesland` mit den 9 österreichischen Bundesländern zur Sicherstellung der Datenqualität (ÖTO-konform).
|
||||
|
||||
### 2. ViewModel (`VereinViewModel.kt`)
|
||||
* Erweiterung des `VereinUiState` um die neuen Adress- und Logo-Felder.
|
||||
* Implementierung der Change-Handler für alle neuen Felder.
|
||||
* Anpassung der `onSave`- und `onAddNew`-Methoden zur Berücksichtigung der erweiterten Datenstruktur.
|
||||
|
||||
### 3. UI-Anpassungen (`VereinScreens.kt`)
|
||||
* **Card-Preview:**
|
||||
* Anzeige der vollständigen Adresse (Straße, Hausnummer, PLZ, Ort, Bundesland).
|
||||
* Integration eines "Maps"-Buttons, der die Adresse direkt in Google Maps öffnet (via `LocalUriHandler`).
|
||||
* Vergrößertes Logo-Display (80dp) mit modernem Design.
|
||||
* **Editor:**
|
||||
* Logische Gruppierung der Adressfelder (Straße/Nr. in einer Zeile, PLZ/Ort/Bundesland in der nächsten).
|
||||
* Einsatz des `MsEnumDropdown` für die Bundesland-Auswahl.
|
||||
* Vorbereitung einer "Logo-Upload-Zone" mit visuellem Feedback für Drag-and-Drop / FilePicker.
|
||||
|
||||
## 🔍 Verifikation
|
||||
* [x] Bugfix: Datei-Dialog friert die UI nicht mehr ein (IO-Dispatcher).
|
||||
* [x] Feature: Base64-Logo wird in der Card-Vorschau gerendert.
|
||||
* [x] Feature: Logging im ViewModel und Logo-Service implementiert.
|
||||
* [x] UI: Kompakte Adressfelder und Google-Maps-Link funktionieren.
|
||||
|
||||
## 📌 Nächste Schritte
|
||||
* Implementierung einer tatsächlichen Bild-Skalierung vor dem Base64-Encoding, um Datenbank-Größe zu optimieren.
|
||||
* Finalisierung der Drag-and-Drop Logik (`onExternalDrag`), sobald Bibliotheks-Support stabil ist.
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,83 +0,0 @@
|
||||
# Journal: 21. April 2026 - Abschluss der Vormittags-Session (Curator)
|
||||
|
||||
## 🏁 Session-Abschluss (12:00)
|
||||
|
||||
In dieser Session haben wir den Navigations-Flow massiv professionalisiert und die geforderte fachliche Tiefe in die Veranstaltungsanlage integriert. Weg von reinen "Fake-Daten", hin zu einem robusten, ZNS-gestützten Workflow.
|
||||
|
||||
### ✅ Erreichte Meilensteine
|
||||
|
||||
1. **Hybrid-Suche & ZNS-Fallback (SCS: Organizer):**
|
||||
* Der `VeranstaltungWizard` durchsucht nun nicht mehr nur die lokale Datenbank, sondern bietet bei fehlenden Treffern einen automatischen Fallback auf die **ZNS-Stammdaten** an.
|
||||
* Gefundene Vereine aus den Stammdaten können mit einem Klick als neuer Veranstalter in den Workflow übernommen werden.
|
||||
|
||||
2. **Profile-Onboarding Wizard (SCS: Identity):**
|
||||
* Realisierung des `ProfileOnboardingWizard` (3 Steps: Suchen → Bestätigen → Verknüpfen).
|
||||
* Dieser Wizard klärt die Identität des Benutzers (Satznummern-Check) vor der ersten Pferdesportlochen-Aktion.
|
||||
* Nahtlose Integration in die Desktop-Shell (`ContentArea.kt`).
|
||||
|
||||
3. **Tiefe Turnier-Integration (SCS: Tournament):**
|
||||
* Der `TurnierWizard` wurde vollständig nach ADR-0024 refactored und als Komponente in Schritt 5 des `VeranstaltungWizard` eingebettet.
|
||||
* Die Child-ViewModel Injektion ermöglicht den konsistenten Datentransfer vom Turnier-Wizard zurück in die Veranstaltungsliste.
|
||||
|
||||
4. **Fachliche Validierung (§ 39 ÖTO) (SCS: Competition):**
|
||||
* Implementierung einer dynamischen **Abteilungs-Vorschau** im Bewerbs-Wizard.
|
||||
* Das System zeigt nun proaktiv die Schwellenwerte für Abteilungstrennungen (z. B. ab 35 Nennungen in Klasse S) an, basierend auf der gewählten Klasse.
|
||||
|
||||
5. **Stabilisierung & Robustheit:**
|
||||
* Einführung von robustem UUID-Parsing mit Try-Catch Fallbacks für Mock-IDs ("v1", "v2").
|
||||
* Beseitigung von "Dead-Ends" in der Navigation durch konsistentes Callback-Hoisting.
|
||||
* **Navigations-Stabilisierung:** Behebung eines Fehlers in `DesktopApp.kt`, der Benutzer trotz vorhandener Konfiguration fälschlicherweise zum `DeviceInitialization`-Wizard umleitete.
|
||||
* **Daten-Integrität:** Ergänzung der `settings.json` um Pflichtfelder (`syncInterval`), um die Validierung im `DeviceInitializationValidator` erfolgreich zu bestehen.
|
||||
* **Logging-Transparenz:** Erweiterung der Navigations-Logs in `DesktopApp.kt` und `DesktopMainLayout.kt` zur besseren Rückverfolgbarkeit von Redirect-Entscheidungen.
|
||||
* **Identity-Integration:** Hinzufügen des `Dashboard` Screens zur Ausnahmeliste des Authentifizierungs-Gates.
|
||||
|
||||
### 📋 Status der MASTER_ROADMAP
|
||||
* **PHASE 13 (Erweitert):** Der "Veranstaltungs-Wizard" ist nun keine Wunschvorstellung mehr, sondern ein integrierter Prozess vom ZNS-Import über das Benutzer-Profil bis zur fachlich validierten Bewerbs-Anlage.
|
||||
|
||||
### 🚀 Nächste Schritte
|
||||
Die Pferdesportliche Logik (§ 39) ist nun im Wizard sichtbar. Der nächste Schritt ist die **Live-Koppelung mit dem Nennungseingang**, um die Abteilungen basierend auf Realdaten (Nennungen) automatisch vorzuschlagen.
|
||||
|
||||
*Dokumentiert durch den Curator.*
|
||||
|
||||
### 🔧 Hotfix: Build-Stabilisierung & Navigations-Fix (12:15)
|
||||
- Behebung von Kompilierungsfehlern im `ProfileOnboardingScreen.kt`:
|
||||
- Korrektur der `MsTextField` `leadingIcon` Syntax (ImageVector statt Lambda).
|
||||
- Auflösung von `firstName`/`lastName` Referenzfehlern durch Nutzung der ZNS-Reiterdaten (`vorname`/`nachname`).
|
||||
- **Navigations-Fix:**
|
||||
- Korrektur der `LaunchedEffect`-Logik in `DesktopMainLayout.kt` zur Vermeidung von automatischen Umleitungen zur `VeranstaltungVerwaltung`, die Stammdaten-Screens (Vereine, Reiter, etc.) blockierten.
|
||||
- Erweiterung des Login-Gates in `DesktopApp.kt` um alle relevanten Stammdaten-Screens (`Vereine`, `Reiter`, `Pferde`, `Funktionäre` sowie deren Profil-Ansichten), um unerwünschte Redirects im Offline-Modus zu verhindern.
|
||||
- Erfolgreiche Verifizierung durch Kompilierung des Desktop-Moduls.
|
||||
|
||||
### 🍱 Stammdaten-Refinement: Vorschau-Cards & Erweiterungen (13:50)
|
||||
- **Modell-Erweiterungen:**
|
||||
- `Reiter` & `Funktionaer`: Ergänzung der Felder `Nation` und `Bundesland`.
|
||||
- `Pferd`: Einführung der `Kopfnummer`.
|
||||
- `Funktionaer`: Konsolidierung der `Qualifikation`.
|
||||
- **UI-Modernisierung:**
|
||||
- Implementierung von `ReiterCardPreview`, `PferdCardPreview` und `FunktionaerCardPreview` zur schnellen Identifikation in der Detailansicht.
|
||||
- Integration dieser Vorschau-Cards in die jeweiligen Screens (`Master-Detail-Layout`) sowie als Orientierungshilfe in den Editoren.
|
||||
- Anpassung der Pferde-Liste um die Spalte `Kopf-Nr.`.
|
||||
- **Suche & Performance:**
|
||||
- Erweiterung der Pferde-Suche um die Kopfnummer im `PferdeViewModel`.
|
||||
- Bereinigung von Compiler-Warnungen (unnecessary non-null assertions) in den neuen Screen-Komponenten.
|
||||
- Erfolgreiche Verifizierung durch Kompilierung des Desktop-Moduls (`BUILD SUCCESSFUL`).
|
||||
|
||||
### 2026-04-21 15:00 - [Frontend Expert] & [Lead Architect]
|
||||
* **Aktion:** Professionalisierung des Veranstalter-Wizards und Profil-Bearbeitung.
|
||||
* **Ergebnis:**
|
||||
* **Veranstalter-Domäne:** Erweiterung um Kontaktdaten (Telefon, E-Mail, Ansprechpartner, Adresse).
|
||||
* **Veranstalter-Wizard:** Refactoring des Wizards zu einer vollwertigen Edit/Create-Komponente inklusive Detail-Erfassung (Step 2).
|
||||
* **Repository-Update:** `FakeVeranstalterRepository` liefert nun vollständige Datensätze für alle Mock-Veranstalter.
|
||||
* **UI-Integration:** "Bearbeiten"-Button im Veranstalter-Profil ist nun mit dem Wizard verknüpft; Änderungen werden via Repository persistiert.
|
||||
* **Architektur:** Umstellung `VeranstalterDetailViewModel` auf das `VeranstalterRepository` (Eliminierung von In-View-Mocks).
|
||||
* **Navigation:** Einführung der Route `VeranstalterProfilEdit` für gezielte Bearbeitungs-Sprints.
|
||||
* **Vorschau & Logo:** Integration einer `VeranstalterCardPreview` und der `LogoUploadZone` im Veranstalter-Wizard zur optischen Verifikation und Branding-Unterstützung.
|
||||
* **Status:** Der "Veranstalter-Wizard" ist nun fachlich fertiggestellt und ermöglicht die vollständige Verwaltung der Veranstalter-Stammdaten inkl. Logos.
|
||||
|
||||
### 2026-04-21 15:30 - [Lead Architect] & [Frontend Expert] - Navigations-Hotfix
|
||||
* **Problem:** Unerwünschte Redirects im Offline-Modus (nicht authentifiziert) führten dazu, dass bei Klick auf "Veranstalter" oder andere Screens immer die "EventVerwaltung" (Dashboard) erzwungen wurde.
|
||||
* **Lösung:**
|
||||
* **DesktopApp.kt:** Erweiterung der Whitelist für erlaubte Screens im Offline-Modus um `VeranstalterVerwaltung`, `VeranstalterProfil`, `VeranstalterProfilEdit` und weitere. Die Whitelist wurde zudem in eine übersichtlichere Variable `isAllowedScreen` extrahiert.
|
||||
* **DesktopMainLayout.kt:** Entfernung redundanter und störender Redirect-Logik im `LaunchedEffect`, die Screen-Wechsel fälschlicherweise als "Setup-Erfolg" interpretierte und zurück zum Dashboard sprang.
|
||||
* **Ergebnis:** Die Sidebar-Navigation funktioniert nun konsistent; Benutzer landen auf dem Screen, den sie ausgewählt haben.
|
||||
* **Verifizierung:** Erfolgreicher Build des Desktop-Moduls.
|
||||
@@ -1,19 +0,0 @@
|
||||
# 📓 Journal-Eintrag: Bereinigung Git-Index (.idea-Altlasten)
|
||||
|
||||
**Datum:** 2026-04-21
|
||||
**Rolle:** 🐧 [DevOps Engineer]
|
||||
|
||||
## 🎯 Problemstellung
|
||||
Obwohl der Ordner `.idea/` in der `.gitignore` korrekt eingetragen ist, wurden Änderungen an IDEA-internen Dateien (Artefakte, XML-Configs) im Git-Status angezeigt. Dies lag daran, dass diese Dateien bereits im Git-Index getrackt wurden ("tracked files"), bevor die `.gitignore` entsprechend optimiert wurde.
|
||||
|
||||
## 🛠️ Durchgeführte Maßnahmen
|
||||
1. **Index-Bereinigung:** Alle Dateien innerhalb des `.idea/`-Verzeichnisses wurden mittels `git rm -r --cached .idea/` aus dem Git-Index entfernt.
|
||||
- *Wichtig:* Die Dateien wurden **nicht** physisch gelöscht, sondern nur für Git "vergessen".
|
||||
2. **Verifizierung:** Ein anschließender `git status` bestätigt, dass die Dateien nun als "gelöscht" zum Commit vorgemerkt sind.
|
||||
3. **Zukünftige Vermeidung:** Durch den bestehenden `.gitignore`-Eintrag (`.idea/`) werden diese Dateien zukünftig vollständig ignoriert.
|
||||
|
||||
## 🏁 Ergebnis
|
||||
Der Git-Arbeitsbereich ist nun sauber von IDE-spezifischen Konfigurationsdateien befreit. Nur noch relevante Projektdateien werden getrackt.
|
||||
|
||||
---
|
||||
*Gez. Junie (DevOps Engineer)*
|
||||
@@ -1,36 +0,0 @@
|
||||
# Session-Journal: 22. April 2026 - Finale ZNS-Sync & Auth Resolution
|
||||
|
||||
## 🎯 Status & Highlights
|
||||
- **Auth-Fix (Cloud-Sync):** Vollständige Behebung des `401 Unauthorized` beim Cloud-Sync. Redundante Header-Setzungen im `ZnsImportViewModel` wurden entfernt, da der zentrale `apiClient` Interceptor die Token-Injektion zuverlässig übernimmt.
|
||||
- **Route-Standardisierung:** Alle Masterdata-API-Routen wurden auf die singularisierten Pfade (`/horse`, `/funktionaer`, `/verein`, `/reiter`) umgestellt, um 1:1 mit den Backend-Controllern zu korrespondieren.
|
||||
- **Infrastruktur-Resilience:** Consul Health-Checks für den `masterdata-service` final stabilisiert (Nutzung von Port 8086 für Spring Actuator und Port 8091 für die Ktor-API). Intervalle und Timeouts wurden für Massenoperationen optimiert.
|
||||
- **SQLite-Bereitschaft:** Die lokale Datenbank ist nach einem Reset bereit für den initialen Massen-Sync von über 70.000 Datensätzen.
|
||||
|
||||
## 🛠️ Durchgeführte Änderungen
|
||||
### Frontend (Common/Desktop)
|
||||
- **ZnsImportViewModel.kt:**
|
||||
- Manuelle Token-Header und hartcodierte Basis-URLs entfernt.
|
||||
- Vollständige Umstellung auf `ApiRoutes` Konstanten.
|
||||
- Fehlerbehandlung bei API-Aufrufen (Pferde, Funktionäre) konsolidiert.
|
||||
- **Netzwerk-Abstraktion:**
|
||||
- Verifizierung, dass der `apiClient` in allen Repositories (`KtorVereinRepository`, `KtorReiterRepository` etc.) genutzt wird.
|
||||
- **UI-Stabilität:**
|
||||
- Behebung von Kompilierungsfehlern durch Import-Korrekturen (`ApiRoutes`).
|
||||
|
||||
### Backend (Infrastructure)
|
||||
- **masterdata-service (application.yml):**
|
||||
- Consul Health-Check Pfad auf `/actuator/health/readiness` präzisiert.
|
||||
- `health-check-port` fest auf 8086 (Spring Management) gesetzt.
|
||||
- Timeouts (`health-check-timeout: 5s`) hinzugefügt, um "Critical"-States bei kurzen Lastspitzen zu vermeiden.
|
||||
|
||||
## 🧐 QA & Verifizierung
|
||||
- **Build:** `./gradlew :frontend:shells:meldestelle-desktop:compileKotlinJvm` ist **BUILD SUCCESSFUL**.
|
||||
- **Infrastruktur-Check:** Manuelle Prüfung der Port-Zuweisung bestätigt die Trennung von Management und API.
|
||||
- **Logik-Check:** Verifizierung der Routen-Konstanten gegen die Backend-Controller.
|
||||
|
||||
## 🚀 Next Steps
|
||||
1. **Cloud-Sync Ausführung:** Start der Desktop-App und Betätigung des "Cloud-Sync" Buttons.
|
||||
2. **Daten-Validierung:** Suche in den Feature-Screens (Pferde, Funktionäre), um die Korrektheit der SQLite-Persistenz zu bestätigen.
|
||||
3. **Produktiv-Test:** Erstellung einer Veranstaltung im Wizard unter Nutzung eines importierten Vereins.
|
||||
|
||||
🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧐 [QA Specialist] | 🧹 [Curator]
|
||||
@@ -1,43 +0,0 @@
|
||||
# Curator Journal: Technische Geräte-Initialisierung & "Plan-USB"
|
||||
|
||||
**Datum:** 30. April 2026
|
||||
**Agenten:** 🏗️ [Lead Architect], 🎨 [Frontend Expert], 🧹 [Curator]
|
||||
|
||||
## 🎯 Status Quo
|
||||
Status: 🚧 IN ARBEIT (UI KORREKTUREN WEB)
|
||||
|
||||
Nach dem gestrigen Fehltritt wurden die Halluzinationen in der Web-Shell korrigiert:
|
||||
1. **Light-Mode Force:** Die Web-App erzwingt nun den Light-Mode für bessere Ablesbarkeit.
|
||||
2. **Download-Card:** Eine prominente Card für den Desktop-Download wurde im `WebMainScreen` integriert.
|
||||
3. **POC-Guide:** Ein detaillierter Guide wurde unter `docs/06_Frontend/Guides/POC_INITIALISIERUNG.md` erstellt.
|
||||
|
||||
## 🏗️ Implementierte Features (Update)
|
||||
* **Web-Shell Korrekturen:** Dark-Mode Deaktivierung und Download-CTA.
|
||||
* **Build-Fix:** Erstellung der fehlenden App-Icons (PNG/ICO) zur Behebung des Packaging-Fehlers.
|
||||
* **Chat:** Implementierung eines Veranstaltungs-Chats (MVP) in der Desktop-App inkl. Footer-Integration.
|
||||
* **Docker-Fix:** Behebung des "services must be a mapping" Fehlers in der Docker-Infrastruktur.
|
||||
* **Dokumentation:** Erster Entwurf der POC-Anleitung für Hardware-Tests (inkl. Run-Anweisungen).
|
||||
|
||||
## 📝 Wichtigste Entscheidungen & Artefakte
|
||||
(Bisherige Inhalte bleiben erhalten)
|
||||
|
||||
## 🏗️ Implementierte Features
|
||||
* **Single-Page Setup:** Alle technischen Einstellungen (Name, Key, Pfad, Interface) auf einer Seite.
|
||||
* **Dark-Mode & Modern UI:** Vollständige Unterstützung für Dark/Light/System-Themes mit einem kompakten "Professional"-Design.
|
||||
* **Intelligentes Fokus-Management:** Automatischer Sprung zum nächsten Feld und optimierte Tab-Navigation (Tooltips werden übersprungen).
|
||||
* **Benutzerfreundliche Netzwerkwahl:** Klartext-Namen für Adapter und Filterung technischer Details.
|
||||
* **Drucker-Fallback:** Virtueller PDF-Drucker für papierloses Arbeiten oder fehlende Hardware.
|
||||
|
||||
## 🗺️ Roadmap-Update
|
||||
(Roadmap wurde auf 2026-04-29 aktualisiert)
|
||||
|
||||
## 🚀 Nächste Schritte
|
||||
1. **Hardware-PoC (Dringend):** Verifikation der Netzwerk-Discovery und des Plan-USB Exports durch den User.
|
||||
2. **Meilenstein 1:** Beginn der physischen Implementierung der Turnier-Hierarchie erst nach Erfolg von Meilenstein 0.
|
||||
3. **Feinschliff:** Behebung von Bugs, die im PoC heute Abend gefunden werden.
|
||||
|
||||
---
|
||||
**🚫 Anti-Halluzinations-Protokoll aktiv:** Kein Task wird ohne Hardware-Beweis als "Erledigt" markiert.
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,15 +0,0 @@
|
||||
# Curator Journal: Chat-Navigation-Fix
|
||||
|
||||
## 🛠️ Problemstellung
|
||||
Die Chat-Funktion konnte in der Desktop-App nicht geöffnet werden. Das Navigations-Log zeigte, dass die App nach dem Versuch, den `ChatScreen` zu rendern, sofort eine Umleitung zum `EventVerwaltung` (Dashboard) durchführte.
|
||||
|
||||
## 🔍 Ursachenanalyse
|
||||
Die Ursache lag in der Guard-Logik innerhalb der `DesktopApp.kt`. Dort wird geprüft, ob ein User authentifiziert ist. Für Screens, die ohne expliziten Cloud-Login zugänglich sein sollen (wie das lokale Dashboard oder der Offline-Chat), gibt es eine `isAllowedScreen`-Liste. Der `AppScreen.Chat` fehlte in dieser Liste, wodurch der Security-Guard fälschlicherweise eine nicht vorhandene Session monierte und zum Dashboard zurückleitete.
|
||||
|
||||
## ✅ Durchgeführte Änderungen
|
||||
- **Security-Guard:** `AppScreen.Chat` wurde zur `isAllowedScreen`-Liste in `DesktopApp.kt` hinzugefügt.
|
||||
- **Verifikation:** Die Logik wurde mit den im Issue bereitgestellten Logs abgeglichen. Durch die Aufnahme in die Liste wird der `LaunchedEffect`, der die Umleitung triggert, für den Chat-Screen nun korrekt übersprungen.
|
||||
|
||||
## 📌 Status
|
||||
- [x] Chat-Navigation repariert
|
||||
- [x] Code-Basis konsistent mit "Offline-First" Strategie (Chat im LAN ohne Cloud-Login)
|
||||
@@ -1,27 +0,0 @@
|
||||
# Curator Journal - 30. April 2026
|
||||
|
||||
## 🛠️ Netzwerk-Discovery Fix (Meilenstein 0)
|
||||
|
||||
### Status: Verifikation durch Hardware-POC ausstehend (Iteration 2)
|
||||
|
||||
Der erste Hardware-POC des Users zeigte Probleme bei der automatischen Discovery der Desktop-Instanzen auf. Trotz erfolgreichem Pings fanden sich die Instanzen nicht.
|
||||
|
||||
### 🔍 Ursachenanalyse
|
||||
1. **Unpräzises mDNS-Binding:** JmDNS nutzte standardmäßig `getLocalHost()`, was in vielen Netzwerk-Konfigurationen (insb. bei VPNs oder Docker-Interfaces wie vom User gemeldet: `172.17.x.x`) auf das falsche Interface bindet.
|
||||
2. **UI-Unklarheit:** Der User erkannte nicht, ob ein Interface aktiv ist oder ob die Discovery überhaupt läuft.
|
||||
|
||||
### 🚀 Durchgeführte Änderungen
|
||||
1. **Core-Network (mDNS):**
|
||||
- `NetworkDiscoveryService` und `JmDnsDiscoveryService` erweitert, um ein explizites IP-Binding zu ermöglichen.
|
||||
- Die Discovery wird nun hart an die IP des vom User gewählten Netzwerk-Interfaces gebunden.
|
||||
2. **Features-Device-Initialisierung:**
|
||||
- **UI-Rewrite:** Die Dropdown-Liste wurde durch ein interaktives Karten-Layout ersetzt.
|
||||
- **Status-Indikatoren:** Jedes Interface zeigt nun einen farbigen Punkt (Grün für LAN/WLAN-IPs, Rot für andere) und Icons (🔌/🌐) zur schnellen Identifikation.
|
||||
- **Auto-Discovery:** Sobald ein Interface gewählt oder die Rolle gewechselt wird, wird die Discovery/Registrierung automatisch neu gestartet.
|
||||
3. **Guides:**
|
||||
- `POC_INITIALISIERUNG.md` aktualisiert mit klaren Verifikationsschritten für das Netzwerk-Interface.
|
||||
|
||||
### ⚠️ Wichtiger Hinweis für den User
|
||||
Bitte die Desktop-App mit `./gradlew :frontend:shells:meldestelle-desktop:createDistributable` neu bauen und erneut auf die Ziel-Hardware übertragen. Achten Sie im Assistenten auf den **grünen Punkt** bei der Interface-Wahl.
|
||||
|
||||
**Curator Ende.**
|
||||
@@ -1,29 +0,0 @@
|
||||
# Curator Journal: POC-Fix & Portable Distribution
|
||||
|
||||
**Datum:** 30. April 2026
|
||||
**Agenten:** 🏗️ [Lead Architect], 🧹 [Curator]
|
||||
|
||||
## 🎯 Status Quo
|
||||
Status: 🚀 BEREIT FÜR HARDWARE-TEST
|
||||
|
||||
Nach der Kritik am unzureichenden `run`-Hinweis wurde der Build-Prozess für den POC auf eine portable Lösung umgestellt.
|
||||
|
||||
## 🏗️ Wichtigste Änderungen
|
||||
* **Build-Strategie:** Wechsel von `packageDistribution` (benötigt OS-Tools wie dpkg) zu `createDistributable`.
|
||||
* **Portabilität:** Die App wird nun als entpacktes Image (`app`-Ordner) bereitgestellt, das direkt vom USB-Stick auf dem Zielsystem (Zora-Hardware) ausgeführt werden kann.
|
||||
* **Desktop-Chat:** Implementierung eines Veranstaltungs-Chats (MVP) mit Footer-Integration und Navigation.
|
||||
* **Docker-Fix:** Behebung des Syntaxfehlers in `dc-gui.yaml`.
|
||||
* **Dokumentation:** Der Guide `docs/06_Frontend/Guides/POC_INITIALISIERUNG.md` wurde komplett überarbeitet und beantwortet nun alle offenen Fragen zu Docker, Gradle und dem Transfer-Prozess.
|
||||
|
||||
## 📝 Entscheidungen
|
||||
1. **Kein System-Packaging für POC:** Um die Hardware-Abhängigkeiten des Build-Systems zu umgehen, nutzen wir die Portable-Variante.
|
||||
2. **Direkt-Transfer:** Das `app`-Verzeichnis wird 1:1 kopiert.
|
||||
3. **Chat als Navigation-Stub:** Die Chat-UI ist als MVP vorhanden, um die Usability im Feldtest zu prüfen (Online-Gefühl).
|
||||
|
||||
## 🚀 Nächste Schritte
|
||||
1. **Hardware-POC:** Durchführung des Tests auf der Ziel-Hardware durch den User.
|
||||
2. **Chat-Test:** Verifikation der Chat-Erreichbarkeit über die FooterBar.
|
||||
3. **Feedback-Loop:** Auswertung der `init_device.aes` Datei und der Netzwerk-Erkennung.
|
||||
|
||||
---
|
||||
**🚫 Anti-Halluzinations-Protokoll:** Der `createDistributable` Task wurde erfolgreich verifiziert (BUILD SUCCESSFUL). Der Pfad zum Artefakt wurde im Guide korrekt hinterlegt.
|
||||
+5
-2
@@ -8,7 +8,8 @@ source: ../temp/Caht-Verlauf_2026-03-27.md
|
||||
|
||||
# Chat-Verlauf — 27. März 2026
|
||||
|
||||
Hinweis: Inhalt aus `docs/temp/Caht-Verlauf_2026-03-27.md` übernommen. Original belassen, bis die vollständige Migration abgeschlossen ist.
|
||||
Hinweis: Inhalt aus `docs/temp/Caht-Verlauf_2026-03-27.md` übernommen. Original belassen, bis die vollständige Migration
|
||||
abgeschlossen ist.
|
||||
|
||||
```text
|
||||
🏗️ [Lead Architect]
|
||||
@@ -119,6 +120,8 @@ Architektur-Skizze, Modulschnitt und Sprint-Plan.
|
||||
|
||||
### Roadmap bis Neumarkt (Beispiel: 3 Sprints à 2 Wochen)
|
||||
```
|
||||
… (vollständiger Verlauf aus der Quelle)
|
||||
|
||||
… (vollständiger Verlauf aus der Quelle)
|
||||
|
||||
```
|
||||
```
|
||||
+14
-4
@@ -1,10 +1,13 @@
|
||||
# 🧹 Curator – Session Log (2026-04-01)
|
||||
|
||||
## Zusammenfassung
|
||||
- Flow-Entscheidung bestätigt: Grüner Pfad aktiv, roter Pfad verworfen. "+ Neues Turnier" führt direkt zum Tab „STAMMDATEN“ v2 mit Turnier‑Nr.-Gatekeeping.
|
||||
|
||||
- Flow-Entscheidung bestätigt: Grüner Pfad aktiv, roter Pfad verworfen. "+ Neues Turnier" führt direkt zum Tab
|
||||
„STAMMDATEN“ v2 mit Turnier‑Nr.-Gatekeeping.
|
||||
- Keine Codeänderungen in dieser Sitzung; Build zuletzt grün. Entscheidungen und nächste Schritte dokumentiert.
|
||||
|
||||
## Beschlossene UI/Flow-Regeln
|
||||
|
||||
- Turnieranlage
|
||||
- Einstieg: "+ Neues Turnier" → direkt „Turnier Detail v2“ Tab „STAMMDATEN“.
|
||||
- Gatekeeping: 5‑stellige Turnier‑Nr. eingeben + Bestätigungsdialog (danach immutable).
|
||||
@@ -19,20 +22,26 @@
|
||||
- Datum im zulässigen Veranstaltungszeitraum; Hinweis: „Muss zwischen [von–bis] liegen“.
|
||||
- Abweichender Turnier‑Ort: Soft‑Warnung (kein Hard‑Block).
|
||||
- Branding
|
||||
- Feld „Titel“ optional. Default‑Vorschlag: „[Kategorien] [Verein‑Ort] [Bundesland]“ (Fallback über Veranstalterdaten).
|
||||
- Feld „Titel“ optional. Default‑Vorschlag: „[Kategorien] [Verein‑Ort] [Bundesland]“ (Fallback über
|
||||
Veranstalterdaten).
|
||||
- „Turnier‑Logo“ optional; Fallback = Veranstalter‑Logo.
|
||||
|
||||
## Veranstalter-Flow
|
||||
|
||||
- Nach „Schritt 2: Vereinsdaten bestätigen“ → Weiterleitung zum „Veranstalter‑Profil“.
|
||||
- Veranstalter‑Profil: minimale Felder (Logo‑URL, Ansprechpartner, E‑Mail, Telefon, Adresse), CTA „+ Neue Veranstaltung“.
|
||||
- Von dort → Veranstaltung‑Wizard Schritt 2 („Basisdaten“). Feld „Veranstaltungs‑Logo“ optional; Fallbacks: Veranstaltungs‑Logo → Veranstalter‑Logo → Default.
|
||||
- Veranstalter‑Profil: minimale Felder (Logo‑URL, Ansprechpartner, E‑Mail, Telefon, Adresse), CTA „+ Neue
|
||||
Veranstaltung“.
|
||||
- Von dort → Veranstaltung‑Wizard Schritt 2 („Basisdaten“). Feld „Veranstaltungs‑Logo“ optional; Fallbacks:
|
||||
Veranstaltungs‑Logo → Veranstalter‑Logo → Default.
|
||||
|
||||
## Footer-Onboarding
|
||||
|
||||
- Online/Offline‑Status anzeigen.
|
||||
- Geräte‑Verbindung (z. B. „Richter‑Turm“) anzeigen, klickbar für Details.
|
||||
- Chat‑Trigger anzeigen, wenn mindestens ein weiteres Gerät verbunden ist.
|
||||
|
||||
## Nächste Schritte (To‑Do)
|
||||
|
||||
- Routing final auf Stammdaten v2 festziehen; alte Pfade entfernen.
|
||||
- Save‑Enable‑Matrix implementieren; ZNS‑Panel inkl. Import‑Log.
|
||||
- Kategorien‑UI konsolidieren und gruppieren; Default‑Titel generieren; Ort‑Softwarnung.
|
||||
@@ -40,6 +49,7 @@
|
||||
- Footer‑Onboarding integrieren (Status, Geräte, Chat‑Trigger).
|
||||
|
||||
## Artefakte/Referenzen
|
||||
|
||||
- docs/80_Assets/frontend/screens/E_Nennen/flow-wechsel.png (neuer Flow – grüner Pfeil)
|
||||
- docs/80_Assets/frontend/screens/E_Nennen/flow-fehler.png (Bruchstellen im alten Flow)
|
||||
- docs/99_Journal/2026-03-31_Session_Log_Event_First_Workflow.md
|
||||
+6
-1
@@ -15,6 +15,7 @@ Hinweis: Dieses Protokoll konsolidiert Inhalte aus drei Quelldateien unter `docs
|
||||
Die Originale bleiben bis zur finalen Migration erhalten.
|
||||
|
||||
## Agenda & Ziel
|
||||
|
||||
- Überblick über aktuelle Reports aller Rollen
|
||||
- Strategie-Feinschliff und Arbeitsaufträge
|
||||
- Reihenfolge der nächsten Entwicklungsschritte
|
||||
@@ -24,12 +25,15 @@ Quelle: `Besprechung_2026-04-02.md` (Kurzagenda, Report-Verweise)
|
||||
## Domänen-Klärungen und Entscheidungen
|
||||
|
||||
### Veranstalter/Veranstaltung/Turnier — Präzisierung der Hierarchie
|
||||
Kernaussage: Eine interne `Veranstaltung` (Tenant-Grenze) kann mehrere `Turnier` (mit jeweils eigener OEPS-Turniernummer) enthalten.
|
||||
|
||||
Kernaussage: Eine interne `Veranstaltung` (Tenant-Grenze) kann mehrere `Turnier` (mit jeweils eigener
|
||||
OEPS-Turniernummer) enthalten.
|
||||
Konsequenz: Anpassung der `Ubiquitous_Language.md` und Datenbankschemata erforderlich.
|
||||
|
||||
Quelle: `Okay,_ich_bin_der_Besitzer_dieses_Projek.md`
|
||||
|
||||
### Abteilung als kleinste Einheit & USB-Stick-Fallback
|
||||
|
||||
- `Abteilung` ist die operative Einheit mit eigener Startliste/Ergebnis/Siegerehrung.
|
||||
- USB-Export/Import wird auf Abteilungs-Ebene präzisiert (Startlisten/Ergebnisse je Abteilung).
|
||||
- System muss abhängig vom Prüfungstyp korrekte Zusammenführung bzw. separate Siegerehrung unterstützen.
|
||||
@@ -37,6 +41,7 @@ Quelle: `Okay,_ich_bin_der_Besitzer_dieses_Projek.md`
|
||||
Quelle: `1._USB-Stick_Fallback_bei_LAN-Ausfall.md`
|
||||
|
||||
## Arbeitsaufträge (Auszug)
|
||||
|
||||
- Architect: Domänenmodell präzisieren (Veranstaltung 1:N Turnier) und ADR/UL aktualisieren.
|
||||
- Backend: Tabellen für `veranstaltung`, `turnier`, `abteilung`; Kassa-Logik je Ebene.
|
||||
- Frontend: Dialog-Logik für Abteilungs-Vorschläge/Validierung.
|
||||
+14
-7
@@ -12,13 +12,18 @@ sources:
|
||||
|
||||
## ✅ Beschlüsse
|
||||
|
||||
- Ubiquitous Language wird als SSoT geführt; Aktualisierungen zu Abteilung, Kassen, TeilnehmerKonto, Zahlvorgang sind angenommen.
|
||||
- Event‑First‑Workflow (Veranstaltung → Turnier → Bewerbe → Abteilungen → Startliste) ist der verbindliche Bedienfluss fürs MVP.
|
||||
- Ubiquitous Language wird als SSoT geführt; Aktualisierungen zu Abteilung, Kassen, TeilnehmerKonto, Zahlvorgang sind
|
||||
angenommen.
|
||||
- Event‑First‑Workflow (Veranstaltung → Turnier → Bewerbe → Abteilungen → Startliste) ist der verbindliche Bedienfluss
|
||||
fürs MVP.
|
||||
- Abteilung ist kleinste ausführbare Einheit; Typisierung eingeführt: `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH`.
|
||||
- Kassen‑Konzept bestätigt: Turnierkassa je Turnier, Konsolidierung in Veranstaltungs‑Kassa auf Event‑Ebene.
|
||||
- Zahlvorgang darf mehrere Rechnungen/Belege ausgleichen (auch turnierübergreifend innerhalb derselben Veranstaltung); Buchung auf TeilnehmerKonto (Event‑Ebene).
|
||||
- Navigation V2: Screen‑Baum festgelegt, Back‑Stack‑Regeln (SingleTop Tabs, Logout poppt MainShell, modale Overrides nicht im Stack) angenommen.
|
||||
- Tenant‑Konzept bestätigt: „Eine Veranstaltung = eine Datenbank (Tenant)“, gemäß ADR‑0021; Auswirkungen auf Schema, API, Frontend dokumentieren.
|
||||
- Zahlvorgang darf mehrere Rechnungen/Belege ausgleichen (auch turnierübergreifend innerhalb derselben Veranstaltung);
|
||||
Buchung auf TeilnehmerKonto (Event‑Ebene).
|
||||
- Navigation V2: Screen‑Baum festgelegt, Back‑Stack‑Regeln (SingleTop Tabs, Logout poppt MainShell, modale Overrides
|
||||
nicht im Stack) angenommen.
|
||||
- Tenant‑Konzept bestätigt: „Eine Veranstaltung = eine Datenbank (Tenant)“, gemäß ADR‑0021; Auswirkungen auf Schema,
|
||||
API, Frontend dokumentieren.
|
||||
|
||||
## 🛠️ Domänen‑Korrekturen
|
||||
|
||||
@@ -30,7 +35,9 @@ sources:
|
||||
|
||||
- ⏸️ USB‑Fallback für Datensync (Offsite‑Export/Import) – Evaluierung Sprint B/C.
|
||||
-
|
||||
⏸️ Web‑App (PWA) – nach Desktop‑MVP, Anforderungen sammeln.
|
||||
|
||||
⏸️ Web‑App (PWA) – nach Desktop‑MVP, Anforderungen sammeln.
|
||||
|
||||
- ⏸️ Nenn‑System‑Integration (ZNS Live‑Sync) – nach Abschluss Stammdaten‑Stabilisierung.
|
||||
|
||||
## 🔗 Verweise
|
||||
@@ -38,6 +45,6 @@ sources:
|
||||
- Ubiquitous Language: `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`
|
||||
- Event‑First‑Workflow: `docs/02_Guides/Event-First-Workflow.md`
|
||||
- Navigation V2: `docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
|
||||
- Navigation V2 (Archiv): `docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
|
||||
- Navigation V2 (Archiv): `docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
|
||||
- Tenant‑Konzept (Laien‑Erklärung): `docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md`
|
||||
- ADR‑0021: `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md`
|
||||
+26
-9
@@ -11,41 +11,58 @@ last_update: 2026-04-02
|
||||
* Fokus: UI/UX-Verbesserungen in der Desktop-Frontend-App, Navigation und Profil-Ansichten
|
||||
|
||||
## Zusammenfassung
|
||||
* Onboarding: Eingaben für „Gerätename“ und „Sicherheitsschlüssel“ bleiben beim Zurück-Navigieren erhalten; Tab/Enter-Navigation funktionsfähig.
|
||||
* Profil-Seiten: Einheitliche Vorschau-Cards mit „bearbeiten“-Dialog für Veranstalter, Pferd, Reiter, Verein, Funktionär.
|
||||
* Navigation/UX: Breadcrumbs und Zurück-Navigation korrigiert; Veranstaltungs-Wizard (Schritt 2) kehrt korrekt zum zugehörigen Veranstalter-Profil zurück.
|
||||
|
||||
* Onboarding: Eingaben für „Gerätename“ und „Sicherheitsschlüssel“ bleiben beim Zurück-Navigieren erhalten;
|
||||
Tab/Enter-Navigation funktionsfähig.
|
||||
* Profil-Seiten: Einheitliche Vorschau-Cards mit „bearbeiten“-Dialog für Veranstalter, Pferd, Reiter, Verein,
|
||||
Funktionär.
|
||||
* Navigation/UX: Breadcrumbs und Zurück-Navigation korrigiert; Veranstaltungs-Wizard (Schritt 2) kehrt korrekt zum
|
||||
zugehörigen Veranstalter-Profil zurück.
|
||||
* Abschlussdialog: Vor „Veranstaltung final anlegen“ wird eine Daten-Vorschau zur Bestätigung angezeigt.
|
||||
|
||||
## Wichtige Änderungen (High-Level)
|
||||
|
||||
* State-Lift im Onboarding mittels `rememberSaveable`; Routing-/Back-Handling im Desktop-Layout aktualisiert.
|
||||
* Profil-Ansichten auf Card-Vorschau mit Edit-Dialog umgestellt; Persistenz an `StoreV2` gebunden.
|
||||
* Veranstaltungs-Konfig: Bestätigungs-Dialog mit Datenübersicht vor finalem Anlegen.
|
||||
|
||||
## Betroffene/Referenz-Dateien
|
||||
|
||||
* frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/layout/DesktopMainLayout.kt
|
||||
* frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/Screens.kt
|
||||
* frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/VeranstaltungScreens.kt
|
||||
* frontend/core/navigation/src/commonMain/kotlin/at/mocode/frontend/core/navigation/AppScreen.kt
|
||||
* frontend/features/reiter-feature/src/commonMain/kotlin/at/mocode/frontend/features/reiter/domain/Reiter.kt
|
||||
* Design-Referenzen: docs/80_Assets/frontend/screens/A_EventVerwaltung/Veranstalter-Card-v01.png, docs/80_Assets/frontend/screens/A_EventVerwaltung/Veranstalter-Profil-Card-v01.png
|
||||
* Design-Referenzen: docs/80_Assets/frontend/screens/A_EventVerwaltung/Veranstalter-Card-v01.png,
|
||||
docs/80_Assets/frontend/screens/A_EventVerwaltung/Veranstalter-Profil-Card-v01.png
|
||||
|
||||
## Qualitätssicherung
|
||||
* Lint: keine Fehler; nur harmlose Warnungen (unbenutzte Imports/Parameter, reduzierbarer Not-Null-Call, Legacy Long→Duration-Overloads).
|
||||
|
||||
* Lint: keine Fehler; nur harmlose Warnungen (unbenutzte Imports/Parameter, reduzierbarer Not-Null-Call, Legacy
|
||||
Long→Duration-Overloads).
|
||||
* Manuelle Klickpfade geprüft (ohne Backend-Abhängigkeit).
|
||||
|
||||
## Offene Punkte / ToDos
|
||||
|
||||
* Onboarding: Werte-Persistenz in allen Rücknavigations-Pfaden erneut verifizieren (frühere Inkonsistenz gemeldet).
|
||||
* „VeranstalterNeu“: Vereins-Suche und „Daten übernehmen“ finalisieren (Suche, Auswahl, Mapping, Validierung, Fehleranzeigen).
|
||||
* „VeranstalterNeu“: Vereins-Suche und „Daten übernehmen“ finalisieren (Suche, Auswahl, Mapping, Validierung,
|
||||
Fehleranzeigen).
|
||||
* ZNS-Importer: Testbarkeit ohne Backend verbessern (Mock/Trockenlauf-Umschalter in der UI).
|
||||
* Lint-Aufräumen: ungenutzte Imports/Parameter entfernen; Long→Duration-Konvertierungen; not-null Call vereinfachen.
|
||||
|
||||
## Handover für nächste Session
|
||||
* Fokusvorschlag: Fertigstellung „VeranstalterNeu“ mit Vereinssuche + Datenübernahme; Ergänzung von UI-Tests (State-Retention im Onboarding, Wizard-Backpfade).
|
||||
|
||||
* Fokusvorschlag: Fertigstellung „VeranstalterNeu“ mit Vereinssuche + Datenübernahme; Ergänzung von UI-Tests (
|
||||
State-Retention im Onboarding, Wizard-Backpfade).
|
||||
* Optional: Export (PDF/Markdown) der Bestätigungsansicht für Veranstaltungsdaten evaluieren.
|
||||
|
||||
## Glossar/Begriffe (konsistent verwenden)
|
||||
|
||||
* „Veranstalter-Profil Card“: Vorschau-Ansicht mit Logo/Name/Kontakt + Button „bearbeiten“.
|
||||
* „Wizard Schritt 2 / Basisdaten der Veranstaltung“: Konfigurationsschritt mit Rücknavigation ins zugehörige Veranstalter-Profil, wenn `veranstalterId` gesetzt ist.
|
||||
* „Wizard Schritt 2 / Basisdaten der Veranstaltung“: Konfigurationsschritt mit Rücknavigation ins zugehörige
|
||||
Veranstalter-Profil, wenn `veranstalterId` gesetzt ist.
|
||||
|
||||
## Hinweise
|
||||
* Backend war in dieser Session nicht erforderlich; ZNS-Importer scheitert erwartungsgemäß ohne laufenden Endpoint (`http://localhost:8081/api/v1/import/zns`).
|
||||
|
||||
* Backend war in dieser Session nicht erforderlich; ZNS-Importer scheitert erwartungsgemäß ohne laufenden Endpoint (
|
||||
`http://localhost:8081/api/v1/import/zns`).
|
||||
@@ -0,0 +1,43 @@
|
||||
# Session Log: Behebung Flyway Migrations-Fehler im Ping-Service
|
||||
|
||||
**Datum:** 2026-04-03
|
||||
**Agent:** Backend Developer / Curator
|
||||
|
||||
## Problembeschreibung
|
||||
|
||||
Der `ping-service` ließ sich via Docker nicht starten und warf eine `FlywayMigrateException` mit der Ursache
|
||||
`ERROR: relation "ping" does not exist`.
|
||||
Die Log-Analyse zeigte, dass die Datenbankmigration `V2__seed_data.sql` fehlgeschlagen ist, weil die vorausgehende
|
||||
Migration `V1__init_ping.sql` (in der die Tabelle `ping` erstellt wird) offensichtlich nicht ausgeführt wurde.
|
||||
|
||||
## Ursachenanalyse
|
||||
|
||||
Die `application.yaml` des `ping-service` enthielt die Konfiguration `baseline-on-migrate: true`. Wenn mehrere
|
||||
Services (z. B. `masterdata-service`, `ping-service` etc.) dieselbe PostgreSQL-Datenbank (`pg-meldestelle-db`) und
|
||||
standardmäßig das Schema `public` nutzen, teilen sie sich ohne weitere Konfiguration die gleiche
|
||||
Flyway-Historientabelle (`flyway_schema_history`).
|
||||
|
||||
Wenn ein anderer Service bereits Migrationen ausgeführt oder die Datenbank initialisiert hatte, setzte Flyway für den
|
||||
`ping-service` eine Baseline mit Version `1`. Infolgedessen ignorierte Flyway die Datei `V1__init_ping.sql` und
|
||||
versuchte direkt, `V2__seed_data.sql` auszuführen. Dies führte zum Scheitern der Migration, da die notwendige Struktur
|
||||
aus `V1` fehlte.
|
||||
|
||||
## Lösung
|
||||
|
||||
1. **Isolierung der Flyway-Historientabelle:** In der `application.yaml` des `ping-service` wurde die Property
|
||||
`spring.flyway.table: flyway_schema_history_ping` hinzugefügt. Dadurch verwaltet der `ping-service` seinen eigenen
|
||||
Migrationsstatus unabhängig von anderen Services in der gleichen Datenbank.
|
||||
2. **Anpassung der Baseline-Version:** Es wurde explizit `spring.flyway.baseline-version: "0"` konfiguriert, um
|
||||
sicherzustellen, dass V1-Skripte stets als Teil der Historie betrachtet werden, selbst falls Flyway in einer nicht
|
||||
leeren Datenbank ansetzt.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
* `/mocode/Meldestelle/backend/services/ping/ping-service/src/main/resources/application.yaml`
|
||||
* `/mocode/Meldestelle/docs/05_Backend/Services/PingService_Reference.md` (Dokumentation aktualisiert)
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
* Die Infrastruktur sollte nun stabil hochfahren. (Ggf. Ping Service im Docker Stack neustarten).
|
||||
* Diese Best Practice (spezifische `flyway.table` pro Service) sollte zukünftig auch bei anderen Microservices angewandt
|
||||
werden, die sich dasselbe DB-Schema teilen, um Konflikte zu vermeiden.
|
||||
+4
@@ -4,13 +4,16 @@ status: FINAL
|
||||
owner: Curator
|
||||
last_update: 2026-04-03
|
||||
---
|
||||
|
||||
# Session Log — Postman Doku konsolidiert und Runbook-Struktur geschaffen
|
||||
|
||||
## Kontext
|
||||
|
||||
- Ziel: Postman-Dokumentationen zusammenführen, für Nicht‑Programmierer verständlich machen.
|
||||
- Zusätzlich: Zentralen Ort für Betriebsanleitungen etablieren, Alt-Dokus ins Archiv.
|
||||
|
||||
## Änderungen
|
||||
|
||||
- Neu: `docs/07_Infrastructure/runbooks/POSTMAN_API_Tests_Runbook.md` (konsolidiertes, einsteigerfreundliches Runbook)
|
||||
- Neu: `docs/07_Infrastructure/runbooks/README.md` (Index und Regeln für Runbooks/Betriebsanleitungen)
|
||||
- Backend-Guide umgestellt auf Redirect: `docs/05_Backend/Guides/Testing_with_Postman.md`
|
||||
@@ -19,5 +22,6 @@ last_update: 2026-04-03
|
||||
- Originalpfad zeigt nun Redirect-Notiz: `docs/04_Agents/Besprechung_2026-04-03/Postman_Tests_Dokumentation.md`
|
||||
|
||||
## Hinweise
|
||||
|
||||
- Bestehende Links bleiben funktionsfähig (Redirect-Stub).
|
||||
- Weitere Betriebsanleitungen künftig hier ablegen: `docs/07_Infrastructure/runbooks/`
|
||||
+17
-9
@@ -8,30 +8,38 @@ created: 2026-04-09
|
||||
# 🧹 Curator Session Log — 09.04.2026
|
||||
|
||||
## Änderungen in dieser Session
|
||||
|
||||
- Frontmatter zu `docs/README.md` hinzugefügt; Quick Links um Journal/Reports erweitert.
|
||||
- Report erstellt: `90_Reports/2026-04-09_Curator-Cleanup-Report.md` (Analyse & Maßnahmen).
|
||||
- Journal angelegt: `99_Journal/2026-03-27_Chat-Verlauf.md` (Chat-Protokoll importiert, Original referenziert).
|
||||
- Journal angelegt: `99_Journal/2026-04-02_Besprechung.md` (konsolidiertes Protokoll mit Quellen).
|
||||
- Report erstellt: `90_Reports/2026-04-09_Todos-ZNS-Importer.md` (bereinigt aus temp/).
|
||||
- Leitlinie für Assets erstellt: `80_Assets/README.md` (C-3, Zielstruktur & Migration).
|
||||
- Physische Konsolidierung (Phase 1):
|
||||
- Neumarkt-Assets (PNG/WEBP/PDF/TXT) von `docs/Neumarkt2026/` nach `docs/80_Assets/neumarkt2026/` verschoben.
|
||||
- SuDo-Screenshots (PNG) von `docs/BilderSuDo/` nach `docs/80_Assets/frontend/sudo/` verschoben.
|
||||
- Referenzen aktualisiert in: `docs/04_Agents/Logs/2026-03-21_Frontend_NennungsMaske.md`.
|
||||
- Physische Konsolidierung (Phase 1):
|
||||
- Neumarkt-Assets (PNG/WEBP/PDF/TXT) von `docs/Neumarkt2026/` nach `docs/80_Assets/neumarkt2026/` verschoben.
|
||||
- SuDo-Screenshots (PNG) von `docs/BilderSuDo/` nach `docs/80_Assets/frontend/sudo/` verschoben.
|
||||
- Referenzen aktualisiert in: `docs/04_Agents/Logs/2026-03-21_Frontend_NennungsMaske.md`.
|
||||
|
||||
## Offene Punkte für Folgesession
|
||||
|
||||
- Physische Konsolidierung der Assets nach `docs/80_Assets/**` und Link-Updates.
|
||||
- Vollständiger Frontmatter-Check aller Markdown-Dateien; fehlende Header ergänzen.
|
||||
- `docs/temp/` Inhalte nach erfolgreicher Migration in `_archive/` überführen.
|
||||
- Weitere Referenz-Updates: verbleibende Hinweise auf `docs/BilderSuDo/*` und Frontend-Screenshots unter `docs/06_Frontend/**` angleichen.
|
||||
- Weitere Referenz-Updates: verbleibende Hinweise auf `docs/BilderSuDo/*` und Frontend-Screenshots unter
|
||||
`docs/06_Frontend/**` angleichen.
|
||||
|
||||
## Phase 2.1 — Assets (Frontend-Screens) Migration
|
||||
|
||||
- Inventur durchgeführt: Produktive Referenzen auf `docs/06_Frontend/Screenshots/**` außerhalb von `docs/temp/**` nur in `docs/04_Agents/Logs/2026-03-21_Frontend_NennungsMaske.md` gefunden.
|
||||
- Befund: Referenzierter Screenshot `Desktop-Nennmaske-Entwurf_2026-03-21_11-53.png` existiert nicht mehr am alten Pfad; Mapping weist auf `flows/nennmaske_flow-desktop-uebersicht__v1__entwurf__2026-03-21__11-53.png`, der aktuell ebenfalls nicht im Repo ist.
|
||||
- Maßnahme: Link nicht umgebogen, stattdessen Hinweis in Log ergänzt (Screenshot derzeit nicht verfügbar, Mapping referenziert). Keine physischen Moves in 2.1 notwendig.
|
||||
- Inventur durchgeführt: Produktive Referenzen auf `docs/06_Frontend/Screenshots/**` außerhalb von `docs/temp/**` nur in
|
||||
`docs/04_Agents/Logs/2026-03-21_Frontend_NennungsMaske.md` gefunden.
|
||||
- Befund: Referenzierter Screenshot `Desktop-Nennmaske-Entwurf_2026-03-21_11-53.png` existiert nicht mehr am alten Pfad;
|
||||
Mapping weist auf `flows/nennmaske_flow-desktop-uebersicht__v1__entwurf__2026-03-21__11-53.png`, der aktuell ebenfalls
|
||||
nicht im Repo ist.
|
||||
- Maßnahme: Link nicht umgebogen, stattdessen Hinweis in Log ergänzt (Screenshot derzeit nicht verfügbar, Mapping
|
||||
referenziert). Keine physischen Moves in 2.1 notwendig.
|
||||
- Nächste Schritte (2.2 Vorschlag):
|
||||
- Quelle des Desktop‑Nennmaske‑Screens wiederherstellen (oder Figma-Export ergänzen) und nach `docs/80_Assets/frontend/screens/` einordnen.
|
||||
- Quelle des Desktop‑Nennmaske‑Screens wiederherstellen (oder Figma-Export ergänzen) und nach
|
||||
`docs/80_Assets/frontend/screens/` einordnen.
|
||||
- Danach Link in `2026-03-21_Frontend_NennungsMaske.md` aktualisieren.
|
||||
|
||||
## Phase 2.2 — Konsolidierung umgesetzt (09.04.2026)
|
||||
+6
-1
@@ -8,9 +8,12 @@ last_update: 2026-04-09
|
||||
# Session Log: Turnier-/Veranstaltungs-Domain Alignment
|
||||
|
||||
## Anlass
|
||||
- Auftrag aus Lead-Architect-Update: fachliche Ergänzungen/Umbenennungen in `Veranstaltung` und `Turnier` verifizieren, vervollständigen und dokumentieren.
|
||||
|
||||
- Auftrag aus Lead-Architect-Update: fachliche Ergänzungen/Umbenennungen in `Veranstaltung` und `Turnier` verifizieren,
|
||||
vervollständigen und dokumentieren.
|
||||
|
||||
## Ergebnis
|
||||
|
||||
- `Veranstaltung` enthält die geforderten Listen bereits im Domain-Modell:
|
||||
- `austragungsplaetze: List<Austragungsplatz>`
|
||||
- `artikelPreisliste: List<TurnierArtikel>`
|
||||
@@ -24,11 +27,13 @@ last_update: 2026-04-09
|
||||
- `"Kein Turnierbeauftragter zugewiesen"`
|
||||
|
||||
## Aktualisierte Artefakte
|
||||
|
||||
- Code:
|
||||
- `backend/services/events/events-domain/src/main/kotlin/at/mocode/events/domain/model/Turnier.kt`
|
||||
- Dokumentation:
|
||||
- `docs/03_Domain/01_Core_Model/Entities/Overview.md`
|
||||
|
||||
## Verifikation
|
||||
|
||||
- Projektweite Suche auf Altbegriff `richterObmannId`: keine aktiven Code-Treffer (nur Verlauf/Archiv).
|
||||
- Zielgerichtetes Linting für geänderte Kotlin-Datei durchgeführt (ohne Fehler).
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: Curator
|
||||
last_update: 2026-04-10
|
||||
---
|
||||
|
||||
# Journal Entry: 2026-04-10 - Billing Service Setup & ZNS Importer Hardening
|
||||
|
||||
## 👷 [Backend Developer] / 🏗️ [Lead Architect] / 🧹 [Curator]
|
||||
|
||||
### Zusammenfassung der Session
|
||||
|
||||
In dieser Session wurde das Fundament für den Kassa-Service (`billing-context`) gelegt und die Robustheit des
|
||||
ZNS-Importers durch zusätzliche Integrationstests für Funktionäre gesteigert.
|
||||
|
||||
### Wichtigste Ergebnisse
|
||||
|
||||
1. **Billing Service Initialisierung & API:**
|
||||
* `billing-service` Modul erstellt, konfiguriert und mit `core-domain` (Serialisierung) verknüpft.
|
||||
* Exposed-Tabellendefinitionen (v1) für `TeilnehmerKonto` und `Buchung` implementiert.
|
||||
* `BillingController` mit REST-Endpunkten für Konten, Buchungen und Historie erstellt.
|
||||
* `TeilnehmerKontoService` um API-Methoden (`getKontoById`, `getKonto`, `getBuchungsHistorie`, `buche`) erweitert.
|
||||
* Integrationstests (`TeilnehmerKontoServiceTest`) erfolgreich mit H2-In-Memory-DB durchgeführt.
|
||||
* **OpenAPI-Dokumentation:** `documentation.yaml` für `billing-service` erstellt und CRUD-Endpunkte für Konten und
|
||||
Buchungen dokumentiert.
|
||||
2. **Entries-Integration (Neu):**
|
||||
* Automatische Buchung von Nenngeld und Nachnenngebühren bei Einreichung einer Nennung implementiert.
|
||||
* Erweiterung der `Bewerb`-Entität um Finanzfelder (`nenngeld_cent`, `nachnenngebuehr_cent`).
|
||||
* Neue Flyway-Migration `V8__add_bewerb_financial_fields.sql` im `entries-service` hinzugefügt.
|
||||
* `NennungUseCases` nutzt nun den `TeilnehmerKontoService` zur automatischen Belastung der Teilnehmerkonten (negativer
|
||||
Saldo).
|
||||
* `EntriesServiceApplication` scannt nun auch `at.mocode.billing` Pakete für die Cross-Context Integration.
|
||||
3. **ZNS-Importer Hardening:**
|
||||
* Erweiterung von `ZnsImportServiceTest` um Tests für mehrfache Qualifikationen und die Update-Strategie (
|
||||
Delete+Insert) bei Funktionären (`RICHT01.dat`).
|
||||
* Alle 11 Integrationstests sind erfolgreich durchgelaufen.
|
||||
4. **Kompilations-Fixes (Billing):**
|
||||
* `billing-service` auf korrekte Exposed DSL Syntax (`selectAll().where { ... }`) umgestellt.
|
||||
* Explizite `transaction { ... }` Blöcke in `TeilnehmerKontoService` eingeführt.
|
||||
* Typ-Konsistenz für `Instant` (kotlin.time) in `billing-domain` zur Übereinstimmung mit `core-domain` hergestellt.
|
||||
|
||||
### Betroffene Dateien
|
||||
|
||||
- `backend/services/billing/` (Neuer SCS-Kontext)
|
||||
- `backend/infrastructure/zns-importer/src/test/kotlin/at/mocode/zns/importer/ZnsImportServiceTest.kt`
|
||||
|
||||
### Nächste Schritte
|
||||
|
||||
- [x] Integration des Billing-Services in den `entries-context` (automatische Buchung bei Nennung).
|
||||
- [x] Fix von Kompilationsfehlern und Test-Regressionen (H2/Exposed Kompatibilität).
|
||||
- UI-Anbindung im Frontend für Kontenübersicht und manuelle Buchungen.
|
||||
- Erweiterung der Abrechnungs-Logik (z.B. Rechnungserstellung als PDF).
|
||||
|
||||
### Technische Details & Fixes
|
||||
|
||||
- **Exposed / H2:** `TIMESTAMPTZ` in Flyway-Migrationen auf `TIMESTAMP WITH TIME ZONE` umgestellt, um H2-Kompatibilität
|
||||
in Integrationstests zu gewährleisten.
|
||||
- **Multi-Tenancy:** `ExposedTenantTransactions` unterstützt nun sowohl PostgreSQL (`SET search_path`) als auch H2 (
|
||||
`SET SCHEMA`).
|
||||
- **Billing Config:** `BillingDatabaseConfiguration` ist nun robust gegen fehlende JDBC-URLs (wichtig für modularisierte
|
||||
Tests).
|
||||
|
||||
---
|
||||
*Co-authored-by: Junie <junie@jetbrains.com>*
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-04-14
|
||||
---
|
||||
|
||||
# Session Log: Fix Kotlin Wasm JS Compilation OOM
|
||||
|
||||
## Problem
|
||||
|
||||
Die Kompilierung des Moduls `:frontend:features:billing-feature` für `wasmJs` schlug mit einem
|
||||
`java.lang.OutOfMemoryError: GC overhead limit exceeded` fehl.
|
||||
|
||||
Ursache war die Verwendung von `material-icons-extended` in Kombination mit den bisherigen JVM-Speichereinstellungen (
|
||||
6GB). Da `material-icons-extended` tausende generierte Icon-Dateien enthält, stößt der Kotlin/Wasm-Compiler bei der
|
||||
IR-Lowering-Phase an seine Grenzen.
|
||||
|
||||
## Lösung
|
||||
|
||||
1. **Speichererhöhung:** Die JVM-Heap-Einstellungen in `gradle.properties` wurden von 6GB auf 8GB erhöht.
|
||||
- `kotlin.daemon.jvmargs` wurde auf `-Xmx8g` gesetzt.
|
||||
- `org.gradle.jvmargs` wurde auf `-Xmx8g` gesetzt, wobei die Optionen für den Kotlin-Daemon (
|
||||
`-Dkotlin.daemon.jvm.options`) auf `-Xmx6g` erhöht wurden.
|
||||
2. **Verifizierung:** Die Kompilierung von `:frontend:features:billing-feature:compileProductionLibraryKotlinWasmJs`
|
||||
wurde nach einem Daemon-Restart erfolgreich durchgeführt.
|
||||
|
||||
## Betroffene Dateien
|
||||
|
||||
- `gradle.properties`: Erhöhung der Speicherlimits.
|
||||
- `frontend/features/billing-feature/build.gradle.kts`: (Kurzzeitig getestet ohne `materialIconsExtended`, aber wieder
|
||||
aktiviert, da Icons daraus benötigt werden).
|
||||
|
||||
## Handover
|
||||
|
||||
- Zukünftig sollte bei weiteren OOM-Problemen im Wasm-Bereich geprüft werden, ob `material-icons-extended` durch eine
|
||||
selektive Icon-Einbindung (z.B. als Ressourcen) ersetzt werden kann, um den Compiler zu entlasten.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-04-14
|
||||
---
|
||||
|
||||
# Session Log: Finalize and Enable Entries Isolation Integration Test
|
||||
|
||||
## Problem
|
||||
|
||||
Der Test `EntriesIsolationIntegrationTest` im Modul `:backend:services:entries:entries-service` war deaktiviert (
|
||||
`@Disabled`). Er hatte Probleme mit der Daten-Isolierung zwischen verschiedenen Tenants, wenn Exposed mit mehreren
|
||||
Schemas und PostgreSQL-Containern verwendet wurde.
|
||||
|
||||
Zusätzlich gab es IDE-Warnungen bezüglich nicht auflösbarer Symbole in SQL-Strings, redundantem `runBlocking` und
|
||||
ungenutzten Variablen.
|
||||
|
||||
## Lösung
|
||||
|
||||
1. **Test-Bereinigung:**
|
||||
- Entfernung der `@Disabled` Annotation.
|
||||
- Behebung der `runBlocking` Redundanz durch Verwendung von `runBlocking` auf Test-Methoden-Ebene.
|
||||
- Entfernung ungenutzter Variablen (`saved`).
|
||||
- Bereitstellung einer `@TestConfiguration` mit einem Mock `JwtDecoder`, um ApplicationContext-Ladefehler durch
|
||||
Security-Abhängigkeiten zu vermeiden.
|
||||
|
||||
2. **Schema-Isolierung fixiert:**
|
||||
- Umstellung der Tabellen-Erstellung im `setup` auf JDBC, um zu verhindern, dass Exposed's `Table`-Singletons
|
||||
frühzeitig an ein falsches Schema gebunden werden.
|
||||
- Sicherstellung, dass `tenantTransaction` den `search_path` in PostgreSQL korrekt setzt.
|
||||
- Explizite Verwendung von `SET search_path` innerhalb der Transaktionen im Isolationstest, um Leaks zu vermeiden.
|
||||
- Verifizierung der Isolation: Schreibzugriffe in `event_a` landen nun nachweislich nicht mehr in `event_b`.
|
||||
|
||||
3. **Verifizierung & Cleanup:**
|
||||
- Alle 10 Tests im Modul (inkl. der neu aktivierten Isolation-Tests) laufen erfolgreich durch.
|
||||
- IDE-Warnungen in `EntriesIsolationIntegrationTest` und `JdbcTenantRegistryTest` wurden durch
|
||||
`@Suppress("SqlResolve")`, Verwendung von String-Konstanten/Interpolation (`$CONTROL_SCHEMA`) und Entfernung
|
||||
ungenutzter Code-Fragmente (`nennungRepository`, `random()`, `registerDataSource`) behoben.
|
||||
- Typos wie "testdb" -> "test_db" und "Produktions" -> "Production" wurden korrigiert.
|
||||
- Behebung von IDE-Warnungen in `NennungBillingIntegrationTest`, `BewerbeZeitplanIntegrationTest` und
|
||||
`DomainHierarchyMigrationTest` durch Entfernung ungenutzter Variablen (`result`), Ersetzen von Umlauten in
|
||||
Funktionsnamen/Strings durch ASCII-Zeichen und Verwendung von Konstanten für Schema-Namen (`TEST_SCHEMA`).
|
||||
- Fehlende Spring-Konfigurations-Metadaten für `multitenancy.*` wurden in
|
||||
`additional-spring-configuration-metadata.json` ergänzt.
|
||||
|
||||
## Betroffene Dateien
|
||||
|
||||
-
|
||||
`backend/services/entries/entries-service/src/test/kotlin/at/mocode/entries/service/tenant/EntriesIsolationIntegrationTest.kt`:
|
||||
Reaktiviert und repariert.
|
||||
- `backend/services/entries/entries-service/src/test/kotlin/at/mocode/entries/service/tenant/JdbcTenantRegistryTest.kt`:
|
||||
Bereinigt und optimiert.
|
||||
- `backend/services/entries/entries-service/src/main/resources/META-INF/additional-spring-configuration-metadata.json`:
|
||||
Metadaten ergänzt.
|
||||
|
||||
## Handover
|
||||
|
||||
- Der `EntriesIsolationIntegrationTest` dient nun als Referenz für Multi-Tenancy Tests mit echten PostgreSQL-Containern.
|
||||
Bei weiteren Tests dieser Art sollte auf das Exposed-Schema-Caching geachtet werden.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-04-14
|
||||
---
|
||||
|
||||
# Session Log: Fix Entries Service Integration Tests (EOFException / PostgreSQL Connection)
|
||||
|
||||
## Problem
|
||||
|
||||
Die Integrationstests im Modul `:backend:services:entries:entries-service` (`BewerbeZeitplanIntegrationTest`,
|
||||
`NennungBillingIntegrationTest`) schlugen mit einer `FlywaySqlUnableToConnectToDbException` (verursacht durch
|
||||
`PSQLException: EOFException`) fehl.
|
||||
|
||||
Ursache war das Fehlen einer `application-test.yaml`. Dadurch wurden die Standardwerte aus `application.yaml` geladen,
|
||||
welche eine aktive PostgreSQL-Instanz auf `localhost:5432` sowie Consul und Flyway-Migrationen erwarteten. In der
|
||||
CI/Test-Umgebung ohne diese Infrastruktur führte der Verbindungsversuch zum Abbruch.
|
||||
|
||||
## Lösung
|
||||
|
||||
1. **Test-Konfiguration erstellt:** Eine neue Datei
|
||||
`backend/services/entries/entries-service/src/test/resources/application-test.yaml` wurde angelegt.
|
||||
- Umstellung auf H2 In-Memory Datenbank (`jdbc:h2:mem:entries-test`).
|
||||
- Deaktivierung von Flyway (`spring.flyway.enabled=false`), da die Tests Tabellen manuell via Exposed `SchemaUtils`
|
||||
anlegen.
|
||||
- Deaktivierung von Consul Discovery (`spring.cloud.consul.enabled=false`).
|
||||
- Umstellung der Multitenancy-Registry auf `inmem`.
|
||||
2. **Verifizierung:** Die Tests im Modul wurden mit `./gradlew :backend:services:entries:entries-service:test`
|
||||
erfolgreich durchgeführt (5 Tests bestanden, 1 übersprungen/disabled).
|
||||
|
||||
## Betroffene Dateien
|
||||
|
||||
- `backend/services/entries/entries-service/src/test/resources/application-test.yaml`: Neue Konfiguration für das `test`
|
||||
Profil.
|
||||
|
||||
## Handover
|
||||
|
||||
- Die `EntriesIsolationIntegrationTest` bleibt weiterhin `@Disabled`, da sie Testcontainers benötigt und laut
|
||||
Quellcode-Kommentar noch weitere Fixes für die Exposed-Metadaten-Isolierung erfordert.
|
||||
+2
@@ -34,6 +34,8 @@ Dies erhöht die Sicherheit und automatisiert die Feature-Freischaltung auf den
|
||||
|
||||
- `backend/services/identity/identity-domain/src/main/kotlin/at/mocode/identity/domain/model/Device.kt`
|
||||
-
|
||||
|
||||
`backend/services/identity/identity-infrastructure/src/main/kotlin/at/mocode/identity/infrastructure/persistence/DeviceTable.kt`
|
||||
|
||||
- `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/onboarding/OnboardingSettings.kt`
|
||||
- `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/Screens.kt`
|
||||
+3
@@ -39,8 +39,11 @@ funktional auszubauen (Stammdaten-Validierung).
|
||||
## 🔗 Relevante Dateien
|
||||
|
||||
-
|
||||
|
||||
`frontend/features/veranstaltung-feature/src/jvmMain/kotlin/at/mocode/veranstaltung/feature/presentation/VeranstaltungenScreen.kt`
|
||||
|
||||
- `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/VeranstaltungScreens.kt` (Zentrale
|
||||
Desktop-Ansicht)
|
||||
-
|
||||
|
||||
`frontend/features/veranstaltung-feature/src/jvmMain/kotlin/at/mocode/veranstaltung/feature/presentation/VeranstaltungNeuScreen.kt`
|
||||
+5
-4
@@ -19,10 +19,11 @@ In dieser intensiven Abendsession wurden kritische Stabilitätsprobleme und UX-M
|
||||
3. **📦 ZNS-Import Robustheit:** Der Importer erkennt nun flexibel verschiedene Dateinamens-Schemata (z.B. `VEREIN*.DAT`)
|
||||
und gibt detailliertes Feedback über fehlende Stammdaten.
|
||||
4. **🎨 UI/UX Veredelung:**
|
||||
* Sicherheitsschlüssel-Feld im Onboarding ist nun ein Passwort-Feld mit Sichtbarkeits-Toggle.
|
||||
* Rollenvergabe im Client-Management wurde auf Dropdowns umgestellt.
|
||||
* Backup-Pfadauswahl nutzt jetzt einen nativen JFileChooser für bessere Usability.
|
||||
* Navigations-Abstürze (Koin `NoDefinitionFoundException`) wurden im Vereins-Modul eliminiert.
|
||||
|
||||
* Sicherheitsschlüssel-Feld im Onboarding ist nun ein Passwort-Feld mit Sichtbarkeits-Toggle.
|
||||
* Rollenvergabe im Client-Management wurde auf Dropdowns umgestellt.
|
||||
* Backup-Pfadauswahl nutzt jetzt einen nativen JFileChooser für bessere Usability.
|
||||
* Navigations-Abstürze (Koin `NoDefinitionFoundException`) wurden im Vereins-Modul eliminiert.
|
||||
|
||||
## 🚧 Offene Punkte / Ausblick
|
||||
|
||||
+24
-6
@@ -5,36 +5,54 @@
|
||||
**Kontext:** Desktop-Zentrale Onboarding
|
||||
|
||||
## 🔍 Problembeschreibung
|
||||
Der User berichtete von anhaltenden Problemen bei der Tastatur-Navigation (Tabulator- und Enter-Taste) im `DeviceInitialization`-Screen. Trotz vorangegangener Optimierungen mit `ImeAction.Next` war der Fokus-Fluss in Compose Desktop unzuverlässig, insbesondere beim Wechsel zwischen `MsSettingsField` und Standard-`OutlinedTextField` sowie beim dynamischen Einblenden von Sektionen.
|
||||
|
||||
Der User berichtete von anhaltenden Problemen bei der Tastatur-Navigation (Tabulator- und Enter-Taste) im
|
||||
`DeviceInitialization`-Screen. Trotz vorangegangener Optimierungen mit `ImeAction.Next` war der Fokus-Fluss in Compose
|
||||
Desktop unzuverlässig, insbesondere beim Wechsel zwischen `MsSettingsField` und Standard-`OutlinedTextField` sowie beim
|
||||
dynamischen Einblenden von Sektionen.
|
||||
|
||||
## 🛠️ Lösung & Implementierung
|
||||
Um die Navigation absolut deterministisch zu machen, wurde von der automatischen Fokus-Suche auf eine explizite **Focus-Requester-Kette** umgestellt.
|
||||
|
||||
Um die Navigation absolut deterministisch zu machen, wurde von der automatischen Fokus-Suche auf eine explizite *
|
||||
*Focus-Requester-Kette** umgestellt.
|
||||
|
||||
### 1. Explizite FocusRequester
|
||||
|
||||
In `DeviceInitializationConfig.jvm.kt` wurden `FocusRequester` für alle Hauptfelder definiert:
|
||||
|
||||
- `deviceNameFocus`
|
||||
- `sharedKeyFocus`
|
||||
- `backupPathFocus`
|
||||
|
||||
### 2. Harte KeyboardActions
|
||||
Anstatt sich auf `focusManager.moveFocus(FocusDirection.Next)` zu verlassen (was bei komplexen Hierarchien fehlschlagen kann), rufen die `onNext`-Handler nun explizit den `requestFocus()` des logisch nächsten Feldes auf.
|
||||
|
||||
Anstatt sich auf `focusManager.moveFocus(FocusDirection.Next)` zu verlassen (was bei komplexen Hierarchien fehlschlagen
|
||||
kann), rufen die `onNext`-Handler nun explizit den `requestFocus()` des logisch nächsten Feldes auf.
|
||||
|
||||
- `Gerätename` -> `sharedKeyFocus.requestFocus()`
|
||||
- `Sync-Key` -> `backupPathFocus.requestFocus()` (falls Rolle = MASTER)
|
||||
|
||||
### 3. Dialog-Auto-Fokus
|
||||
Beim Klick auf "+ Client hinzufügen" wird nun mittels `LaunchedEffect` sofort der Fokus auf das neue Eingabefeld (`addClientNameFocus`) gesetzt, was einen nahtlosen Übergang ohne Maus-Interaktion ermöglicht.
|
||||
|
||||
Beim Klick auf "+ Client hinzufügen" wird nun mittels `LaunchedEffect` sofort der Fokus auf das neue Eingabefeld (
|
||||
`addClientNameFocus`) gesetzt, was einen nahtlosen Übergang ohne Maus-Interaktion ermöglicht.
|
||||
|
||||
### 4. Komponenten-Refactoring
|
||||
Die `MsSettingsField`-Komponente wurde erweitert, um den `Modifier` korrekt an das interne `OutlinedTextField` durchzureichen, was die Bindung der `FocusRequester` ermöglichte.
|
||||
|
||||
Die `MsSettingsField`-Komponente wurde erweitert, um den `Modifier` korrekt an das interne `OutlinedTextField`
|
||||
durchzureichen, was die Bindung der `FocusRequester` ermöglichte.
|
||||
|
||||
## ✅ Ergebnis
|
||||
|
||||
Die Tastatur-Navigation folgt nun exakt dem fachlichen Workflow:
|
||||
|
||||
1. Gerätename (Enter/Tab) ->
|
||||
2. Sync-Key (Enter/Tab) ->
|
||||
3. Backup-Pfad (Enter/Tab) ->
|
||||
4. Interaktive Elemente (Slider/Buttons)
|
||||
|
||||
Dies entspricht dem professionellen Anspruch an eine hocheffiziente Desktop-Anwendung ("Information Density over White Space").
|
||||
Dies entspricht dem professionellen Anspruch an eine hocheffiziente Desktop-Anwendung ("Information Density over White
|
||||
Space").
|
||||
|
||||
---
|
||||
🏗️ **[Lead Architect]**
|
||||
+20
-8
@@ -9,39 +9,51 @@ date: 2026-04-18
|
||||
|
||||
## 🎯 Zusammenfassung
|
||||
|
||||
In dieser Session wurde der `DeviceInitialization`-Screen (ehemals Onboarding) der Desktop-App umfassend optimiert. Der Fokus lag auf der Verbesserung der Benutzerführung (UX), der Tastatur-Bedienbarkeit und der strukturellen Klarheit gemäß dem Plug-and-Play Prinzip.
|
||||
In dieser Session wurde der `DeviceInitialization`-Screen (ehemals Onboarding) der Desktop-App umfassend optimiert. Der
|
||||
Fokus lag auf der Verbesserung der Benutzerführung (UX), der Tastatur-Bedienbarkeit und der strukturellen Klarheit gemäß
|
||||
dem Plug-and-Play Prinzip.
|
||||
|
||||
## ✅ Erreichte Meilensteine
|
||||
|
||||
### 1. Tastatur-Navigation (Tab & Enter)
|
||||
|
||||
- **Implementierung:** Alle Eingabefelder wurden um `KeyboardOptions` und `KeyboardActions` erweitert.
|
||||
- **Fluss:** Mit der **Enter-Taste** (ImeAction.Next) springt der Fokus nun logisch zum nächsten Feld.
|
||||
- **Abschluss:** Das letzte Feld in der Master-Konfiguration (Backup-Pfad) schließt die Tastatur-Interaktion mit `ImeAction.Done` ab.
|
||||
- **Abschluss:** Das letzte Feld in der Master-Konfiguration (Backup-Pfad) schließt die Tastatur-Interaktion mit
|
||||
`ImeAction.Done` ab.
|
||||
|
||||
### 2. Linearer Workflow & Layout-Struktur
|
||||
|
||||
- **Neuordnung:** Die Sektion **"Erwartete Clients"** wurde ans Ende der Konfiguration verschoben.
|
||||
- **Logik:** Der Benutzer konfiguriert nun erst sein eigenes Gerät (Name, Key, Backup, Intervall), bevor er optionale Clients definiert. Dies entspricht einem natürlichen Arbeitsfluss.
|
||||
- **Logik:** Der Benutzer konfiguriert nun erst sein eigenes Gerät (Name, Key, Backup, Intervall), bevor er optionale
|
||||
Clients definiert. Dies entspricht einem natürlichen Arbeitsfluss.
|
||||
|
||||
### 3. Optimierter "Client hinzufügen" Flow
|
||||
- **UX-Korrektur:** Der Hinzufügen-Prozess wurde von einem reinen Icon-Button auf einen dedizierten Eingabebereich mit **"Speichern"** und **"Abbrechen"** Buttons umgestellt.
|
||||
|
||||
- **UX-Korrektur:** Der Hinzufügen-Prozess wurde von einem reinen Icon-Button auf einen dedizierten Eingabebereich mit *
|
||||
*"Speichern"** und **"Abbrechen"** Buttons umgestellt.
|
||||
- **Tastatur-Support:** Im Client-Dialog kann nun ebenfalls via Tab/Enter zwischen Name und Rolle navigiert werden.
|
||||
- **Feedback:** Erfogreiches Hinzufügen oder Entfernen von Clients wird nun explizit im Log bestätigt.
|
||||
|
||||
### 4. Konsistentes Diagnose-Logging
|
||||
|
||||
- **Standardisierung:** Alle Log-Ausgaben im Device-Setup wurden auf das Präfix `[DeviceInit]` vereinheitlicht.
|
||||
- **Inhalt:** Pfadauswahl, Client-Management und Fehlerzustände sind nun in der Konsole klar identifizierbar.
|
||||
|
||||
## 🛠️ Technische Details
|
||||
|
||||
- **Datei:** `DeviceInitializationConfig.jvm.kt`
|
||||
- **Komponenten:** `MsSettingsField` wurde erweitert, um `KeyboardOptions` und `KeyboardActions` als Parameter zu akzeptieren.
|
||||
- **Komponenten:** `MsSettingsField` wurde erweitert, um `KeyboardOptions` und `KeyboardActions` als Parameter zu
|
||||
akzeptieren.
|
||||
- **FocusManager:** Nutzung von `LocalFocusManager.current` zur präzisen Steuerung des Eingabefokus.
|
||||
|
||||
## 🚀 Ausblick & Nächste Schritte
|
||||
|
||||
Das Fundament für die Geräte-Initialisierung ist nun ergonomisch und technisch solide.
|
||||
Das Fundament für die Geräte-Initialisierung ist nun ergonomisch und technisch solide.
|
||||
|
||||
1. **Feature-Extraktion:** Als nächster Schritt sollte die `VeranstaltungVerwaltung` (Zentrale) in ein eigenes Feature-Modul (`:frontend:features:veranstaltung-feature`) extrahiert werden.
|
||||
2. **Repository-Anbindung:** Umstellung der Zentrale von Mock-Daten (`Store.kt`) auf das `VeranstaltungRepository` mit Anbindung an die `localdb`.
|
||||
1. **Feature-Extraktion:** Als nächster Schritt sollte die `VeranstaltungVerwaltung` (Zentrale) in ein eigenes
|
||||
Feature-Modul (`:frontend:features:veranstaltung-feature`) extrahiert werden.
|
||||
2. **Repository-Anbindung:** Umstellung der Zentrale von Mock-Daten (`Store.kt`) auf das `VeranstaltungRepository` mit
|
||||
Anbindung an die `localdb`.
|
||||
|
||||
**Status:** Device-Setup ist "Production-Ready". 🚀
|
||||
+19
-12
@@ -9,21 +9,28 @@ wurde das Onboarding in das neue Plug-and-Play Modul `device-initialization` (AD
|
||||
### 🛡️ Verifizierte Fakten (Stand: 18.04.2026, 15:45 Uhr)
|
||||
|
||||
1. **Plattform-Konsolidierung:**
|
||||
* `js(IR)` Targets aus allen Modulen (Core, Features, Contracts, Shells) entfernt.
|
||||
* Alle `src/jsMain/` und `src/jsTest/` Verzeichnisse wurden gelöscht.
|
||||
* Der Build läuft nun ohne "Unresolved platforms: [js]" Fehler durch.
|
||||
|
||||
* `js(IR)` Targets aus allen Modulen (Core, Features, Contracts, Shells) entfernt.
|
||||
* Alle `src/jsMain/` und `src/jsTest/` Verzeichnisse wurden gelöscht.
|
||||
* Der Build läuft nun ohne "Unresolved platforms: [js]" Fehler durch.
|
||||
|
||||
2. **Shell-Härtung:**
|
||||
* `meldestelle-desktop`: Reines JVM-Modul (WASM entfernt).
|
||||
* `meldestelle-web`: Reines WASM-Modul (JVM entfernt).
|
||||
* Die Web-Shell startet wieder direkt mit der Landing-Page (Veranstaltungs-Cards), ohne das Desktop-Onboarding-Gate.
|
||||
|
||||
* `meldestelle-desktop`: Reines JVM-Modul (WASM entfernt).
|
||||
* `meldestelle-web`: Reines WASM-Modul (JVM entfernt).
|
||||
* Die Web-Shell startet wieder direkt mit der Landing-Page (Veranstaltungs-Cards), ohne das Desktop-Onboarding-Gate.
|
||||
|
||||
3. **Onboarding (Geräte-Initialisierung):**
|
||||
* Neues Modul `device-initialization` ist aktiv.
|
||||
* ViewModel-basierte Logik (StateFlow) implementiert.
|
||||
* Domain-Sprache auf "Geräte-Initialisierung" vereinheitlicht.
|
||||
|
||||
* Neues Modul `device-initialization` ist aktiv.
|
||||
* ViewModel-basierte Logik (StateFlow) implementiert.
|
||||
* Domain-Sprache auf "Geräte-Initialisierung" vereinheitlicht.
|
||||
|
||||
4. **Build-Stabilität:**
|
||||
* `platform:architecture-tests` für WASM-Kompatibilität angepasst (reine WASM-Shells werden ignoriert).
|
||||
* `yarn.lock` für die neue WASM-Infrastruktur synchronisiert.
|
||||
* `./gradlew clean build` ist erfolgreich (700+ Tasks).
|
||||
|
||||
* `platform:architecture-tests` für WASM-Kompatibilität angepasst (reine WASM-Shells werden ignoriert).
|
||||
* `yarn.lock` für die neue WASM-Infrastruktur synchronisiert.
|
||||
* `./gradlew clean build` ist erfolgreich (700+ Tasks).
|
||||
|
||||
---
|
||||
|
||||
+11
-6
@@ -13,14 +13,19 @@ modulare Bauweise.
|
||||
1. **ADR-0024 Erstellt:** Festschreibung der "Plug-and-Play" Strategie. Komponenten müssen fachlich autark sein und
|
||||
ihren State via ViewModel-Interfaces erhalten.
|
||||
2. **Ping-Service Refactoring:**
|
||||
* `PingScreen` wurde in `PingActionGroup` und `TerminalConsole` zerlegt.
|
||||
* `AuthStatusCard` wurde als globale Plug-and-Play Komponente in `frontend:core:auth` extrahiert.
|
||||
|
||||
* `PingScreen` wurde in `PingActionGroup` und `TerminalConsole` zerlegt.
|
||||
* `AuthStatusCard` wurde als globale Plug-and-Play Komponente in `frontend:core:auth` extrahiert.
|
||||
|
||||
3. **Keycloak/Auth Integration:**
|
||||
* Die `AuthStatusCard` zeigt im Ping-Screen den Live-Status (User, Rollen) an.
|
||||
* Login- & Logout-Flows sind direkt integriert und funktionieren ohne App-Neustart.
|
||||
|
||||
* Die `AuthStatusCard` zeigt im Ping-Screen den Live-Status (User, Rollen) an.
|
||||
* Login- & Logout-Flows sind direkt integriert und funktionieren ohne App-Neustart.
|
||||
|
||||
4. **Desktop UI Cleanup:**
|
||||
* Navigationsleiste: "Sync" wurde korrekt in "Ping" umbenannt.
|
||||
* Routing: `LoginScreen` ist nun nahtlos in das `DesktopMainLayout` integriert.
|
||||
|
||||
* Navigationsleiste: "Sync" wurde korrekt in "Ping" umbenannt.
|
||||
* Routing: `LoginScreen` ist nun nahtlos in das `DesktopMainLayout` integriert.
|
||||
|
||||
### 🧐 QA & Validierung
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
agent: 🏗️ Lead Architect & 🧐 QA Specialist
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
# 📜 Session-Abschluss: Stabilisierung & Security-Fix Ping-Service (Update)
|
||||
|
||||
## 🎯 Zusammenfassung
|
||||
|
||||
In dieser Session wurde die fehlerhafte Authentifizierung des **Ping-Service (ConnectivityCheck)** bei Zugriffen via
|
||||
Postman und externen Clients behoben. Die Hauptursache war ein **Issuer-Mismatch** im JWT-Token zwischen der internen
|
||||
Docker-Infrastruktur (`keycloak:8080`) und der externen Sicht des Clients (`localhost:8180`).
|
||||
|
||||
## ✅ Erreichte Meilensteine
|
||||
|
||||
### 1. Diagnose & Ursachenanalyse
|
||||
|
||||
- **Issuer-Mismatch:** Spring Security validiert standardmäßig den `iss` Claim. Da Keycloak im Docker-Netzwerk einen
|
||||
anderen Hostnamen hat als für den externen Client, schlug die Validierung fehl (401 Unauthorized), obwohl der Token an
|
||||
sich gültig war.
|
||||
- **Autorisierungs-Lücke:** Der Ping-Service (Resource Server) und das Gateway lehnten Token ab, deren Issuer nicht
|
||||
exakt der konfigurierten `issuer-uri` entsprach.
|
||||
|
||||
### 2. Flexibilisierung der Security-Validierung
|
||||
|
||||
- **Custom JWT Decoder (Gateway):** Implementierung eines `ResilienceReactiveJwtDecoder`, der die Issuer-Validierung
|
||||
überspringt, aber weiterhin Signatur und Zeitstempel prüft. Dies ermöglicht den nahtlosen Wechsel zwischen
|
||||
Docker-internen und externen Aufrufen.
|
||||
- **Custom JWT Decoder (Ping-Service):** Analog wurde in der `GlobalSecurityConfig` ein `JwtDecoder` konfiguriert, der
|
||||
auf die strikte Issuer-Prüfung verzichtet.
|
||||
|
||||
### 3. Security Hardening & Konsistenz
|
||||
|
||||
- **CORS-Fix:** Die `allowedHeaders` im Gateway wurden auf `*` gesetzt, um Inkompatibilitäten mit Postman-Headern zu
|
||||
vermeiden.
|
||||
- **Endpunkt-Konsistenz:** Die Postman-Tests für `secure`, `sync` (authentifiziert) und `enhanced` (authentifiziert)
|
||||
sind nun wieder erfolgreich, da das Gateway und der Service den Token korrekt akzeptieren.
|
||||
|
||||
## 🛠️ Technische Änderungen
|
||||
|
||||
- `backend/infrastructure/gateway/src/main/kotlin/at/mocode/infrastructure/gateway/security/SecurityConfig.kt`: Neuer
|
||||
`ResilienceReactiveJwtDecoder` mit deaktiviertem Issuer-Check.
|
||||
- `backend/infrastructure/security/src/main/kotlin/at/mocode/infrastructure/security/GlobalSecurityConfig.kt`: Explizite
|
||||
`JwtDecoder` Bean zur Umgehung des Issuer-Mismatches hinzugefügt.
|
||||
- `backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json`: Refactoring
|
||||
und Erweiterung der Connectivity-Tests.
|
||||
|
||||
## 🚀 Status-Report
|
||||
|
||||
Alle Connectivity-Endpunkte (Simple, Health, Public, Sync, Secure, Enhanced) sind nun sowohl öffentlich als auch
|
||||
authentifiziert (je nach Anforderung) erreichbar. Die Infrastruktur ist robuster gegenüber Umgebungsunterschieden (Local
|
||||
vs. Docker) geworden.
|
||||
|
||||
**Status:** Authentifizierung stabilisiert und Issuer-Mismatch behoben. 🟢
|
||||
+13
-8
@@ -11,16 +11,21 @@ aktuellen Compose-Standard zu entsprechen.
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
|
||||
1. **Code-Cleanup:**
|
||||
* `DesktopMainLayout.kt`: Ungenutzte Property `TopBarColor` und die nicht mehr benötigte Funktion `PlaceholderScreen`
|
||||
entfernt.
|
||||
* `LoginViewModel.kt`: Die ungenutzte `apiClient` Property (HttpClient) aus dem Konstruktor entfernt und das
|
||||
Koin-Modul `AuthModule.kt` entsprechend angepasst.
|
||||
|
||||
* `DesktopMainLayout.kt`: Ungenutzte Property `TopBarColor` und die nicht mehr benötigte Funktion `PlaceholderScreen`
|
||||
entfernt.
|
||||
* `LoginViewModel.kt`: Die ungenutzte `apiClient` Property (HttpClient) aus dem Konstruktor entfernt und das
|
||||
Koin-Modul `AuthModule.kt` entsprechend angepasst.
|
||||
|
||||
2. **UI-Modernisierung:**
|
||||
* `AuthStatusCard.kt`: Veraltete `Icons.Default.Login` und `Icons.Default.Logout` durch die modernen `AutoMirrored`
|
||||
Versionen ersetzt.
|
||||
|
||||
* `AuthStatusCard.kt`: Veraltete `Icons.Default.Login` und `Icons.Default.Logout` durch die modernen `AutoMirrored`
|
||||
Versionen ersetzt.
|
||||
|
||||
3. **Dokumentation:**
|
||||
* Das Architektur-Dokument **ADR-0024** (Plug-and-Play Architektur) wurde vollständig ins Deutsche übersetzt und als
|
||||
`0024-plug-and-play-architektur.md` gespeichert. Das englische Original wurde gelöscht.
|
||||
|
||||
* Das Architektur-Dokument **ADR-0024** (Plug-and-Play Architektur) wurde vollständig ins Deutsche übersetzt und als
|
||||
`0024-plug-and-play-architektur.md` gespeichert. Das englische Original wurde gelöscht.
|
||||
|
||||
### 🧐 QA & Validierung
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user