Florian WildeandClaude Opus 5
abacad1cb7
Eine veroeffentlichte Vorlagen-Version ist fuer immer unveraenderlich — daran haengt, dass ein archivierter Lauf in zehn Jahren noch genau die Schritte zeigt, mit denen er gestartet wurde. Die Regel steht deshalb zweimal: im Service, der die verstaendliche Meldung gibt, und in der Datenbank, die die Garantie gibt. Vier Trigger fangen Schreibzugriffe ab, die nicht durch den Service kommen — Migrationen, psql, der Seed und ab Phase 4 die Connectoren — und versperren den Rueckweg nach ENTWURF, der alles andere ausgehebelt haette. - Service: anlegen, Kopfdaten bearbeiten, Entwurf als tiefe Kopie der letzten veroeffentlichten Version, speichern, veroeffentlichen, verwerfen, duplizieren, archivieren - Hoechstens ein Entwurf je Vorlage, durchgesetzt vom partiellen Index; zwei gleichzeitige Klicks auf „Bearbeiten“ bekommen denselben Entwurf statt eines Fehlers - Optimistisches Sperren ueber geaendertAm: wer auf einem ueberholten Stand speichert, wird abgewiesen statt die Arbeit des anderen spurlos zu ersetzen - JSON-Export und -Import samt Format-Dokumentation; der Export ist nachsichtig, der Import streng - src/lib/validierung.ts als einzige Zod-Quelle mit deutschen Meldungen, per ESLint-Regel erzwungen Der unabhaengige Review fand drei Blocker, alle an der Mandantengrenze: der Suchfilter brachte ein zweites OR mit und ueberschrieb die Kundenbedingung, Historie und Aufbau einer Version filterten gar nicht. Zu queries/vorlagen.ts gab es keinen Test — jetzt gibt es tests/vorlagen-sicht.test.ts. 428 Tests gruen (vorher 336). Schliesst #009 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.1 KiB
2.1 KiB
#011 M6 – Mitarbeiter, Abteilungen, Geräte
Status: offen Meilenstein: v0.1.0 Labels: phase-1, backend, frontend Geschätzt: 9 h Tatsächlich: –
Ziel
Die Stammdaten, an denen die Historie hängt. Mitarbeiter und Geräte werden nie gelöscht, damit archivierte Läufe für immer auf sie zeigen können.
Aufgaben
- Mitarbeiterliste: Suche über Anzeigename, Mail, UPN und
sam, Filter nach Abteilung und Aktiv-Status - Mitarbeitersuche als wiederverwendbare Komponente: standardmäßig nur aktive, Umschalter „auch deaktivierte“ fürs Offboarding
- Mitarbeiterseite: Stammdaten, Abteilung, Vorgesetzter, seine Geräte, alle Läufe chronologisch (Onboarding, Übergaben, Offboarding)
- Mitarbeiter manuell anlegen und bearbeiten (
herkunft = MANUELL); synchronisierte Felder sind beiherkunft = ABGLEICHgesperrt - Deaktivieren statt löschen (
aktiv = false) - Abteilungen: Name (eindeutig je Kunde), Ziel-OU, Standardgruppen (
String[]), Mail-Domain, Notizen - Geräte: Stammdaten nach Vorgabe, Pflichtregel „
hostnameoderbezeichnungmuss gesetzt sein“, Besitzer optional - Geräteliste mit Suche über Hostname, Bezeichnung, Seriennummer und
tagCode, Filter nach Typ - CSV-Import für Geräte (
hostname,label,serialNumber,inventoryNumber,type,model),tagCodewird beim Import erzeugt; eigenersrc/lib/csv.ts - Archivieren statt Löschen, sobald Läufe an einem Gerät oder einer Abteilung hängen
- Screenshots Mitarbeiterliste, Mitarbeiterseite, Geräteliste, Abteilungen in
docs/screenshots/m6/
Akzeptanzkriterien
- Test: Mitarbeitersuche liefert standardmäßig nur
aktiv = true; mit Umschalter auch deaktivierte - Test: ein Gerät ohne
hostnameund ohnebezeichnungwird abgelehnt - Test: ein Gerät mit Läufen lässt sich nicht löschen, nur archivieren
- Test:
tagCodeeines bestehenden Geräts lässt sich nicht ändern - Test: CSV-Import erzeugt je Zeile einen
tagCode, meldet fehlerhafte Zeilen einzeln und bricht nicht ab - Test: bei
herkunft = ABGLEICHlehnt der Service Änderungen an synchronisierten Feldern ab