Jeder Teilen-Vorgang endete bisher in einer Sackgasse — Login-Hinweis oder
"Keine geteilten Fotos gefunden", und danach war das Geteilte weg. Zwei Ursachen:
1. share.html prüfte api.getToken() — ein JWT in IndexedDB, das es seit der
SSO-Umstellung nicht mehr gibt (api.login() legt nur noch 'user' ab, die
Sitzung steckt im HttpOnly-Cookie awl_sso). Der Wert war immer leer, also kam
IMMER "Bitte zuerst anmelden"; der Weg "Zur App" verwarf das Geteilte.
Jetzt: Cookie-Prüfung über api/verify.php wie in ensureAuth(), und die
Anmeldung (Passwort + Passkey) läuft IN der Teilen-Seite — das Geteilte bleibt
dabei gesichert und der Ablauf geht danach direkt weiter.
2. Der Service Worker sicherte nur Dateien. Titel, Text und Link aus dem
share_target wurden weggeworfen, ein reiner Text-Share schrieb gar nichts.
Jetzt wird das ganze Paket gesichert und immer weitergeleitet (absolute
Redirect-URL, leere File-Platzhalter fliegen raus).
Die Teilen-Seite zeigt Bildvorschau, Betreff und Text zum Nachbessern und eine
Auftragssuche (ohne Suchbegriff die offenen Aufträge, mit Suchbegriff alle).
Beim Ablegen gehen die Bilder über die normale Upload-Queue (Persist-First),
der Text wird als notiz_*.txt über api/note.php gespeichert. Scheitert die
Notiz (kein Netz), bleibt der Text gesichert und der Vorgang ist wiederholbar.
Dazu ein Banner in der App, wenn noch ein Paket unabgelegt bereitliegt —
abgebrochene Vorgänge findet sonst niemand wieder. share.html liest auch den
alten IndexedDB-Schlüssel, damit der erste Share nach dem Deploy (noch alter
Service Worker) nicht verlorengeht.
Lokal durchgespielt: Bild+Text, nur Text, und abgemeldet teilen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Textnotizen: neuer Punkt "Notizen (n)" am Auftrag, direkt unter der Sprachnotiz.
Liste mit Betreff, Vorschau und Zeitstempel; antippen oeffnet die Notiz zum Lesen und
Aendern, loeschen mit Rueckfrage. Gespeichert wird ueber api/note.php als
notiz_<betreff>_<datum>.txt im Auftragsordner - derselbe Weg wie bei der Sprachnotiz,
damit die Notiz auch im Dolibarr-Auftrag und in der Anhaenge-Spalte des Bericht-Editors
auftaucht. In "Weitere Dokumente" sind Notizen ausgefiltert, sie haetten dort doppelt
gestanden.
Fotokacheln laden jetzt serverseitige Thumbnails (photo.php?size=thumb) statt der
Originale: rund 10 KB statt mehrerer hundert KB je Kachel. Das <img> haengt direkt an
der URL statt an einer Blob-URL - damit greifen HTTP-Cache und loading="lazy"
tatsaechlich und der Browser laedt parallel. Vorher lief eine sequenzielle Schleife, die
jedes Foto komplett holte, bevor das naechste anfing, und im Fehlerfall ein zweites Mal.
Bericht-Seiten zeigen composite_path, wenn vorhanden - also das im Editor gebaute
Seitenbild mit Anmerkungen statt der Rohdatei. Raster-Layouts bekommen ein Kennzeichen
("4"); Seiten ohne Bildquelle zeigen keine Fehlerkachel mehr.
confirm/alert/prompt sind an allen zehn Stellen durch eigene Modale ersetzt
(confirmDialog/alertDialog/inputDialog). Browser-Dialoge zeigen in der installierten PWA
die Herkunfts-URL und wirken wie ein Systemfehler. Der Hardware-Zurueck-Button schliesst
sie als Abbruch.
Service Worker: eigener Cache baustelle-media (cache-first, LRU 300) fuer Thumbnails.
Vorher war ohne Netz kein einziges schon angesehenes Foto verfuegbar. Der Cache ueberlebt
Deploys bewusst und wird beim Abmelden geleert (CLEAR_MEDIA), damit keine Kundenfotos auf
dem Geraet zurueckbleiben.
Nebenbei behoben:
- .modal-header, .close-btn und .modal-body hatten ueberhaupt kein CSS, obwohl das Markup
sie nutzt (u. a. beim Loeschen eines Berichts) - der Schliessen-Knopf sass unter der
Ueberschrift statt daneben.
- Das Laden eines Thumbnails ueberschrieb den ganzen Kachel-Inhalt und nahm die Overlays
mit: Auswahl-Haekchen und Seitennummer verschwanden, sobald das Bild da war.
- manifest.webmanifest: share_target.action war eine absolute URL auf den Prod-Host und
lag damit ausserhalb des Scopes - der Browser verwarf das share_target komplett. Jetzt
relativ ("share.html"), funktioniert lokal und auf Prod.
ROADMAP.md neu angelegt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Backend (Bericht 1.4.0) validiert den Auftrag jetzt ohne Position - die
Leistungen kommen aus dem Stundenzettel. Am PWA-Code selbst aendert sich
nichts, das Antwortfeld added_line wurde hier nie ausgewertet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PWA:
- Checkbox in /orders Route hinzugefügt
- Filter in localStorage persistiert
- CSS für .filter-toggle
Doku:
- README.md komplett aktualisiert mit allen Features
- API-Dokumentation erweitert
[deploy]
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Mobile Progressive Web App für Baustellen-Doku, spricht die REST-API
des Dolibarr-Bericht-Moduls.
MVP-Features:
- Vanilla JavaScript, kein Build-Step nötig
- Login mit Dolibarr-Credentials → JWT (7 Tage)
- Auftragsliste mit Suche und Multi-User-Filter
- Auftragsdetail mit Kunde, Adresse, Click-to-Call
- Foto-Aufnahme via Kamera oder Galerie (multiple)
- Clientseitige Bildverkleinerung (max 2000px, JPEG q=0.85)
- Offline-Queue in IndexedDB für Uploads ohne Netz
- Auto-Sync bei Online-Event mit Status-Badge
- Service Worker für App-Shell-Cache
- PWA-installierbar (Manifest, Icons, Theme-Color)
Hosting: awl.data-it-solution.de/baustelle/ via Apache-Alias
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
