93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
# Werkstattablauf
|
|
|
|
## Geräteerkennung
|
|
|
|
Beim Start liest die Anwendung die verfügbaren DMI-Felder. Bevorzugt wird eine
|
|
gültige System-UUID. Fehlt sie, wird eine gehashte Kombination aus Hersteller und
|
|
Seriennummer verwendet. Platzhalter wie `To be filled by O.E.M.` sind ungültig.
|
|
Falls der Linux-Benutzer einzelne DMI-Felder nicht lesen darf, müssen die Rechte auf
|
|
dem Werkstattrechner passend eingerichtet werden.
|
|
|
|
Die Hardware-ID wird an `POST /api/v1/devices/resolve/` gesendet. Der Server ordnet
|
|
sie einem vorhandenen Gerät zu oder vergibt atomar eine neue Gerätenummer. UUID und
|
|
Seriennummer können als Aliase dasselbe Gerät bezeichnen. Widersprüche werden zur
|
|
manuellen Prüfung abgelehnt.
|
|
|
|
## Automatische Erfassung
|
|
|
|
Für neue Geräte und Geräte in **Eingang** startet ein Kurzscan. Erfasst werden
|
|
Hersteller, Modell, CPU, installierter RAM sowie Größe und Art aller Laufwerke. Die
|
|
Daten werden revisionsgesichert über den Intake-Endpunkt geschrieben. Ein Gerät in
|
|
einem späteren Prozessschritt wird durch den automatischen Scan nicht überschrieben.
|
|
|
|
## Inspektion
|
|
|
|
Jeder Prüfschritt besitzt eine Aktion, eine verständliche Anleitung, ein sichtbares
|
|
Ergebnis und eine Wiederholungsmöglichkeit. Verfügbare Schritte umfassen Display,
|
|
Tastatur, Touchpad, WLAN, Lautsprecher, Mikrofon, Kamera, USB-Anschlüsse, Laden,
|
|
Temperatur, Stabilität und SMART-Daten jedes internen Laufwerks.
|
|
|
|
Ergebnisse unterscheiden:
|
|
|
|
- bestanden
|
|
- Hardwarefehler
|
|
- Test nicht verfügbar
|
|
- Einrichtungsproblem
|
|
- nicht geprüft
|
|
- nicht vorhanden
|
|
- Bestätigung erforderlich
|
|
|
|
Ein fehlendes Werkzeug oder eine fehlende Berechtigung wird niemals als
|
|
Hardwaredefekt gewertet. Optionale Hardware muss ausdrücklich als nicht vorhanden
|
|
bestätigt werden.
|
|
|
|
Beim Start einer Prüfung wird der Zustand **Inspektion** an den Server gesendet.
|
|
Zwischenstände und der Abschluss verwenden unveränderliche Anforderungs-IDs, damit
|
|
ein Verbindungsabbruch keine doppelten Einträge erzeugt. Ein Abschluss benötigt
|
|
einen Technikernamen und vollständig bewertete Prüfschritte.
|
|
|
|
## Unterbrechung und Offlinebetrieb
|
|
|
|
Der lokale Prüfstand wird atomar gespeichert. Nach einem Neustart öffnet die
|
|
Anwendung die letzte unvollständige Prüfung mit Messwerten und Notizen. Noch nicht
|
|
bestätigte Uploads liegen in `outbox/inspections/`; bestätigte Uploads werden nach
|
|
`outbox/sent/` verschoben. Beim nächsten Start werden gespeicherte Prüfungen erneut
|
|
in die Warteschlange aufgenommen.
|
|
|
|
## Reparaturen und Bericht
|
|
|
|
Eine Reparatur enthält Bauteil, Tätigkeit, Ersatzteil, Techniker und Zeitpunkt. Der
|
|
vorherige Befund bleibt erhalten und der betroffene Test wird erneut geöffnet. Der
|
|
HTML-Abschlussbericht enthält Spezifikationen, Laufwerks- und Akkuzustand,
|
|
Messwerte, Mängel, Reparaturverlauf und technische Freigabe.
|
|
|
|
## WLAN und Inventarverbindung
|
|
|
|
Das Werkstatt-WLAN wird erst nach erfolgreicher Verbindung gespeichert. Die Datei
|
|
`config/workshop-wifi.json` ist nur für den Besitzer lesbar und kann in den
|
|
Einstellungen ersetzt oder gelöscht werden. Das Passwort wird über die
|
|
Standardeingabe an NetworkManager übergeben und erscheint nicht in Prozessargumenten.
|
|
|
|
Die Inventarverbindung benötigt:
|
|
|
|
```json
|
|
{"url": "https://inventory.example.org"}
|
|
```
|
|
|
|
Der API-Schlüssel liegt separat in `config/inventory-api-key`. Für einen privaten
|
|
HTTPS-Server kann `config/inventory-server.crt` die öffentliche CA enthalten.
|
|
Zertifikats- und Hostnamenprüfung bleiben aktiv.
|
|
|
|
## Abnahme eines neuen Builds
|
|
|
|
Vor dem Werkstatteinsatz sind mindestens diese Punkte auf echter Hardware zu prüfen:
|
|
|
|
1. Start der eigenständigen Datei in der vorgesehenen Linux-Umgebung
|
|
2. persistente Daten nach Neustart der Anwendung und des Rechners
|
|
3. automatische Wiederverbindung mit dem WLAN
|
|
4. richtige Gerätezuordnung und Dublettenwarnung
|
|
5. Intake-Synchronisation ohne Überschreiben späterer Zustände
|
|
6. Ein- und Ausgabegeräte sowie jedes Laufwerk
|
|
7. Offline-Warteschlange und Wiederholung nach Verbindungsabbruch
|
|
8. druckbarer Bericht
|