ajax/verify_signature.php:
- Liest Metadaten aus .meta.json neben einer Unterschrift-Seite
- Rechnet SHA256 über die zum Signaturzeitpunkt existierenden Seiten
(erste N laut meta.page_count_at_signing)
- Vergleicht mit dem gespeicherten Hash → verified true/false
- Liefert reason bei Fehlschlag (Seitenanzahl oder Inhalt geändert)
bericht_card.php:
- Seiten mit .meta.json kriegen 🔒-Badge + grünen Rand
- 🔍-Button neben dem Löschen-Button öffnet Verifikations-Modal
editor.js:
- showSignatureVerifyResult-Modal zeigt alle Metadaten,
beide Hashes, GPS als OpenStreetMap-Link, IP, User, Zeit
- Grün/Rot je nach Verifikationsergebnis
api/pages.php:
- Neuer Action reorder: POST mit {order:[ids]} schreibt neue
page_order-Werte als Transaktion
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
Unterschrift (api/pages.php?action=signature):
- Metadaten einbrennen: Überschrift, Bericht-Ref, Parent-Ref, Kunde,
Datum/Zeit (Server), Unterzeichner-Name, Bestätigungstext, GPS
- SHA256 Hash-Verkettung über alle vorherigen Seiten + Bericht-Ref
→ nachträgliches Austauschen von Seiten fällt auf
- Composite-Canvas: Header mit Metadaten, Unterschrift mittig,
Footer mit Hash + Server + Zeitstempel
- Metadaten-JSON neben der PNG (für spätere Verifikation)
- signer_name ist Pflicht, gps_lat/gps_lon optional
- Page-Note zeigt Unterzeichner + Zeit statt nur 'Unterschrift Kunde'
Kundenkarten-API (api/customers.php):
- GET ohne id = Liste mit Suche (q-Param), zeigt Stammdaten + Bericht-Count
- GET mit id = Detail: Stammdaten, letzten 50 Aufträge, 50 Rechnungen,
100 Berichte über UNION aus commande/facture JOIN
- Nur echte Kunden (client IN (1,2,3)), keine reinen Lieferanten
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
- api/pages.php:
- DELETE (oder POST ?delete=1) — Seite aus Bericht entfernen
(source_path wird nur gelöscht wenn unter bericht/work/, damit
Anhänge von Auftrag/Rechnung nicht mit rausfliegen)
- POST {note, rotation} — Meta einer Seite updaten
- POST ?action=signature&bericht_id=X + multipart file= — PNG
Unterschrift als neue Seite am Bericht anhängen mit
note='Unterschrift Kunde'
- api/pdf.php — liefert finales PDF oder on-the-fly Preview mit
JWT-Auth (damit PWA das PDF direkt im <iframe> anzeigen kann)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
- Wenn mehrere Berichte zum Auftrag existieren, wird der erste
gefundene ENTWURF (status=0) wiederverwendet
- Finalisierte Berichte werden NICHT mehr mit neuen Seiten überschrieben
- Optional ?bericht_id=X um gezielt in einen bestimmten Bericht hochzuladen
- Wenn alle Berichte final sind, wird automatisch ein neuer Entwurf angelegt
So kann die PWA mehrere Fotos hintereinander in denselben Bericht
packen, statt pro Upload einen neuen anzulegen.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
- reports.php: GET ohne id listet alle Berichte des Users
(Multi-User-Filter über fk_user_creat + Parent fk_user_*),
mit parent_ref, page_count, status
- reports.php action=finalize: generiert jetzt wirklich das PDF
(TCPDF+FPDI + bericht_render_page_to_pdf), schreibt ECM-Eintrag,
setzt Status auf Final
- api/delete_photo.php: JWT-Version von delete_attachment
- api/voice.php: Audio-Upload pro Auftrag (webm/mp4/mp3/ogg)
in das Auftrags-Anhang-Verzeichnis
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
Manche Apache-Setups (Prod!) leiten den Authorization-Header nicht
als HTTP_AUTHORIZATION in $_SERVER weiter. Jetzt wird zusätzlich
REDIRECT_HTTP_AUTHORIZATION und apache_request_headers() geprüft.
Fallback: ?jwt=<token> als Query-Param akzeptieren (wird von der
PWA jetzt standardmäßig mitgesendet für <img>-kompatible URLs).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
_inc.php setzt standardmäßig Content-Type: application/json — das
hat photo.php beim Bildversand blockiert (die Blob kam als JSON rein
und der Browser konnte sie nicht als Bild darstellen).
Jetzt lädt photo.php Dolibarr direkt, dekodiert JWT manuell (mit
Query-Param-Support für Fallback ohne Header-Auth) und sendet NUR
image/jpeg-Header beim Ausliefern.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
Neuer Endpoint liefert Dateien aus DOL_DATA_ROOT aus, geschützt per
JWT statt Dolibarr-Session. Whitelist auf facture/commande/propal/
bericht. Optional size=small/mini für Thumbs (Dolibarr _small Variante).
CORS-Header damit PWA direkt zugreifen kann.
Die PWA kann damit Anhang-Bilder in der Auftrags-Detail-Ansicht
rendern — vorher nutzte sie document.php was nur mit Session ging
und deshalb im Standalone-Mode leer blieb.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
- api/_jwt.php: HS256 JWT encode/decode/from_request, Secret aus
dolibarr_main_instance_unique_id, 7 Tage TTL
- api/_inc.php: gemeinsamer API-Init mit CORS, JSON-Helpers,
api_authenticate() lädt User aus JWT und prüft bericht/read
- api/auth.php: POST { login, password } → JWT mit user + perms
- api/orders.php:
- GET /api/orders.php — Liste der Aufträge des Users (Multi-User
Filter über fk_user_*, Admin sieht alle)
- GET /api/orders.php?id=X — Auftrags-Detail mit Kunde + Berichten
- GET /api/orders.php?id=X&action=photos — Anhänge
- POST /api/orders.php?id=X&action=upload_photo — Foto hochladen,
Bericht wird automatisch angelegt falls nicht vorhanden
- api/reports.php:
- GET /api/reports.php?id=X — Bericht-Detail + Seiten
- POST /api/reports.php?id=X&action=finalize — Status auf final
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
