Eddy: „Bei Fotos aufnehmen auch Videos unterstützen bitte".
- orders.php upload_photo nimmt mp4/m4v/mov/webm, am Inhalt geprüft
(ftyp ohne Bildmarke bzw. EBML), Name video_…; taken_at wird bei
Videos zum Dateidatum. Zu groß für PHP → 413 mit Meldung.
- Aufnahmezeit eines Videos aus dem MP4-Kopf (moov → mvhd), auch wenn
moov hinter den Videodaten steht.
- photo.php liefert Teilbereiche (Range → 206): Videos spielen sofort
und lassen sich spulen.
- config.php meldet upload_max für die Höchstlänge in der App.
- Bericht-Editor: 🎬-Kachel für Videos; in Berichte übernehmen geht
weiterhin nur mit Bild/PDF.
Im Android-Emulator über die App geprüft (Aufnahme, Funkloch, Galerie,
Abspielen, Löschen).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Eddy: „deswegen erkenne ich so wenig — mach im Admin eine Einstellung fuers
Verkleinern und stelle sie auf 100% 1:1. Ich will die volle Handy-Qualitaet der
Kamera, nichts anderes."
- Admin → Bericht → „Fotoqualitaet der Baustellen-App":
BERICHT_PHOTO_MAXSIDE (0 = Originalgroesse, sonst 4000/3000/2000/1600 px)
und BERICHT_PHOTO_QUALITY (nur relevant, wenn verkleinert wird)
- Vorgabe ist 0 = Originalgroesse. Ohne Zutun laedt die App ab jetzt das
unveraenderte Kamerabild. Prod-Limits tragen das (upload_max_filesize 300M,
nachgesehen)
- neuer Endpoint api/config.php liefert die Werte an die PWA, Auth per awl_sso
- Lang-Keys de+en
Nebenbefund, an einem Bestandsfoto gemessen: den bisherigen Fotos fehlt das
EXIF vollstaendig (Quality 85, kein DateTimeOriginal). Das Canvas-Verkleinern
hat es entfernt — deshalb fiel bericht_file_taken_at() immer auf das Dateidatum
zurueck. Mit 1:1 bleibt das Kamera-EXIF erhalten.
Admin-Feld und Endpoint lokal im Browser geprueft: Auswahl steht auf
Originalgroesse, config.php liefert {ok:true, photo_maxside:0, photo_quality:100}.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
