0e539710c0
feat: Implement price list import feature with preview and apply options feat: Create price rules management page with CRUD operations feat: Develop quotes management page with itemized quotes and status tracking feat: Introduce organization registration page for new users feat: Build suppliers management page with detailed supplier information feat: Create users management page for inviting and managing roles chore: Add TypeScript configuration for improved type checking chore: Set up Vite configuration for development server and API proxy chore: Add Vite environment type definitions for better TypeScript support
59 lines
2.3 KiB
Markdown
59 lines
2.3 KiB
Markdown
# Fensterkonzept
|
|
|
|
Die Anwendung ist nach dem Login fensterbasiert. Das Dashboard bleibt die
|
|
Hauptfläche und zeigt Status, Live-Verbindung und zusammenfassende Daten. Alle
|
|
fachlichen Arbeitsbereiche öffnen als eigene Fenster.
|
|
|
|
## Grundregeln
|
|
|
|
- Vor dem Login sind nur Login und Registrierung sichtbar.
|
|
- Nach dem Login bleibt das Dashboard die Basisansicht.
|
|
- Navigationseinträge außer Dashboard öffnen ein Fenster.
|
|
- Ein bereits geöffnetes Fenster wird fokussiert, nicht doppelt geöffnet.
|
|
- Fenster können geschlossen und später erneut geöffnet werden.
|
|
- Fenster behalten pro Benutzer Position, Größe und Reihenfolge, soweit der
|
|
jeweilige Client das technisch unterstützt.
|
|
- Offene Listenfenster müssen auf Live-Events reagieren und ihre Daten
|
|
aktualisieren oder als veraltet markieren.
|
|
|
|
## Einheitliche Fensteraktionen
|
|
|
|
- `Öffnen`: Fenster wird erzeugt oder, falls vorhanden, fokussiert.
|
|
- `Fokussieren`: Fenster erhält die höchste Z-Reihenfolge.
|
|
- `Schließen`: Fenster wird aus der Arbeitsfläche entfernt.
|
|
- `Verschieben`: Fensterposition wird geändert.
|
|
- `Größe ändern`: Fensterabmessungen werden geändert.
|
|
- `Aktualisieren`: Fenster lädt seine Daten neu oder reagiert auf ein
|
|
Backend-Event.
|
|
|
|
## Webclient
|
|
|
|
- Fenster werden über der Dashboard-Fläche dargestellt.
|
|
- Position und Größe sind per Maus oder Pointer veränderbar.
|
|
- Fensterstatus wird im `localStorage` pro Benutzer gespeichert.
|
|
- Wiederherstellung erfolgt nach Login oder Reload.
|
|
|
|
## Desktopclient
|
|
|
|
- Fenster verwenden native `egui::Window`-Instanzen.
|
|
- Benutzerrechte, Firmendaten und Freischaltungen sind als Fenster umgesetzt.
|
|
- Weitere fachliche Module folgen demselben Muster.
|
|
|
|
## Live-Updates
|
|
|
|
Backend-Änderungen erzeugen Events über die bestehende Socket-Verbindung. Clients
|
|
verwenden diese Events, um offene Fenster zu aktualisieren oder deren Status auf
|
|
`Aktualisiert` zu setzen.
|
|
|
|
Für Phase 2 genügt ein gemeinsamer Live-Event-Store pro Client. Fachliche
|
|
Module können später gezielt nach Entity-Typ filtern.
|
|
|
|
## Parallelbearbeitung und Konflikte
|
|
|
|
- Schreibvorgänge laufen immer über das Backend.
|
|
- Das Backend entscheidet final über Berechtigungen und Datenstand.
|
|
- Bei konkurrierenden Änderungen wird zunächst eine frische Liste geladen.
|
|
- Für spätere fachliche Datensätze wird ein Versionsfeld oder `updated_at`
|
|
benötigt, damit Konflikte vor dem Speichern erkennbar sind.
|
|
|