- Token-Tabelle: fk_bericht → fk_element + element_type (generisch)
- Migration: bestehende Tokens auf neue Spalten migrieren
- upload_photo API: Foto direkt nach commande/{ref}/, kein Bericht/BerichtPage mehr
- mobile_upload.php: Upload-Ziel über Token-Methode getUploadDir() ermitteln
- Token-Erstellung: element_id + element_type statt berichtid (abwärtskompatibel)
- QR-Modal: Token für Auftrag statt für Bericht; Polling auf Anhänge-Änderung [deploy]
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Neue Klasse BerichtPdf / BerichtPdfFpdi (Trait-basiert):
* Header: links Bericht-Titel (Bold) + Firmenname, rechts Firmen-Logo (max 40x18mm),
Trennlinie. Top-Margin jetzt 30mm für den Header-Bereich.
* Footer: zentriert "Seite X / Y" mit TCPDF-Aliases.
* berichtInit(): kompiliert Hack-TTFs nach DOL_DATA_ROOT/bericht/tcpdf_fonts/
(beschreibbar) und bindet sie per AddFont an die PDF-Instance.
Vorher schlug addTTFfont still fehl weil K_PATH_FONTS read-only war —
deshalb kam weder Titel noch Notiz in Hack.
- bericht_ensure_hack_font($pdf) zieht den Font-Key jetzt aus der Instance
(BerichtPdfTrait), sonst Fallback helvetica.
- bericht_write_note_html() wrapped das CKEditor-HTML in
<span style="font-family:hack...;"> damit writeHTMLCell den Hack-Font
tatsächlich verwendet.
- Composite-Branch: $mT=30 / $mB=16 damit Bilder nicht unter dem Header
sitzen.
- ajax/generate_pdf, ajax/preview_pdf, api/pdf, api/reports, bericht_batch:
alle nutzen jetzt BerichtPdf(Fpdi), setzen SetMargins(10,30,10),
setPrintHeader(true) und berichtInit() mit Titel, mysoc->name und Logo.
- Neue Tabelle llx_bericht_material (element_type, fk_element, label,
qty, unit, note, fk_user_creat, datec) via Migration
- api/materials.php: GET list, POST anlegen, DELETE löschen
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
Desktop-Editor Polish:
- Aktives Seiten-Thumbnail deutlich markiert (scale + shadow + blauer
Label-Hintergrund)
- Titel-Feld pro Seite in der DB (llx_bericht_page.title)
Phase 5.2 Vorher/Nachher-Layout:
- Neuer layout-Typ 'before_after' in bericht_render_page_to_pdf
- Zwei Bilder nebeneinander, Labels 'Vorher' / 'Nachher', Titel oben
- 'VN'-Button in der Anhänge-Grid-Leiste
- create_grid_page akzeptiert before_after
- Layout-Dropdown hat before_after + title_only Option
Phase 5.2b Title-Only Seiten:
- Reine Titel/Zwischentitel-Seiten ohne Bild
- 32pt Titel zentriert, optional Notiz darunter
- bericht_render_page_to_pdf behandelt title_only separat
Phase 5.3 Bericht-Versionierung:
- Neue Spalten version + fk_bericht_parent in llx_bericht
- Bericht::duplicateAsNewVersion() kopiert alles inkl. Seiten
- '🔀 Neue Version'-Button im Editor-Footer
- Versions-Links in der Meta-Zeile (v1, v2, v3 …) mit Sprungmöglichkeit
- Alte Versionen bleiben unverändert erhalten
Phase 5.6 Batch-Modus:
- Neue Seite bericht_batch.php mit Filter (Datum von/bis, Suche)
- Checkbox-Liste aller finalisierten Berichte
- 'Ausgewählte als Sammel-PDF herunterladen' → FPDI merged alle
final_pdf_path in ein neues PDF mit Inhaltsverzeichnis-Seite
- Link im Admin-Setup
api/pages.php:
- POST-Update akzeptiert jetzt auch title und layout zusätzlich zu
note und rotation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
Bericht-Vorlagen (Phase 5.5):
- DB: is_template, template_label in llx_bericht
- Bericht::fetchAllTemplates() und createFromTemplate()
- fetchAllForElement() blendet Vorlagen aus
- ajax/save_as_template.php erzeugt Vorlage aus aktuellem Bericht
- Desktop-Editor: '📋 Als Vorlage' Button im Action-Bereich
- Bericht-Übersicht: Vorlagen-Dropdown beim + Neu Button
- api/templates.php: GET list + POST create_from_template
Schnell-Bericht (Phase 4.a/4.i):
- api/reports.php?action=create POST-Endpoint: Titel, Format,
Orientation, ODT-Template, optional template_id
- api/odt_templates.php: Liste der Deckblatt-Vorlagen
Whisper-Transkription (Phase 5.7):
- api/transcribe.php: POST mit relpath, nutzt externen Whisper-
HTTP-Endpoint (whisper.cpp server ODER OpenAI-kompatibel)
- Konfiguration im Admin: BERICHT_WHISPER_URL/MODE/API_KEY/LANG
- Sprache default 'de'
Cron-Fix:
- BerichtUploadToken::cleanupExpired() ist jetzt Instanz-Methode
(Dolibarr ruft new Klasse($db) bei jobtype=method auf)
- Returnwert für Cron-Success/Failure
- Statische Variante als cleanupExpiredStatic() für direkte Aufrufe
- Damit läuft der tägliche Cron 'Expired Upload-Tokens bereinigen'
nicht mehr hängend
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[deploy]
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]
