dolibarr.netdiag/api
Eduard Wisch 3d12ee1e61 Vier Bestandsfehler im Kundendokument und im Sync behoben
Alle vier durch eine systematische Gegenpruefung des echten Codes gefunden,
nicht durch Symptome — sie waren bereits ausgeliefert und still.

1. Whitelist-Schluessel 'typ' existiert nicht. Die App liefert das
   LinkInfo-Objekt durch, dort heisst das Feld 'type' (app/src/lib/types.ts).
   Folge: im Kundendokument fehlte ausgerechnet beim IP-Test an der Dose die
   Angabe, ob per LAN oder WLAN gemessen wurde - bei einem Abnahmebeleg die
   halbe Aussage. Zusaetzlich 'rssi' aufgenommen: bei einer WLAN-Dose IST der
   Empfangspegel der Messwert, er wurde bisher verworfen.
   Die Rohwerte sind englisch; netdiagKundentext() bildet sie jetzt ab
   ('ethernet' -> 'LAN (Kabel)'), sonst stuende "Anschlussart: ethernet" im
   Abnahmeprotokoll eines deutschen Handwerksbetriebs.

2. Leeres Array druckte "Offene Ports: " ohne Wert. Die Leerpruefung ist ein
   elseif hinter dem Array-Zweig und wurde nie erreicht. Betraf ausgerechnet
   die GUTEN Ergebnisse: Portscan ohne offenen Port, IP-Konflikt ohne
   Konflikt, IP-Scan ohne Veraenderung. Jetzt "keine" - Weglassen waere
   schlechter, weil der Kunde sonst nicht unterscheiden kann, ob nichts
   gefunden oder nichts geprueft wurde.

3. 'error' fehlte in der Whitelist. Der IP-Konflikt gibt im Abbruchfall
   { error: ... } mit roter Ampel zurueck - im Kundendokument stand eine rote
   Ampel ohne einen Buchstaben Erklaerung. Die App vereinheitlicht kuenftig
   auf 'fehler', aber Altdaten lassen sich nicht aendern.

4. tool/category/label wurden beim Sync nicht auf die Spaltenlaenge gekuerzt
   (varchar 64/32/255). Bei striktem SQL-Modus kippt EIN zu langes Label den
   gesamten Sync per rollback() - der Techniker steht beim Kunden mit einem
   Protokoll da, das sich nicht abschliessen laesst, weil eine Beschriftung zu
   lang war. Die App setzt Labels durch Verketten zusammen, 255 Zeichen sind
   erreichbar. found_via wurde 20 Zeilen darueber laengst gekappt.

Ausserdem:
- GET-Zweig der API prueft jetzt eine Berechtigung. Bisher konnte jeder
  angemeldete Benutzer mit einer geratenen ID ein fremdes Protokoll samt
  Geraeteliste, IP-Adressen und offenen Ports abrufen. 'write' wird bewusst
  mit akzeptiert: die Rechte sind in Dolibarr einzeln vergebbar, und ein
  Techniker mit Schreib- ohne ausdruecklichem Leserecht duerfte nicht
  ausgesperrt werden - das waere erst beim Kunden aufgefallen.
- netdiagDauerLesbar: "1 Tage 0 Std" -> "1 Tag". floor() liefert einen Float,
  1.0 === 1 ist in PHP false.

Geprueft: php -l, und netdiagFeldFuerKunde() mit 13 echten Faellen gegen die
lokale Instanz durchgerechnet (LAN/WLAN/Mobilfunk, leere und gefuellte Arrays,
error/fehler, tote Schluessel, Interna).
2026-08-16 19:02:11 +02:00
..
applog.php API-Endpoint applog.php — Debug-Log der mobilen App empfangen [deploy] 2026-05-19 17:39:31 +02:00
auth.php Anmeldung ueber das zentrale Auth-Modul awlauth — v1.1.0 [deploy] 2026-08-14 18:23:29 +02:00
customers.php Initiales Commit — Dolibarr-Modul NetDiag [deploy] 2026-05-19 12:12:11 +02:00
netdiag_api.lib.php Phase 5: Kundendokument lesbar, Gerätemerkmale kommen endlich an 2026-08-15 18:54:01 +02:00
orders.php orders.php: Auftragsliste nach letzter Bearbeitung sortieren [deploy] 2026-05-19 22:05:09 +02:00
pdf.php Initiales Commit — Dolibarr-Modul NetDiag [deploy] 2026-05-19 12:12:11 +02:00
protocols.php Vier Bestandsfehler im Kundendokument und im Sync behoben 2026-08-16 19:02:11 +02:00
update.php API-Endpoint update.php — Updater-Backend-Proxy [deploy] 2026-05-19 20:36:08 +02:00