Phase 1: Stammdatenverwaltung
Ab hier fuehrt die Wehr ihren Bestand in FLORIAN. Datenmodell: - Standort, Geraeteraum, Geraetetyp, Qualifikationstyp und Qualifikation - Fahrzeug um Fahrgestellnummer, DIN-Typ, Erstzulassung, Sitzplaetze, Tankinhalt und UVV-Frist erweitert - Geraet um Geraetetyp, Lebensdauerkategorie, errechnetes Lebensdauerende, Anschaffungspreis und die Lagerung erweitert - Ein Geraet steht entweder an einem Standort oder ist auf einem Fahrzeug verlastet. Eine Pruefbedingung setzt das durch, ein Trigger stellt zusaetzlich sicher, dass ein angegebener Geraeteraum zum angegebenen Fahrzeug gehoert. - RLS auf allen neuen Tabellen, Trigram-Indizes fuer die Volltextsuche Fachlogik: - lib/stammdaten/fristen.ts rechnet Prueftermine, Lebensdauer und den abgeleiteten Geraetestatus. Der Geraetetyp gibt vor, das Geraet darf abweichen. - lib/stammdaten/qr.ts und qr-parser.ts erzeugen und lesen die Codes - lib/stammdaten/etiketten.ts baut den A4-Bogen mit 65 Etiketten - lib/stammdaten/import.ts liest CSV und Excel, erkennt deutsche Datums- und Zahlenformate, Windows-1252 und Dubletten innerhalb der Datei - lib/pdf.ts spricht Gotenberg an Oberflaeche: - Geraeteliste mit Volltextsuche, Statusfilter, serverseitiger Sortierung, Blaettern, Spaltenauswahl und Massenbearbeitung - Geraetedetail mit QR-Code, Pruefvorgabe aus dem Geraetetyp und Verlauf - Fahrzeugliste und -detail mit Beladung nach Beladeordnung - Mitgliederliste nach Abteilung, Mitgliedsdetail mit Qualifikationen - Qualifikationen mit Ablaufwarnung je Vorwarnzeit des Typs - Import-Assistent mit Zuordnung und Vorschau vor dem Uebernehmen - QR-Scanner ueber die Kamera, mit Eingabefeld als Rueckfallweg Behoben: - Fristenrechnung lief ueber startOfDay aus date-fns und damit in der Zeitzone des Servers. Ein DATE aus der Datenbank kommt als UTC-Mitternacht und wurde dadurch auf den Vortag geschoben — Fristen waeren einen Tag zu frueh faellig geworden. Jetzt eigene Kalenderarithmetik auf UTC-Bestandteilen. - ctx.sitzung blieb in tRPC-Prozeduren nullbar, weil t.middleware() die Verengung der vorigen Middleware verwirft. Middleware jetzt direkt an .use(). - CardTitle war ein div und damit keine Ueberschrift. Wer mit einer Sprachausgabe arbeitet, springt von Ueberschrift zu Ueberschrift; Karten tauchten in dieser Navigation nicht auf. Daten und Tests: - Seed um 3 Standorte, 20 Geraeteraeume, 14 Geraetetypen mit echten Pruefvorgaben, 49 Geraete und 107 Qualifikationen erweitert - 104 Vitest-Tests (vorher 32), 44 Playwright-Tests (vorher 10) - Anleitung um sieben bebilderte Abschnitte erweitert, Changelog, Devlog, Aufwandsschaetzung und Roadmap fortgeschrieben Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
4b3021bb50
commit
26b62a3477
+80
-1
@@ -8,7 +8,86 @@ Die Regeln dazu stehen in [docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
|
||||
|
||||
## [Unveröffentlicht]
|
||||
|
||||
Noch nichts. Nächster Schritt ist Phase 1 (Stammdatenverwaltung).
|
||||
Noch nichts. Nächster Schritt ist Phase 2 (Wartungs- und Prüfmanagement).
|
||||
|
||||
## [0.2.0] — 2026-09-03
|
||||
|
||||
Phase 1: Stammdaten. Ab hier führt die Wehr ihren Bestand in FLORIAN — mit
|
||||
Standorten, Fahrzeugen samt Beladeordnung, Gerätetypen als Vorgabe und
|
||||
Geräten, die per QR-Code am Regal auffindbar sind.
|
||||
|
||||
### Hinzugefügt
|
||||
|
||||
**Datenmodell**
|
||||
|
||||
- `Standort` (Gerätehaus, Lager, Außenstelle, Werkstatt) mit PostGIS-Punkt für
|
||||
die Karte ab Phase 6.
|
||||
- `Geraeteraum` — die Fächer am Fahrzeug (G1 bis G6, Heck, Dach,
|
||||
Mannschaftsraum), in Beladereihenfolge sortierbar.
|
||||
- `Geraetetyp` als Vorgabe für Prüfintervall, Prüfvorschrift und Lebensdauer.
|
||||
Ein einzelnes Gerät darf davon abweichen; sonst gilt der Typ.
|
||||
- `Qualifikationstyp` und `Qualifikation` mit Gültigkeitsdauer und eigener
|
||||
Vorwarnzeit je Typ.
|
||||
- `Fahrzeug` erweitert um Fahrgestellnummer, DIN-Typkurzzeichen, Erstzulassung,
|
||||
Sitzplätze, Tankinhalt, Gesamtmasse und die UVV-Frist.
|
||||
- `Geraet` erweitert um Gerätetyp, Lebensdauerkategorie, errechnetes
|
||||
Lebensdauerende, Anschaffungspreis und die Lagerung.
|
||||
|
||||
**Regeln in der Datenbank**
|
||||
|
||||
- Ein Gerät steht entweder an einem Standort oder ist auf einem Fahrzeug
|
||||
verlastet — eine Prüfbedingung setzt das durch, ein Trigger stellt zusätzlich
|
||||
sicher, dass ein angegebener Geräteraum auch zum angegebenen Fahrzeug gehört.
|
||||
- Row Level Security auf allen neuen Tabellen.
|
||||
- Trigram-Indizes für die Volltextsuche über Geräte, Fahrzeuge und Personen.
|
||||
|
||||
**Funktionen**
|
||||
|
||||
- Geräteliste mit Volltextsuche, Statusfilter, serverseitiger Sortierung,
|
||||
Blättern und Spaltenauswahl. Die Spaltenauswahl bleibt je Browser gespeichert.
|
||||
- Massenbearbeitung: Status mehrerer Geräte auf einmal setzen, Geräte umlagern.
|
||||
Jede Änderung erzeugt einen eigenen Protokolleintrag am jeweiligen Gerät.
|
||||
- QR-Code je Gerät. Der Code zeigt auf `/g/<inventarnummer>` und führt nach der
|
||||
Anmeldung direkt zur Gerätedetailseite.
|
||||
- Etikettenbogen als PDF über Gotenberg: DIN A4 mit 65 Etiketten
|
||||
(38,1 × 21,2 mm). Der Druck kann an einer beliebigen Position beginnen, damit
|
||||
angebrochene Bögen weiterverwendet werden können.
|
||||
- QR-Scan über die Kamera im Browser, mit Eingabefeld als Rückfallweg.
|
||||
- Import aus CSV und Excel: Spalten werden nach den Überschriften automatisch
|
||||
zugeordnet, die Vorschau zeigt Zeile für Zeile, was übernommen würde und was
|
||||
daran nicht stimmt. Geschrieben wird erst nach Bestätigung.
|
||||
- Gerätehistorie und Fahrzeughistorie, gerendert aus dem Audit-Log.
|
||||
- Qualifikationen mit Ablaufwarnung, gerechnet mit der Vorwarnzeit des
|
||||
jeweiligen Typs.
|
||||
- Fahrzeugdetail zeigt die Beladung nach Geräteräumen statt alphabetisch.
|
||||
|
||||
**Daten und Tests**
|
||||
|
||||
- Der Seed legt jetzt zusätzlich 3 Standorte, 20 Geräteräume, 14 Gerätetypen
|
||||
mit echten Prüfvorgaben (DGUV, DIN, vfdb), 49 Geräte und 107 Qualifikationen
|
||||
an. Fristen sind bewusst gestreut, damit die Ampeln etwas zeigen.
|
||||
- 104 Vitest-Tests (vorher 32), davon 40 zum Import und 32 zu QR und Fristen.
|
||||
- 44 Playwright-Tests (vorher 10) über Desktop und Tablet.
|
||||
|
||||
### Geändert
|
||||
|
||||
- **Fristenrechnung auf UTC-Kalenderarithmetik umgestellt.** Vorher wurde über
|
||||
`startOfDay` aus date-fns gerechnet, das die Zeitzone des Servers verwendet.
|
||||
Ein Prüfdatum kommt aus der Datenbank als UTC-Mitternacht und wurde dabei auf
|
||||
den Vortag zurückgeschoben — Fristen wären einen Tag zu früh fällig geworden.
|
||||
- `CardTitle` rendert eine echte Überschrift statt eines `div`. Wer mit einer
|
||||
Sprachausgabe arbeitet, springt von Überschrift zu Überschrift; Karten
|
||||
tauchten in dieser Navigation vorher gar nicht auf.
|
||||
- Die Entwicklungsanzeige von Next.js ist abgeschaltet, damit sie nicht in den
|
||||
Bildern der Anleitung mitläuft.
|
||||
|
||||
### Sicherheit
|
||||
|
||||
- Der Etikettendruck wird protokolliert (`EXPORTIERT`) — damit ist
|
||||
nachvollziehbar, wann welche Aufkleber erzeugt wurden.
|
||||
- Der Import übernimmt keine Werte, die der Browser geschickt hat: die Datei
|
||||
wird beim Übernehmen erneut serverseitig eingelesen und geprüft. Sonst ließe
|
||||
sich die Vorschau umgehen.
|
||||
|
||||
## [0.1.0] — 2026-09-03
|
||||
|
||||
|
||||
Reference in New Issue
Block a user