Files

Torsten Schulz (local) 0e539710c0 feat: Add password reset functionality with request and reset forms

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

2026-06-02 15:28:38 +02:00

2.3 KiB

Raw Permalink Blame History

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.

2.3 KiB Raw Permalink Blame History