Eduard Wisch
90cbee6e81
Die Dauerueberwachung lief im generischen else-Zweig und wurde von
netdiagPdfFlattenResult() zu EINER |-getrennten Zeile zusammengeschoben.
Bei zehn ueberwachten Geraeten standen damit die zehn Geraete-Zeilen und
saemtliche Einzelausfaelle in einer einzigen Tabellenzelle - vollstaendig,
aber beim Kunden nicht lesbar. Dauertest und WLAN-Kanal hatten laengst je
einen Tabellen-Renderer, der Monitor nicht.
netdiagPdfMonitor() gibt jetzt aus: Kennzahlenzeile, Tabelle "Ueberwachte
Geraete", Tabelle "Einzelne Ausfaelle" mit Uhrzeiten, Hinweis zum
Messverfahren am Schluss. Tabellenkoepfe wiederholen sich nach einem
Seitenumbruch.
Die Falle dabei, gegen die im Code ein Kommentar steht: beim Dauertest
fuehrt ein gesetztes 'hinweis' zum sofortigen Abbruch der Ausgabe. Der
Monitor legt aber IMMER einen Hinweis an (das Messverfahren gehoert zur
Aussage dazu) - derselbe Aufbau haette hier bei jedem Lauf alle Zahlen
verschluckt. Nur 'fehler' bricht ab.
Obergrenze 200 Ausfallzeilen gegen ein im Sekundentakt flappendes Geraet.
Gekuerzt wird sichtbar ("... und N weitere Ausfaelle") - stilles Kuerzen
waere bei einem Abnahmebeleg eine Falschaussage.
Ausserdem: 'ausfallzeitSek' heisst jetzt "Ausfallzeit (schlechtestes
Geraet)". Der Wert ist der des schlechtesten Geraets, nicht die Summe -
bei zehn Geraeten las sich "Ausfallzeit: 8 min" wie eine Gesamtaussage.
Geprueft gegen die lokale Testinstanz mit vier konstruierten Faellen
(10 Geraete mit Aussetzern, ein durchgehend totes Geraet, 250 Ausfaelle
ueber sechs Seiten, abgerissener Lauf) und gegen die echte Monitor-
Messung aus ND2026-0016. PDF gerendert und angesehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .forgejo/workflows | ||
| admin | ||
| api | ||
| class | ||
| core/modules | ||
| langs | ||
| lib | ||
| sql | ||
| ChangeLog.md | ||
| netdiag_object_tab.php | ||
| netdiagindex.php | ||
| netdiagprotocol_card.php | ||
| README.md | ||
NetDiag — Netzwerk-Diagnose für Dolibarr
Dolibarr-Modul für die Ablage von Netzwerk-Diagnose-Protokollen. Erfasst per
mobiler App (siehe Projekt NetzwerkDiagnose/app) gefundene Geräte, Ports und
Messungen und hängt die Protokolle dauerhaft an Kunde und Auftrag.
Funktionen
- Datenmodell: Protokoll → Geräte → Messungen (
llx_netdiag_*) - Tab Netzwerk-Diagnose an Kunde (thirdparty) und Auftrag (commande)
- JSON-API unter
/custom/netdiag/api/für die mobile App. Anmeldung seit v1.1.0 über das zentrale Auth-Modul awlauth (Brute-Force-Bremse, gemeinsame Sitzungsliste, „Gerät abmelden"); der alte modul-eigene JWT-Pfad bleibt als Rückfall, bis alle Geräte die neue APK haben - PDF-Protokoll, wird im Dokumentenarchiv (ECM) abgelegt
- Zwei Sichten auf dieselben Messdaten: die Technikeransicht zeigt alles, das Kunden-PDF nur eine Whitelist (siehe „Neue Messart" unten)
- Rechtesystem:
netdiag → protocol → read/write/delete - Mehrsprachig (de_DE, en_US)
- QR-Code zum App-Download in der Modul-Einrichtung
Installation
- Verzeichnis
netdiag/nachhtdocs/custom/auf den Dolibarr-Server kopieren. Auf dem Produktivsystem übernimmt das die Forgejo-Pipeline (.forgejo/workflows/deploy.yml) — Commit mit[deploy]in der Message synct das Modul automatisch auf den Server. - In Dolibarr: Einrichtung → Module → NetDiag aktivieren.
- Beim Aktivieren werden die Tabellen
llx_netdiag_protocol,llx_netdiag_device,llx_netdiag_measurementangelegt und ein JWT-Schlüssel erzeugt. - Benutzern das Recht NetDiag → Protokolle lesen/schreiben geben.
API-Endpunkte
Alle unter https://<dolibarr>/custom/netdiag/api/:
| Endpunkt | Methode | Zweck |
|---|---|---|
auth.php |
POST {login,password} |
Anmeldung → {token,expiresIn,user} |
customers.php |
GET ?q= / ?id= |
Kundensuche / Kundendetail |
orders.php |
GET ?open=1&q= / ?id= |
Auftragsliste / Auftragsdetail |
protocols.php |
GET ?id= |
Protokoll mit Geräten + Messungen |
protocols.php |
POST {action:"sync",protocol:{…}} |
Protokoll anlegen/aktualisieren (idempotent über clientUuid) |
pdf.php |
GET ?id=&jwt= |
Protokoll-PDF streamen |
Authentifizierung per Authorization: Bearer <token> oder ?jwt=<token>.
Jeder Endpunkt prüft ein Recht — protocols.php im GET-Zweig protocol read
oder write: die Rechte sind in Dolibarr einzeln vergebbar, und ein
Techniker mit Schreib- ohne ausdrückliches Leserecht darf nicht ausgesperrt
werden (das fiele erst beim Kunden auf).
?jwt=in der URL ist nur für den PDF-Download da (der Browser kann dort keinen Header setzen). Langzeit-Token in URLs landen in Zugriffs- und Proxy-Logs — Ablösung steht inROADMAP_UMSETZUNG.md, Phase L5.
Neue Messart aus der App aufnehmen
Die App schickt Messergebnisse als freies JSON. Damit ein Feld beim Kunden
ankommt, sind drei Stellen in lib/netdiag.lib.php zu pflegen:
| Funktion | Zweck | Wenn vergessen |
|---|---|---|
netdiagKundenfelder() |
Whitelist + Beschriftung + Einheit | Feld verschwindet im Kunden-PDF spurlos, übrig bleibt die Ampel |
netdiagToolName() |
Klarname des Werkzeugs | beim Kunden steht „[netzwerk] meintool" |
netdiagKundentext() |
Rohwerte übersetzen/entschärfen | englische API-Werte im deutschen Abnahmedokument |
Spiegelbildlich dazu app/src/lib/messfelder.ts in der App.
Feldnamen immer aus dem erzeugenden Code der App ablesen (types.ts, die
run()-Rümpfe der Werkzeuge), nie aus dem Kopf und nie aus selbst
geschriebenen Testdaten — das ist hier schon zweimal schiefgegangen (KB #1084).
Braucht die Messart eine eigene Tabellendarstellung im PDF, einen Zweig in
lib/netdiag_pdf.lib.php ergänzen (Vorbilder: netdiagPdfStressTest,
netdiagPdfWifiKanal) — sonst wird das Ergebnis zu einer |-getrennten Zeile
zusammengeschoben.
Einrichtung
Einrichtung → Module → NetDiag → Einstellungen:
- Token-Gültigkeit (Sekunden)
- App-Download-URL (APK) — wird als QR-Code angezeigt
Lizenz
GPLv3