Eduard Wisch
0f37cae9e5
"0 DHCP-Server (!)" in Rot: In der Produktionsdatenbank stehen drei
ausgelieferte Messungen des entfernten Werkzeugs dhcpcheck mit Ergebnis
{"count":0,"server":[],"hinweis":""} und Status 2. Bei Kabelverbindung gibt
Android die DHCP-Angaben aber grundsaetzlich nicht heraus (nur DhcpInfo, nur
WLAN, deprecated) - gemessen wurde also nichts, "0 gefunden" war der
Rueckgabewert fuer "nicht ermittelbar". netdiagAltlastKorrektur() zeigt diese
Messungen jetzt als "nicht messbar" mit Erklaerung, in PDF und
Technikeransicht. Rohdaten bleiben unangetastet, korrigiert wird nur die
Darstellung - und die wird bei jedem Abruf neu erzeugt. Die Ergebniszahlen
werden dabei unterdrueckt: "Gefundene Geraete: 0" widerspraeche der Aussage
direkt darueber.
"Lease-Dauer: 864000 s s": aeltere App-Fassungen haben die Einheit in den Wert
geschrieben, die Feldtabelle haengt sie erneut an (Prod-Messung #42).
Adress- und Lease-Felder mit dem Wert 0 erscheinen jetzt als "nicht
ermittelbar" statt als "0" - das war nie eine Messung, sondern das
"nichts ermittelt" der alten Android-API.
Neu in der Whitelist: dhcpQuelle (system = LinkProperties ab Android 11 fuer
jeden Anschlusstyp, wlan = alter Weg nur fuer WLAN). Damit ist klaerbar, ob
eine fehlende DHCP-Angabe an der Leitung lag oder an der Android-Version.
Geprueft gegen die lokale Testinstanz mit einer Kopie der echten
Prod-Messungen.
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