100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Paul Nothaft	c4d89c9d64	chore(main): release 3.131.3-beta.0 (#1373)	2026-09-10 11:54:50 +00:00
Paul NothaftandPaul Nothaft	a2bf1f644c	fix(video): try metadata extraction and thumbnail generation independently (#1371) ... * fix(video): try metadata extraction and thumbnail generation independently processUploadedVideo() gated everything behind isValidVideo(), which rejects the whole video if ffprobe can't read even one of duration/width/height -- common on some iPhone/Lightroom-exported MP4s (issue 1370). Callers (photoProcessor.js's processPhoto and processUploadedPhotos) already catch that throw and fall back to a static placeholder thumbnail plus a metadata-only retry (codex review of #845), but that fallback never got a REAL thumbnail even when generateVideoThumbnail() would have succeeded on its own -- thumbnailing doesn't need valid duration/width/height, it just seeks and grabs a frame. processUploadedVideo now tries metadata extraction and thumbnail generation independently, keeping whichever succeeds instead of discarding both on a single failed field. The callers' existing throw handling stays as a backstop. Also: extractVideoMetadata stored duration as 0 (not null) whenever ffprobe had no duration field, masking "unknown" as a fake real zero-second clip and defeating downstream `duration != null` checks meant to skip an untrustworthy value. Relates to issue 1370 * fix(video): fall back to the SVG placeholder when thumbnail generation fails processUploadedVideo could return success with thumbnailKey: null when only thumbnail generation failed. The gallery grid (GridGalleryLayout/JustifiedGalleryLayout) falls back to `photo.thumbnail_url || photo.url` when there's no thumbnail, so AuthenticatedImage downloaded the full original video and tried to render it as an <img> -- a broken tile and a potentially huge fetch just from opening the gallery. Falls back to the same ffmpeg-free SVG placeholder the callers already generate for a total processing failure, so a bare thumbnail-generation failure degrades to that placeholder too, never to "no thumbnail at all". Found by codex review. * fix(video): avoid a SQLite connection deadlock in the placeholder fallback generateVideoPlaceholder() unconditionally called getThumbnailSettings(), which queries the database directly (not through any active transaction). videoProcessor.js's new placeholder fallback can run from inside processUploadedPhotos' open per-file SQLite transaction (chunked video upload) -- knex's default SQLite pool has exactly one connection, so that second, un-transacted query deadlocks against the transaction holding it, timing out after acquireConnectionTimeout (60s). Reproduced directly against an isolated SQLite db. generateVideoPlaceholder now skips the settings lookup entirely when the caller supplies explicit width/height, and the video fallback passes the same DEFAULT_THUMBNAIL_WIDTH/HEIGHT the settings lookup would have fallen back to anyway (now exported for reuse). Found by codex review. * fix(video): throw when neither a real thumbnail nor the placeholder can be produced processUploadedVideo returned success with thumbnailKey: null when both the real thumbnail AND the SVG placeholder failed -- a total, systemic failure (storage backend down, disk full), not a quirk of one file. On stable, which doesn't have the #845 call-site fallback, this silently completed the video with no thumbnail at all instead of the retryable 'failed' status a throw here produces. On main, the pre-existing #845 fallback already absorbed this exact case (no behavior change there) -- verified against codex's own git-blame check of the pre-PR stable code before applying this. Now throws in that case, restoring the pre-existing "let the caller mark it failed and retryable" behavior for a genuinely unrecoverable video, while keeping every partial-failure case (the vast majority) resolving with whatever succeeded. Found by codex review. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-10 13:48:48 +02:00
Paul Nothaft	443ec91de9	chore(main): release 3.131.2-beta.0 (#1368)	2026-09-09 20:35:16 +00:00
Paul NothaftandPaul Nothaft	15cd5ede82	fix(backup): honor the configured database-backup destination path (#1366) ... * fix(backup): stop ignoring the configured database-backup destination path databaseBackupService.getBackupConfig() returns the raw database_backup_*-prefixed setting keys, but backup() and startScheduledBackups() destructured unprefixed names off that object (destinationPath, compress, enabled, schedule, retentionDays, emailOnSuccess/Failure). None of those keys ever existed on the config object, so every read silently fell through to its hardcoded default. The visible symptom (reported in issue 1365): the inline database dump that runs before every file backup (default ON) always tried to create /backup/database, regardless of what an admin configured, and died with EACCES on the read-only default path — before the file backup's own (correctly wired) backup_destination_path was ever reached. The standalone scheduled database-backup runner had the same bug: config.enabled was always undefined, so it silently never started regardless of database_backup_enabled. Also fixes saveManifestToLocal's manifest-directory fallback, which hardcoded /backup instead of matching the sane getStoragePath()/backups default used everywhere else for a missing backup_destination_path. Relates to issue 1365 * fix(backup): reject a database-backup destination inside a public static mount Making database_backup_destination_path actually take effect reopens a GHSA-jw8m-43r2-jqrm-class exfiltration path: that setting is writable via PUT /api/admin/database-backup/config under backup.create alone (the built-in admin role has it without settings.edit or backup.restore), with no path validation. Before this fix the setting was silently ignored (the destructuring bug), so pointing it at the public uploads/logos or fonts mount was harmless; now that it is honored, it needed the same defense GHSA-jw8m already applies to the per-request override. Rejects the setting at both the config write (immediate 400) and, defensively, at backup() time before mkdir. Found by codex review. * fix(backup): close two gaps codex round 2 found in the destination guard - The public-roots list missed the bundled fallback fonts dir (backend/assets/fonts, also mounted at /fonts, and nodejs-owned per the Dockerfile's COPY --chown so it's writable at runtime). - The comparison was case-sensitive; on a case-insensitive-but- preserving filesystem (APFS, NTFS, Docker Desktop bind mounts of either) STORAGE_PATH/UPLOADS/Logos names the same directory as uploads/logos on disk. Now compares lowercased. - database_backup_retention_days reached cleanupOldBackups unvalidated. A value <= 0 pushes the cutoff to today or the future, deleting every completed backup on the next scheduled run -- a backup.create holder achieving what backup.delete gates on the manual /cleanup route. Rejected at config-write time (400) and defensively inside cleanupOldBackups itself. - The scheduled-backup cron callback closed over retention_days from schedule-start time; a retention-only /config update (which doesn't restart the schedule) ran stale until restart. Re-reads it on every tick instead. Found by codex review, round 2. * fix(backup): resolve symlinks and add the all-in-one frontend dir to the destination guard Codex round 3 found two more bypasses of the public-root guard, both specific to the all-in-one image (Dockerfile.aio): - /app/frontend/dist (FRONTEND_DIR) ships nodejs-owned and is served unauthenticated as the built SPA -- missing from the protected-roots list. - /app/storage is a symlink to /data/storage (the actual STORAGE_PATH). A destination given as /app/storage/uploads/logos passed the guard's lexical path.resolve() comparison while resolving, on disk, to the exact same directory as the protected STORAGE_PATH/uploads/logos. isUnderPubliclyServableRoot now resolves symlinks in whatever prefix of each path already exists (resolveRealish) before comparing, rather than relying on path.resolve() alone. Also restores three fs.mkdir spies in the test file that were never un-spied, which silently leaked a rejected mock into any later test doing a real fs.mkdir -- exactly what the new symlink test needed to set up its fixture. Found by codex review, round 3. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-09 22:27:18 +02:00
Paul Nothaft	6d717544ec	chore(main): release 3.131.1-beta.0 (#1364)	2026-09-08 20:08:38 +00:00
Paul NothaftandPaul Nothaft	9f4b9bab46	fix(usage): explain and de-emphasize the pending-packet button lock (#1363) ... * fix(usage): explain and de-emphasize the pending-packet button lock An admin whose report delivery is stuck (old schema, network issue, etc.) saw the v5-upgrade and portal buttons greyed out with no indication why, or what to do about it — the backend's single-packet- in-flight guard is correct, but silent. Add an inline note pointing at "Retry / send if due" when a pending packet is the actual cause. Also: "Review expanded usage.v5 scope" didn't read as an upgrade action — renamed to "Upgrade to usage.v5" / "Auf usage.v5 upgraden". "Open usage portal" is now a primary (green) button in both its signed-in and pre-participation forms, matching the visual weight of the other primary actions on this tab instead of blending in as a secondary outline button. * fix(usage): scope the pending-packet note to controls it actually gates The note added in the previous commit rendered whenever pending_action was truthy, regardless of participation status. Outside `active` (activation_pending, deletion_pending) the portal renders as a plain un-gated link and no v5-upgrade section exists at all, so the note named two controls that either weren't blocked or weren't on screen. And when active but already on the current schema, it wrongly implied a v5-upgrade button existed. Gate on `active` (nothing is actually blocked outside it), and choose between the existing two-control message and a new portal-only one based on whether consent_update_available — which the v5-upgrade section itself is gated on — is true. Four new regression tests cover each shape: activation_pending, deletion_pending, active+current-schema (portal-only), and active+outdated-schema (both, the original case). Found by code review. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-08 22:00:35 +02:00
Paul Nothaft	de3ae1f176	chore(main): release 3.131.0-beta.0 (#1362)	2026-09-08 17:32:31 +00:00
Paul Nothaft	59ef2ee9af	Merge pull request #1361 from PicPeak/feat/usage-reporting-update-prompt ... feat(usage): prompt existing admins once for usage reporting after an update	2026-09-08 19:23:54 +02:00
Paul Nothaft	539f5db2b5	Merge pull request #1360 from PicPeak/feat/setup-usage-reporting-optin ... feat(setup): add product usage consent to the first-run wizard	2026-09-08 19:23:06 +02:00
Paul Nothaft	411d459338	Merge pull request #1359 from PicPeak/fix/qa-shutdown-and-revocation ... fix: complete graceful shutdown and revoke tokens without expiry	2026-09-08 19:22:50 +02:00
Paul Nothaft	fb2f8333dc	fix(usage): classify prompt acknowledgement in privacy coverage	2026-09-08 17:31:32 +02:00
Paul Nothaft	77b4aab61a	fix(usage): synchronize setup consent and dismissal state	2026-09-08 17:26:47 +02:00
Paul Nothaft	a5f7b38e02	fix(setup): refresh usage state after accepting consent	2026-09-08 17:25:20 +02:00
Paul Nothaft	9a437ee9e1	fix(usage): preserve consent choices and make the prompt accessible	2026-09-08 17:22:47 +02:00
Paul Nothaft	81b10f4e31	Merge setup consent fixes from PR 1360 ... # Conflicts: # frontend/src/pages/SetupPage.tsx	2026-09-08 17:15:56 +02:00
Paul Nothaft	9168bdd504	fix(setup): require the full usage reporting disclosure	2026-09-08 17:14:37 +02:00
Paul Nothaft	662516a5ad	fix: retain revocations for tokens without expiry	2026-09-08 15:54:01 +02:00
Paul Nothaft	a31a2e25e2	fix: interrupt idle worker waits during shutdown	2026-09-08 15:54:01 +02:00
Paul Nothaft	20a291eb34	chore(main): release 3.130.2-beta.0 (#1358)	2026-09-08 13:40:19 +00:00
Paul Nothaft	f0e6d2dfb1	fix: enforce gallery access and consolidate gallery workflows (#1357) ... Harden gallery authentication and authorization, consolidate gallery workflows, and prevent token-bearing URLs from leaking through nginx request error logs.	2026-09-08 15:34:09 +02:00
Paul Nothaft	895e5ab3cc	chore(main): release 3.130.1-beta.0 (#1354)	2026-09-08 06:53:51 +00:00
Paul NothaftandPaul Nothaft	acb25a9a1c	fix(images): probe and clean up preview tiers under the extension the encoder actually wrote (#1355) ... generatePreviewImage rewrites the output extension to match the encoding it chose, .jpg or .webp for alpha and multi-frame sources. The tier lookup in ensurePreviewImageAtWidth and the cleanup list in previewTierKeys kept the SOURCE extension instead, so for anything but a lowercase .jpg source the stat never matched: every tier request for a .png, .JPG, .jpeg, .heic or RAW photo re-ran Sharp, and cleanup never found the files it left behind, which accumulated for the life of the install. Both now derive every key the tier can live under: the .jpg and .webp candidates, plus the source-extension key last so tiers written before the rewrite are still found by lookup and by cleanup. Follow-up to issue 1020, where the mismatch was identified during review. Co-authored-by: Paul Nothaft <[email protected]>	2026-09-08 08:41:53 +02:00
Paul NothaftandPaul Nothaft	c97341e454	fix(images): single-flight lazy rendition generation and keep the old rendition during replacement (#1350) ... * fix(images): single-flight lazy rendition generation and keep the old rendition during replacement The lazy generators in imageProcessor are check-then-generate, and the check reads the path off the photo row the route already fetched. N concurrent cold requests for one photo all held a snapshot with the path still null, all missed, and all ran the same sharp pipeline. Only the thumbnail tier path had a guard; the canonical thumbnail it falls back to, heroes, previews and preview tiers had none. One process-local map now covers every rendition, keyed by photo id and rendition (`thumbnail:<id>`, `thumbnail:<id>:w<width>`, `hero:<id>`, `preview:<id>`, `preview:<id>:w<width>`). Concurrent callers share one promise; the entry is cleared in a finally on success and failure alike so a rejection cannot poison the key. The tier stat moved inside the flight so a request arriving as the previous flight clears finds the written tier instead of missing on a stale probe. Heroes and previews also deleted the existing object before generating its replacement, and again in the catch. Both are gone, mirroring what the thumbnail generator already does: put is the last statement in the try and replaces atomically on local storage and by key on S3, so the delete only ever opened a window with no rendition at all, and a source that failed to read stripped the old rendition with the row still pointing at it. No re-read of the photo row inside the flight: the admin regenerate endpoints force a rebuild by passing a row with the path nulled, and a re-read would hand back the persisted rendition untouched. Fixes the single-flight half of issue 1020. The preview cache-key extension mismatch and any server-wide work queue remain separate. * fix(images): keep the snapshot validity check outside the single-flight With the check inside the flight, an admin regeneration (row passed with the path nulled) could join a viewer's flight for the same photo that was merely confirming an already-good rendition, and be handed back the very file it was asked to replace while the endpoint counted a success. Only a miss enters the flight now; inside it everything is a regeneration. * fix(images): forced rebuilds run after an in-flight lazy generation instead of adopting it The admin regenerate endpoints could still join a lazy flight that was already generating for the same photo. That flight read the thumbnail settings when it started, so after a settings change it produces exactly the rendition the regenerate was invoked to replace; adopting it counted a success while the old size stayed cached. ensureThumbnail and ensurePreviewImage take `{ force: true }`: skip the snapshot check and, if a flight is pending, start after it settles. Lazy misses arriving meanwhile join the forced flight, and an older flight settling late no longer evicts the newer entry from the map. * fix(images): key rendition flights by source as well as photo id replacePhoto keeps the photo id and changes path and filename. Keyed by id and width alone, a request carrying the replacement row joined a flight still rendering the file it replaced and was handed the old image, which the gallery caches for 30 minutes. The tier map this replaced was keyed by storage key and so already told the two apart. * test(thumbnails): wait for the regenerate loop's completion line instead of a fixed 150 ms The loop runs in setImmediate after the response. Under a loaded machine (fifteen suites in parallel, each booting a migrated SQLite) it took longer than 150 ms once and the assertions ran against a half-finished mock call list. Poll the logger spy for the "regeneration complete" line with a 10 s deadline; the suite also finishes sooner because the wait ends as soon as the loop does. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-08 08:33:04 +02:00
Paul NothaftandPaul Nothaft	0e459b3293	docs: define security support across stable and main (#1351) ... Co-authored-by: Paul Nothaft <[email protected]>	2026-09-08 08:32:54 +02:00
Paul NothaftandPaul Nothaft	f83cbe9109	docs: refresh repository support and community links (#1349) ... Co-authored-by: Paul Nothaft <[email protected]>	2026-09-08 08:32:50 +02:00
Paul Nothaft	d36585379f	assets: add vectorized logo mark as SVG (traced from picpeak-kamera-transparent.png) (#1348)	2026-09-07 22:47:50 +02:00
Paul Nothaft	7e9a61c245	chore(main): release 3.130.0-beta.0 (#1347)	2026-09-07 20:36:18 +00:00
Paul NothaftandPaul Nothaft	810801a9ab	fix(events): drop non-canonical keys from the event update before any check runs (#1346) ... PUT /admin/events/:id spreads the body into the UPDATE. SQLite resolves quoted identifiers case-insensitively, so `{ "Event_Name": ... }` lands on event_name there — while every check in the handler (validators, the field-level permission guards, the deny-set) keys on the exact lowercase name. The deny-set already case-folded for its own columns; every other column was reachable through a spelling variant. Every events column and every input-only key the handler accepts is lowercase snake_case, so a key with any uppercase in it is not something a legitimate client sends. Such keys are now removed before anything looks at the body. Postgres was unaffected (quoted identifiers are case-sensitive there; a variant produced a 500 instead). Surfaced by the Codex review of the folder-watcher change, where a photos.upload guard on external_watch could be walked around this way. Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 22:30:13 +02:00
Paul NothaftandPaul Nothaft	8cc7d7d14a	feat(external-media): watch reference folders and import new files automatically (#1345) ... * feat(external-media): watch reference folders and import new files automatically Managed uploads dropped into storage/events/active are picked up by the chokidar watcher; external media had no equivalent, so a NAS folder that keeps growing needed an admin to open the event and press Import every time. Relates to issue 1187. - The import pass moves out of the route into services/externalImportService.js. The watcher and the Import button now run the identical function; the route only validates and maps errors to status codes. - Mutual exclusion is the per-event claim from maintenanceJobState (`external_import:<id>`, seeded on demand by the new ensure()) instead of the in-process Set. The Set stopped a double-click in one process; the claim also stops the watcher on a second replica, or an admin clicking while the watcher is mid-run elsewhere. The run heartbeats so a claim from a dead process is taken over. - services/externalMediaWatcher.js: per-event opt-in via the new events.external_watch column (migration 208), chokidar with awaitWriteFinish so a copy in flight is not imported half-written, debounced full pass per change, a timer sweep every 15 minutes as the fallback for NFS/SMB mounts that deliver no inotify events, optional stat-polling via EXTERNAL_MEDIA_WATCH_POLLING. The set of watched events is re-read every minute, so the toggle works from any replica. A watcher that just started runs one pass immediately. - Deletions are ignored on purpose: a file vanishing from a NAS is at least as likely to be a reorganisation or a dropped mount as an intentional removal, and acting on it would delete a guest-visible photo. Rows whose file is gone stay, as they do today. - Not gated on STORAGE_BACKEND: EXTERNAL_MEDIA_ROOT is always local. - Quiet system passes stay out of the activity log; runs that imported something are logged with actor external-media-watcher. - Frontend: "Watch folder for new files" checkbox under the external folder picker, status line in view mode, EN/DE strings. * fix(external-media): close the review gaps in the folder watcher Codex review of the watcher, round 1. All six findings were real: - Enabling the watcher, or pointing an enabled one at another folder, now requires photos.upload — the permission the manual Import already requires. events.edit alone was a way around it. Only the transition is checked, so a role without photos.upload can still edit an already-watched event. The checkbox is disabled for such roles. - Automatic passes defer files that are still changing: anything modified inside the stability window, or whose size moves across one wait of that window, is left for the next pass. chokidar's awaitWriteFinish only settles the file that fired the event, and the sweep sees no events at all, so a sibling still being copied could be inserted half-written and then skipped forever. - Photos an admin deleted are not brought back by the sweep. The delete routes record the file in external_import_exclusions (migration 209); automatic passes skip the list, the manual Import ignores it and clears it for what it imports. - The six EXTERNAL_MEDIA_WATCH* variables are forwarded in all three compose files; they were documented but the backend services use explicit environment lists, so the kill switch did nothing. - A pass re-checks is_active / is_archived at run time, not only in the minutely reconcile. - The lease is renewed on a timer for the whole run, walk included, and ownership is checked before the event row is touched. * fix(external-media): make automatic passes follow the row, not rewrite it Codex review round 2, four findings, all applied: - The event update route drops non-canonical spellings of external_watch and external_path before the permission guard. SQLite resolves column names case-insensitively, so `External_Watch` reached the column while the guard only looked at the lowercase key. - Exclusions are checked per file at insert time, not against a snapshot taken before the settle wait. A photo deleted during the wait was present in the snapshot and got re-inserted by the loop. - An automatic pass no longer writes source_mode / external_path. It re-reads the row after the walk and the settle wait and stops if the folder changed or the event went managed; the manual Import is the only writer. The options are now `automatic` + `settleMs`. - A pass that deferred files re-arms the debounced import, so a file copied just before the watcher started is not stranded when the sweep is disabled. * fix(external-media): keep exclusions for replaced photos, stop a pass whose event stopped qualifying Codex review round 3, both findings applied: - recordExclusions keys on external_relpath alone. A replaced external photo becomes managed but keeps its relpath on purpose, and deleting that replacement must not republish the NAS original. - An automatic pass checks the full watcher predicate (reference mode, same folder, watch on, active, not archived) before it inserts and on every heartbeat tick during the loop, and stops as soon as the event no longer qualifies. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 22:29:55 +02:00
Paul Nothaft	1b3f721d10	chore(main): release 3.129.0-beta.0 (#1344)	2026-09-07 18:47:26 +00:00
Paul NothaftandPaul Nothaft	d6a0c4aff5	feat(cms): keep the editor toolbar in reach on long pages (#1335) ... On the CMS page the editor has no bounded height, so a long document scrolls the whole admin content area and the toolbar scrolled away with it. Editing a 16-section privacy policy meant scrolling back to the top for every heading or list. The top toolbar block (mode/save row and formatting row) is now `sticky top-0` from the md breakpoint up, pinned to the admin page's scroller. The rounded wrapper clips with `overflow-clip` instead of `overflow-hidden`, because hidden turns the wrapper into a scroll container and the toolbar would pin to that instead of to the page. Not below md: there the formatting row wraps to several lines and a permanently stuck block would eat most of a phone's editing area. Two things follow from pinning. The link-entry row moves inside the sticky block: rendered below it, the URL field sat at the toolbar's original document position, under the pinned toolbar. And ProseMirror's selection scrolling gets a top threshold and margin sized from the block's rendered height (ResizeObserver, re-applied through editor.setOptions), because the formatting row wraps to two rows at common desktop widths and the link row comes and goes; a constant would leave the caret behind the toolbar half the time. Below md the offsets are zero again. Verified in Chromium against the CMS page with an 18-section document: scrolled to the last sections, the toolbar stays at the top of the content area; on main it is gone. A source-level test pins the sticky block, the wrapper's clip, the link row's placement and the measured offsets, since jsdom does not lay out. Relates to issue 1289 Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 20:41:29 +02:00
Paul NothaftandPaul Nothaft	fb9da72f14	feat(security): opt-in recoverable gallery passwords (#1341) ... * feat(security): opt-in recoverable gallery passwords Gallery passwords are bcrypt hashes, so an admin who needs to hand a password to a client a second time has to reset it, which invalidates what the client already has. This adds a security setting, security_gallery_password_recoverable, off by default, that keeps an AES-256-GCM encrypted copy of each gallery password and client PIN next to the hash. The key is derived from GALLERY_PASSWORD_ENCRYPTION_KEY or JWT_SECRET. While the setting is on: - create, publish, send-later, edit, reset and the v1 API write the copy alongside the hash; turning a gallery's password requirement off clears it - GET /api/admin/events/:id/password returns the copy to admins with events.edit and ownership, and writes a gallery_password_viewed activity entry on every real reveal - resend-email uses the stored password instead of the "set at creation" sentinel, so the client receives what already works Switching the setting off purges every stored copy. Login and hash verification are untouched; the copy is never read on the gallery side. The Security tab carries the toggle with a warning that stays visible, and the event page shows "Show password" with copy buttons only while the setting is on and the gallery has a secret. Relates to issue 1271 * fix(security): close the write-versus-switch-off race in the password vault The recoverable setting is read while an event insert is assembled and the client-PIN hash awaits after that, so a settings request that switched the feature off and purged in that gap was overtaken by the insert. Every write site now re-reads the setting right after its statement and clears its own row when the setting is off; the settings writer flips the value before it purges, so either the purge or the re-check catches the row. * fix(security): resend carries the stored client PIN and link; deterministic tamper test The creation mail includes the client-access link and PIN; a resend only sent the gallery password even when a stored PIN was available. The ciphertext tamper assertion replaced the last two characters with a constant, which was a no-op roughly once in 4096 runs. * fix(security): drop the revealed password after Send gallery email The send-later route can replace the password; the share card keys its revealed copy on the event query's refetch time, so invalidate the event after the send like the other password-changing mutations do. * fix(security): purge leftovers before the setting write when turning recovery on Switching on wrote the setting first and purged after, so a password write that read the new "on" in between stored a copy the purge then deleted. Turning on now purges before the write; turning off keeps purging after it, which together with the write-site re-check leaves the vault holding exactly what was written while the setting was on. * chore(security): drop the duplicate rateLimitService import left by the rebase * chore(usage): register the password recovery routes in the v5 coverage inventory The inventory moved from v4 to v5 on main; the entry added by this branch followed it. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 20:36:48 +02:00
Paul Nothaft	16b79ee119	chore(main): release 3.128.0-beta.0 (#1343)	2026-09-07 18:10:48 +00:00
Paul NothaftandPaul Nothaft	5c1e38d921	feat(usage): distinguish real edits and template delivery with v5 consent (#1339) ... * feat(usage): distinguish real edits and template delivery with v5 consent * fix(usage): exclude queued test messages and count reorders as edits - queueEmail carries usageEligible: false into email_data and the queue processor passes it on, so the dev tools' send-test-email no longer records email_template_delivery once the worker sends it. - event-types/reorder and categories/reorder-global compare the persisted order before and after and record the v5 edit markers only when it changed, matching the display_order edit already counted on PUT. - normalized() builds arrays with Array.from so a row array from the sqlite binding compares equal under Jest's separate realm. * fix(usage): cover per-gallery category order and workflow test runs - categories/reorder records category_editing when an event's override changes; reorder/:eventId records it when an override was actually removed. - send_email and the collections handoff pass usageEligible: false for a workflow test run (engine.testRun sets __test), so a non-dry test send is not counted as template delivery. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 20:03:15 +02:00
Paul NothaftandPaul Nothaft	69754f8a2c	fix(email): scrub gallery passwords from the sent-mail archive (#1340) ... * fix(email): scrub gallery passwords from the sent-mail archive The email queue kept every gallery password and client PIN in clear text in email_data and rendered_html after the mail was sent, and the Messages reading pane handed them back to any admin with the messaging flag. A password hash in the events table bought nothing while the plaintext sat next to it. Once a mail is out, or its retries are exhausted, the processor now masks secret-looking variables (password, passcode, pin) in email_data and replaces their values in the rendered body, plain and HTML-escaped. The reading pane applies the same masking to rows archived before this change. Pending rows keep the real values so a retry still sends them. Relates to issue 1271 * fix(email): keep a quoted ">" from cutting an attribute value out of redaction The tag splitter stopped at the first ">", so a template attribute such as title="{{gallery_password}} > details" left the password unmasked in the archived HTML while email_data was already masked. The tokenizer is now quote-aware; a tag with an unbalanced quote falls through as text and is scrubbed there. * fix(email): scrub secrets inside HTML comments in the archived body A comment such as <!-- PIN: {{client_password}} --> was split off as a tag and its body, which has no attribute, was never scrubbed. Comments are now one segment and their content is masked whole. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 20:02:57 +02:00
Paul NothaftandPaul Nothaft	8017370271	feat(settings): expose the API rate limiter in the Security tab (#1338) ... * feat(settings): expose the API rate limiter in the Security tab The general per-IP limiter had six settings in app_settings and a backend route to write them, and no screen. Installs ran on the code fallback — 300 requests per 15 minutes per IP — with no way to see it, which is how issue 1287 played out: a 546-photo gallery exhausted the budget for one viewer and the operator learned about the setting from a grep of the backend log. Security tab: a card with the six settings, the validation ranges the route enforces, a one-line explanation per field, and a note that the unit is the client IP — an office or household behind one NAT shares a budget, and behind a proxy TRUST_PROXY has to cover the proxy or every visitor shares its address. The tab's Save button saves the limiter through its own route. The limiter values are checked against the route's ranges before anything is written and the limiter is written first, so a rejected value cannot leave the password/session settings half-saved behind a failure toast. Backend, three things the screen needed: - The settings read fills the six keys with the code defaults when they have no row, so the form shows the budget in force rather than an empty field; the defaults live in one exported constant the limiter itself reads. - The write route upserts instead of updating: on a fresh install, which has no rows, the old UPDATE matched nothing and the route answered 200 while changing nothing. - The live limiter instances move into rateLimitService and the write route rebuilds them. express-rate-limit fixes windowMs when an instance is built — max and skip re-read the settings per request, the window does not — so a saved window used to apply only after a restart. The gates in server.js resolve the instance per request through the service's getters. A rebuild starts fresh counters, which on a settings change is acceptable. The limiters get explicit MemoryStores and a rebuild shuts the superseded ones down, because a store keeps a cleanup interval alive for as long as it exists and dropping the reference alone would leak one timer per save. Tests: the read surfaces defaults and honours the key filter; the write creates rows on a fresh database, the limiter sees the values immediately and hands the gates a fresh instance; existing rows are updated not duplicated; out-of-range values are rejected. The tab renders the values, edits through the hook state, carries the ranges, saves with the tab's button, and the pre-write validation accepts the bounds and rejects outside them and cleared fields. Relates to issue 1337 * docs(security): point the rate limiter doc at the Security tab and the upsert --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 20:02:40 +02:00
Paul Nothaft	834111fc66	chore(main): release 3.127.2-beta.0 (#1342)	2026-09-07 14:40:56 +00:00
Paul NothaftandPaul Nothaft	9bbdca9fc5	docs(security): correct the rate limiter defaults and how they are set (#1336) ... * docs(security): correct the rate limiter defaults and how they are set SECURITY_LOGGING.md said rate_limit_max_requests defaults to 1000 and that the settings are configurable via the admin panel. The code fallback when no app_settings row exists is 300 (19e125d8), a fresh install has no row, and there is no admin screen: the settings are written by PUT /api/admin/settings/security/rate-limit, which nothing in the frontend calls. The reporter of issue 1287 ran on the 300 default without any way to see it. The table now carries the real defaults, what the auth budget counts, the exemptions including the gallery-image one from v3.127.0-beta.0, and the TRUST_PROXY and shared-NAT caveats. Relates to issue 1287 * docs(security): note the rate-limit route only updates existing rows --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-07 16:35:13 +02:00
Paul Nothaft	e43216311b	chore(main): release 3.127.1-beta.0 (#1334)	2026-09-07 07:48:14 +00:00
Paul Nothaft	79eb6d72eb	Merge pull request #1333 from PicPeak/fix/consent-dialog-webkit-flex-basis ... fix(usage): stop WebKit collapsing the consent dialog to its header and footer	2026-09-07 09:42:00 +02:00
Paul Nothaft	1f09ac2d0d	chore(main): release 3.127.0-beta.0 (#1331)	2026-09-07 07:29:24 +00:00
Paul Nothaft	fde0558811	Merge pull request #1328 from PicPeak/fix/1325-premium-canvas ... fix(gallery): honor canvas settings in the Premium lightbox	2026-09-07 09:20:11 +02:00
Paul Nothaft	0986f7f7ac	Merge pull request #1322 from PicPeak/fix/canvas-lightbox-only ... fix(gallery): keep canvas rendering in the lightbox, render tiles as <img>	2026-09-07 09:19:58 +02:00
Paul Nothaft	a02fa08f69	Merge pull request #1329 from PicPeak/feat/usage-portal-signin-and-copy ... feat(usage): open the portal signed in, and rewrite the German copy	2026-09-07 09:19:46 +02:00
Paul Nothaft	a16ff855dd	Merge pull request #1321 from PicPeak/fix/1317-usage-portal-copy ... feat(usage): plain link to the public usage portal, German opt-in copy	2026-09-07 09:19:32 +02:00
Paul Nothaft	f63347d79a	Merge pull request #1330 from PicPeak/chore/usage-catalog-english-only ... chore(usage): make the capability catalog English-only	2026-09-07 09:19:09 +02:00
Paul Nothaft	5b8c13feb6	Merge pull request #1320 from PicPeak/fix/1316-umami-trackview ... fix(analytics): send Umami page views through track(), not the removed trackView()	2026-09-07 09:18:57 +02:00
Paul Nothaft	ac24319135	Merge pull request #1324 from PicPeak/fix/1287-gallery-images-rate-limit ... fix(security): stop a gallery viewer's own image fetches spending the anonymous budget	2026-09-07 09:18:46 +02:00
Paul Nothaft	7c968e74bb	Merge pull request #1326 from PicPeak/fix/sanitize-html-2.17.7-main ... fix(security): bump sanitize-html to 2.17.7	2026-09-07 09:18:27 +02:00
Paul Nothaft	83b74e2256	chore(main): release 3.126.3-beta.0 (#1323)	2026-09-06 19:45:17 +00:00
Paul Nothaft	5306fe378c	Merge pull request #1318 from PicPeak/fix/1308-gallery-downloads-signal ... fix(usage): introduce consented v4 download restriction reporting	2026-09-06 21:40:32 +02:00
Paul Nothaft	6459bff50e	chore(main): release 3.126.2-beta.0 (#1319)	2026-09-06 19:13:42 +00:00
Paul Nothaft	c4b03a831f	Merge pull request #1315 from PicPeak/fix/1287-retry-failed-tiles ... fix(gallery): retry a failed image fetch once the tile is back on screen	2026-09-06 21:07:22 +02:00
Paul Nothaft	b3937d0b8c	Merge pull request #1312 from PicPeak/fix/1287-release-offscreen-tiles ... fix(gallery): release grid tiles once they are far enough out of view	2026-09-06 21:07:19 +02:00
Paul Nothaft	25c3e3d7b8	chore(main): release 3.126.1-beta.0 (#1314)	2026-09-06 17:59:34 +00:00
Paul Nothaft	b801f3a6b8	Merge pull request #1313 from PicPeak/codex/usage-report-compatibility ... fix(usage): preserve compatibility with old and partial reports	2026-09-06 19:54:33 +02:00
Paul Nothaft	63ab731cee	chore(main): release 3.126.0-beta.0 (#1311)	2026-09-06 17:43:14 +00:00
Paul Nothaft	b0bb65d0d2	Merge pull request #1310 from PicPeak/codex/usage-v3-features ... feat(usage): add beta capabilities and gallery/photo totals with explicit consent	2026-09-06 19:33:47 +02:00
Paul Nothaft	d3622de81a	chore(main): release 3.125.0-beta.0 (#1309)	2026-09-06 17:27:47 +00:00
Paul Nothaft	35b42bba9d	Merge pull request #1304 from PicPeak/codex/1110-product-usage ... feat: add opt-in product usage and feedback (#1110)	2026-09-06 19:22:07 +02:00
Paul Nothaft	a5ff926409	chore(main): release 3.124.1-beta.0 (#1307)	2026-09-05 21:55:53 +00:00
Paul Nothaft	5dda14f727	Merge pull request #1306 from PicPeak/fix/strand-fragmentation-defaults ... fix: remove the fragmentation handling stranded by #1303	2026-09-05 23:49:33 +02:00
Paul Nothaft	b4c2c40550	chore(main): release 3.124.0-beta.0 (#1305)	2026-09-05 21:45:17 +00:00
Paul Nothaft	ae23b1adea	Merge pull request #1303 from PicPeak/fix/1300-remove-fragmentation ... fix: remove the image-fragmentation surface	2026-09-05 23:37:14 +02:00
Paul Nothaft	0536c86ec9	Merge pull request #1302 from PicPeak/feat/newsletter-large-send-warning ... feat(newsletters): warn about deliverability before a large send	2026-09-05 23:37:00 +02:00
Paul Nothaft	2e9bd540c9	Merge pull request #1298 from PicPeak/fix/1296-dead-canvas-setting ... fix(security): apply the Image-security defaults instead of storing them (#1296)	2026-09-05 23:36:53 +02:00
Paul Nothaft	905fc595e3	Merge pull request #1295 from PicPeak/fix/post-merge-followups ... fix(gallery): image-loading follow-ups — pre-load band, decode release, sanitizer dedup	2026-09-05 23:36:45 +02:00
Paul Nothaft	1f316ef91c	Merge pull request #1299 from PicPeak/fix/1297-inert-protection-props ... fix(gallery): remove the inert image-protection prop surface from AuthenticatedImage	2026-09-05 23:36:27 +02:00
Paul Nothaft	c71ffae912	chore(main): release 3.123.0-beta.0 (#1294)	2026-09-04 12:40:45 +00:00
Paul Nothaft	fc595409b4	feat(crm): newsletter campaigns behind a newsletters flag (#1264) ... Part B of #1264. Flag off by default, so an install that never enables it gains no route, no nav entry and no way to mass-mail. A campaign is a body plus a recipient rule. Queueing one writes ordinary email_queue rows (email_type 'newsletter', origin 'campaign', new campaign_id), so retry, rendered_html, sent_at and error_message all come from the existing processor rather than a parallel sender. Throttling staggers scheduled_at; the processor loop is untouched. Two rules the service enforces: no raw HTML is ever stored (sanitized on write and again on render, idempotently), and opt-out is checked at queue time AND again at send time. Migration 199 adds email_campaigns, email_campaign_recipients, email_queue.campaign_id, customer_accounts.marketing_opt_out(_at), and the newsletters.view / newsletters.send permissions. Three rounds of external review are folded in, including several that would otherwise have shipped broken: - Campaign rows never came due on SQLite. queueEmail writes a Date, which the sqlite3 binding stores as epoch ms; ISO text in the same column compares as TEXT against an INTEGER, and SQLite orders every INTEGER below every TEXT. The feature silently sent nothing there. - The flag had no Settings card and no sidebar entry, so it could not be enabled through the UI at all. - Consent is per ADDRESS, not per row: two accounts sharing an inbox meant unsubscribing stopped one and not the other, at both queue and send time. - The unsubscribe GET mutated consent, so a mail-security scanner walking a campaign could have unsubscribed much of the list. GET now confirms, POST acts. - The rate ceiling is clamped to the queue's real throughput (10/min), so the composer's estimate stops being wrong by up to 12x. Closes #1264	2026-09-04 14:32:31 +02:00
Paul Nothaft	a7d0972b13	fix(security): make the CSS sanitizer's remote-URL block actually block ... sanitizeCSS "blocked" a remote url() by prefixing it with a /* BLOCKED URL */ COMMENT and leaving the URL in place. CSS comments are discarded during tokenization, so the declaration a browser parsed still carried the live URL — while adminCssTemplates returned sanitization_warnings claiming it had been stopped. Protection that reports success is worse than none, which is why it survived review. Scope is narrow: sanitizeCss (lowercase, the public-site path) never included the pattern and permits remote URLs by design — a test now pins that. Only sanitizeCSS (uppercase) was affected; outside this repo's newsletter branch its sole caller is adminCssTemplates.js. Migration 200 is required, not cosmetic: gallery.js serves css_templates.css_content VERBATIM as text/css and does not re-sanitize on read, so fixing the write path alone would leave every existing template serving its URL forever. Review follow-ups replaced the regex with a small three-state lexer (comment / string / identifier) over the RAW text, after five further bypasses: a ")" inside a quoted url(), CSS escapes (u\72l), the HTML comment strip JOINING tokens into a live url() after the scan, an escaped quote desynchronising the scan, and a quote inside a comment. Escapes are decoded only to decide, never to rewrite — a clean input now round-trips byte-identical, which also keeps unaffected rows out of the migration's write path. Severity is low (writing a template needs branding.edit) but the harm is a gallery visitor's IP reaching a third party from a page the operator believes carries no remote requests.	2026-09-04 14:27:08 +02:00
Paul Nothaft	de3a7f70bf	fix(cms): enable the Tailwind typography plugin so prose classes work (#1288) ... tailwind.config.js had plugins: [] and @tailwindcss/typography was never installed, so every prose / prose-neutral / dark:prose-invert class in the app resolved to nothing. Preflight, which IS active, resets h1-h6 to inherit size and weight and strips list-style from ul/ol — so an applied <h2> rendered pixel-identical to the <p> it replaced. The editor was never broken. The toolbar highlighted because editor.isActive('heading') correctly returned true; only the CSS to show it was missing. That also explains why pasting rendered rich text worked: it carries inline styles. Ten surfaces rely on these classes, including the PUBLIC CMS pages — so impressum/datenschutz were serving unstyled headings to visitors too. Review follow-ups: prose colours are mapped to the theme tokens wherever .text-theme marks theme-owned text (a dark gallery preset sets --color-text but no .dark class, so dark:prose-invert never engages and headings would have gone near-black on dark); code blocks inherit rather than being scaled twice; and H5/H6 get explicit rules, since the plugin only styles h1-h4. Closes #1288	2026-09-04 14:26:51 +02:00
Paul Nothaft	4afe7a6f08	fix(gallery): bound concurrent image fetches and abort them on unmount (#1287) ... Hardening for the large-gallery stall. The reporter could not isolate the cause and neither could I from static reading; these are two defects that are wrong independently of whether they are the whole story. Gallery grids are NOT virtualized: a 546-photo event puts 546 PhotoCards in the DOM, each mounting its own bare fetch. Two problems there: no cap, and a cleanup that only set a flag while the request kept running. withImageFetchSlot now holds requests to six in flight, with the BODY read inside the slot — fetch resolves on headers, so releasing there would have bounded header round-trips and nothing else. Teardown aborts via AbortController. A request queued indefinitely is PENDING, not failed, which is why the failure left no console error, no failed request and nothing in the backend log. Review follow-ups: three tiers (current lightbox slide > neighbour prefetch > grid thumbnails), because a single FIFO put the image the user just clicked behind hundreds of thumbnails; and a synchronous throw now releases its slot instead of permanently draining the pool. If it recurs, capture performance.getEntriesByType('resource') for the stalled thumbnails — a queued request shows responseStart === 0. Relates to #1287	2026-09-04 14:26:48 +02:00
Paul Nothaft	8f98f6bdec	fix(gallery): show a guest their own likes when feedback sharing is off (#1286) ... show_feedback_to_guests means "don't show guests OTHER PEOPLE's feedback". The per-viewer is_liked flag was gated on it anyway, so turning sharing off emptied every heart the guest had set themselves, on every page load, while the photo_feedback rows sat there intact. The query behind the flag is filtered to the viewer (by guest_id, or by their own IP+UA identifier), so what it returns was never aggregate data. The colour-label block twelve lines below already documents this exact reasoning and is correctly ungated. Scope is just that flag — the counts beside it stay gated, with a test pinning that the fix does not leak them back. The #1150 contract still holds: an admin-hidden like does not read as liked. Note for the reporter: the FILTER path was already correct (includeGuestMatches is ungated, /my-feedback carries no gate). The empty Likes chip was downstream of the same falsified flag, not a second bug. Closes #1286	2026-09-04 14:26:27 +02:00
Paul Nothaft	b6e40b9a2a	feat(email): global signature footer from the business profile (#1264) ... The business profile already carried the operator's full issuer block — address, phone, email, website, VAT id — but none of it reached an email. Those columns only fed the quote/invoice PDF renderer, so every outgoing mail footer was the fixed logo + company name + copyright line. The signature is rendered by wrapEmailHtml and nowhere else, so no template, no per-type send path and no queue row needed a change. Two new columns on business_profile (migration 198) carry the toggle and one free-text legal line; everything else is read from the address fields the operator already maintains. Default off, with a test pinning that the disabled path is byte-identical to a no-profile install. Includes three rounds of external review fixes: the plain-text MIME part also carries the signature; string booleans ('false'/'0') no longer invert the toggle; the status line stays silent rather than asserting "off" while unauthorised or loading; and the preview's Text tab mirrors the send path's htmlToText fallback. Manual Messages replies deliberately keep no signature — they bypass the wrapper by design — and the UI copy names that exception. Closes #1264 (Part A)	2026-09-04 14:24:02 +02:00
Paul Nothaft	90da797e3f	chore(main): release 3.122.7-beta.0 (#1282)	2026-09-03 10:47:21 +00:00
Paul Nothaft	ea394b5ee5	Merge pull request #1280 from PicPeak/fix/security-scan-batch-1 ... fix(security): batch 1 — zxcvbn DoS, revocation forgery, unlink traversals, stored Content-Type, edge middleware	2026-09-03 12:36:32 +02:00
Paul Nothaft	dc5bccba05	chore(main): release 3.122.6-beta.0 (#1279)	2026-09-03 06:50:57 +00:00
Paul Nothaft	a87e688484	Merge pull request #1277 from PicPeak/fix/1275-hybrid-pointer-input-mode ... fix(gallery): follow the input in use, not the device's primary pointer (#1275)	2026-09-03 08:45:28 +02:00
Paul Nothaft	30fa320dc2	chore(main): release 3.122.5-beta.0 (#1276)	2026-09-02 14:53:06 +00:00
Paul Nothaft	b9c29fcf9b	Merge pull request #1274 from PicPeak/fix/1261-crm-invitation-visibility ... fix(crm): tell the admin whether a customer's invitation actually went out (#1261)	2026-09-02 16:47:05 +02:00
Paul Nothaft	ec1df704b4	Merge pull request #1273 from PicPeak/fix/1262-email-queue-visibility ... fix(email): show a queue nobody is working instead of reporting all-clear (#1262)	2026-09-02 16:46:28 +02:00
Paul Nothaft	db197e7685	Merge pull request #1272 from PicPeak/fix/1263-mobile-photo-tap-collisions ... fix(gallery): stop invisible overlay controls swallowing mobile taps (#1263)	2026-09-02 16:46:00 +02:00
Paul Nothaft	ca8050899b	chore(main): release 3.122.4-beta.0 (#1270)	2026-09-02 08:56:21 +00:00
Paul Nothaft	f722bdaf4b	Merge pull request #1268 from PicPeak/fix/1265-guest-identity-persistence ... fix(guests): keep guest identity across a tab close (#1265)	2026-09-02 10:49:15 +02:00
Paul Nothaft	63fa05b181	chore(main): release 3.122.3-beta.0 (#1269)	2026-09-02 08:27:26 +00:00
Paul Nothaft	cad699a5be	Merge pull request #1267 from PicPeak/fix/testplan-followups ... fix: close the remaining 2026-09-01 QA items, warnings and follow-on defects	2026-09-02 10:22:08 +02:00
Paul Nothaft	9b63399c48	Merge pull request #1266 from PicPeak/fix/testplan-2026-09-01 ... fix: resolve the 2026-09-01 QA run findings (#1-#21) and repo-health debt	2026-09-02 10:18:39 +02:00
Paul NothaftandPaul Nothaft	afaa00f428	chore: remove issue screenshots from the source tree (#1259) ... Two PR screenshots landed at the repo root in #1241 and have been shipping as part of the source tree since. Nothing references them. Screenshots belong on a `screenshots/*` branch — that is what those branches are for, and how every other UI change here has attached its evidence. Added ignore rules so the next one cannot follow the same path, anchored with a leading slash so docs/ keeps its own five images and test-assets/ keeps the fixtures the e2e specs load. Verified no other tracked file matches the new patterns. Co-authored-by: Paul Nothaft <[email protected]>	2026-09-01 09:34:40 +02:00
Paul Nothaft	884580d849	chore(main): release 3.122.2-beta.0 (#1258)	2026-09-01 07:30:45 +00:00
3 people	66989d70f1	fix(upload): let Android guests reach the camera without breaking video (#1244) ... * fix(upload): let Android guests reach the camera without breaking video Recent Android versions route an <input> whose accept list is entirely image/video types to the system photo picker, which has no camera entry — so a guest standing at the event can only pick an existing photo, not take one. Including a type that picker can't handle forces the general chooser, which does offer the camera. Two corrections to the original approach in #1117: - the .pdf is gated on the Android UA. It was appended unconditionally, so desktop and iOS pickers — which behave correctly — gained a selectable PDF that only produces an error when chosen. - no image-only guard. #1117 rejected every non-image file before the existing allowlist check, which breaks video uploads outright on any install configured for them (fileTypes.ts maps mp4/m4v/webm/mov/avi and general_allowed_file_types is admin-editable). The guard was also redundant: extensionsToMimeTypes only emits types it has a mapping for, so application/pdf can never be in allowedMimeTypes and the existing "Invalid file type" check already rejects a picked PDF. The empty-string fallback to 'image/*, .pdf' goes too — extensionsToMimeTypes already falls back to the configured default set, and image/* was broader than the admin's allowlist. Lives in fileTypes.ts as a pure function so the UA behaviour is testable; the component keeps a one-line useMemo. Co-authored-by: Zszywany <[email protected]> * fix(upload): use android/allowCamera instead of .pdf for the chooser fallback Same mechanism, better token. Chrome on Android 14/15 sends an input whose accept list is all media types to the photo picker, which has no camera tile; adding a value that picker cannot satisfy makes it fall back to the general chooser, which does offer the camera. `.pdf` achieves that but advertises PDFs as selectable — pick one and the existing allowlist check answers "Invalid file type", which is a dead end we put in front of the guest ourselves. `android/allowCamera` is the token the workaround converged on: not a real MIME type, matches no file, so it flips the picker without offering anything. Neither token ever widened what is accepted — addFiles validates against extensionsToMimeTypes, which only emits types it has a mapping for — but not showing the guest a choice that cannot work is worth the one-line change. Verified in a browser rather than asserted: the real component rendered under an Android UA emits image/jpeg,image/png,image/webp,android/allowCamera and under a desktop UA image/jpeg,image/png,image/webp with the visible modal identical in both, and the format hint still reading "JPG, JPEG, PNG, WEBP" — the token does not leak into anything a guest sees. * fix(upload): keep the camera token off Firefox for Android External review round. The gate was a bare /Android/i, which Firefox for Android matches — so it received a token invented to reroute Chromium's photo picker, a picker it does not use. The doc comment two lines up already said Firefox behaves correctly; the code did not agree with it. Inert at best, and at worst it perturbs a chooser that was working. Narrowed to Android minus Firefox, which is the Chromium-family set the behaviour was actually observed on (Chrome and Edge, Android 14/15), with a UA test to pin it. --------- Co-authored-by: Paul Nothaft <[email protected]> Co-authored-by: Zszywany <[email protected]>	2026-09-01 09:24:24 +02:00
Paul Nothaft	7e6bfbecb2	chore(main): release 3.122.1-beta.0 (#1254)	2026-09-01 06:35:22 +00:00
Paul NothaftandPaul Nothaft	6938bad107	fix(events): apply the gallery password policy to publish and send-later (#1253) ... Both routes re-hash password_hash from a plaintext the admin re-types, and both validated it with nothing but express-validator's isLength({min:6}). So the configured complexity — moderate by default, meaning 8 chars plus upper, lower and a digit — governed creation and reset while these two doors accepted 'aaaaaa' and made it the live gallery password. Fixed for both at once, deliberately. Fixing only the newer send-later route would have made a quiet-publish password valid at publish time and rejected by send-later, leaving the admin unable to mail a gallery that is already live under exactly that password. Not an escalation — it needs admin auth plus events.edit, and such an admin could already set the same weak password through /publish. It is a policy gap: the UI promised a complexity level these two endpoints did not enforce. BEHAVIOUR CHANGE: an API-only consumer publishing with a sub-policy password now gets 400 with the same body shape event creation returns (error, details, score, feedback) instead of silently weakening the gallery. Two existing test fixtures had to change for the same reason — their intent was that the supplied password is carried and persisted, not that a weak one is accepted. Co-authored-by: Paul Nothaft <[email protected]>	2026-09-01 08:30:17 +02:00
Paul NothaftandPaul Nothaft	a35d2bad66	fix(archives): restore categories for original-filename archives on main too (#1252) ... main's #1240 landed the manifest lookup in its first form; the hardening that followed only ever reached stable, via #1243. So main still silently loses every category when restoring an archive written while general_use_original_filenames_for_downloads was on: archiveService names each ZIP entry after the ORIGINAL filename while the manifest stays keyed by the internal photos.filename, so the lookup misses every entry. Ported as one unit rather than piecemeal, since a third variant of this function helps nobody: - index by original_filename, and by sanitizeForZipEntry(original_filename) as the ZIP would actually have written it - two passes, canonical names claimed before any alias, so the result no longer depends on manifest iteration order (the archive query has no ORDER BY) - a name two rows both claim is dropped rather than guessed — including the canonical/alias clash, where which file the ZIP emitted depends on a naming mode the manifest does not record - globals count as existing, event-scoped rows win over them, and the global arm requires event_id IS NULL so one event's legacy row can't be adopted by another event's restore - an invented category is explicitly is_global false; the column defaults to TRUE, so a restore was leaking this event's naming into every gallery - categories resolve inside the !existingPhoto branch, so a restore that skips its inserts stops creating unused rows from stale manifest names - a duplicate category name is logged and resolved by lowest id instead of engine order main-only code is untouched: the face-data cleanup (#1074, #1132) and the uploaded_at toISOString fix both survive — stable still has the bare new Date() there, which is the documented Jest/SQLite landmine and worth a separate look. 15 tests, ported from #1243. Co-authored-by: Paul Nothaft <[email protected]>	2026-09-01 08:30:02 +02:00
Paul Nothaft	63f3fb4629	chore(main): release 3.122.0-beta.0 (#1251)	2026-09-01 06:27:11 +00:00
Paul NothaftandPaul Nothaft	1ef2b3c85b	feat(events): publish without notifying, and send the gallery email later (#1235) (#1241) ... * feat(events): publish without notifying, and send the gallery email later (#1235) Publishing queued the gallery_created email whenever any customer email existed, with no opt-out. A photographer working with a client who has no address yet — the Instagram-team case in discussion #1086 — had to type their OWN address into the required field, publish, receive the client-facing email themselves, and hand the link over by DM. Turning off `event_require_customer_email` is not the answer either: that is global, and the same photographer usually does collect addresses. Two halves, because a checkbox alone is only half a workflow: - `notify_customer` on publish, default TRUE. Absent means notify, so the v1 API, an older frontend and any script keep behaving exactly as before. When false the gallery goes live and nothing is queued — not the gallery_created email, not the assigned-customer-account notice, not WhatsApp. Publishing still logs activity and still fires the event.published webhook, because those describe a state change rather than a message to a customer. - POST /:id/send-gallery-email for an already-published gallery. Deliberately not restricted to galleries published quietly: re-sending is a normal thing to want (spam folder, wrong address since corrected) and refusing would push people to unpublish and republish, changing gallery state to work around a mail problem. Refused for a draft, whose link would not work yet, and for an event with no recipient. The email composition is now one helper shared by both, so an email sent a week later is identical to one sent at publish. UI: a checkbox in the publish dialog (checked by default, hidden when nobody would be notified anyway), and a "Send gallery email" action on published galleries that have a recipient. The password field follows the checkbox — unchecking it means nothing is being sent, so there is no plaintext to carry and no reason to demand it. EN + DE strings. 7 integration tests. Two fail without the change, verified by forcing notifyCustomer true and re-running; the rest pin the default, the draft and no-recipient refusals, and that a gallery with no recipient still publishes. * fix(events): make the publish dialog description follow the checkbox (#1235) Caught by screenshotting it. With "Send the gallery email now" unchecked, the paragraph above still read "...and sends the notification email to [email protected]" while the control directly beneath it said nothing would be sent — the dialog contradicted itself at exactly the moment the admin is deciding whether anything goes out. It now reads "No email will be sent — you can send it later from this page." when the box is clear. EN + DE. * fix(events): close six gaps in publish-quietly found by external review (#1235) TWO CORRECTIONS TO MY OWN VERIFICATION FIRST. `npx tsc --noEmit` in frontend/ is a NO-OP — the root tsconfig is solution-style with references and no include, so it checks nothing. Every "tsc clean" I claimed on this branch came from that. The real check, `tsc -p tsconfig.app.json`, showed two TS2339s I had introduced: `event.host_email` does not exist on the frontend Event type, which the admin API normalises away. Both recipient checks now use `customer_email`. PASSWORD ON SEND-LATER. The action promised to send the link and password but always called the endpoint without one, so a protected gallery got the "(set at creation)" sentinel — unusable — and this is most needed right after a quiet publish, the path that never collects a password. New SendGalleryEmailDialog asks for it, same shape and reasoning as the publish dialog (#627). Galleries with no password skip the field. WHATSAPP-ONLY GALLERIES COULD NOT PUBLISH QUIETLY. willNotify ignored customer_phone, so a phone-only gallery hid the opt-out AND told the admin nothing would be sent — while publish queued the WhatsApp anyway. Phone now counts, with its own description line. ASSIGNED-ACCOUNT NOTICES COULD NOT BE SENT LATER. The dialog promised it; the endpoint rejected anything without an inline recipient. It now falls through to the same customer-account path publish uses. EDITORS COULD NOT SEE THE ACTION. The send button was nested inside the events.archive gate, so the default editor role — events.edit, no archive — never saw a button for an endpoint it is allowed to call. Separate gates now. DEAD LINKS. The endpoint only checked is_draft, so an archived, inactive or expired gallery would send a link the gallery middleware rejects. All three are refused with a reason. 9 backend tests (2 new), 22 across the event suites. eslint clean on every changed frontend file; crud.js keeps its 2 pre-existing errors. * fix(events): persist the send-later password, and fix a long-standing isGalleryPublic misuse (#1235) Round 2 of external review. THE EMAIL COULD CARRY A PASSWORD THE GALLERY REJECTS. The send-later dialog invites "or pick a new one", but the route queued that plaintext without touching password_hash — so the customer got credentials that do not open the gallery. Worse than the sentinel it replaced, because it looks usable. The route now hashes and persists first, exactly as publish does. isGalleryPublic TAKES A VALUE, NOT AN EVENT — and this is pre-existing. normalizeRequirePassword returns its default for anything that is not a boolean/number/string, so isGalleryPublic(event) is ALWAYS false and `requirePassword` was always true. The publish dialog on main has demanded a password for public galleries for exactly this reason. Both call sites now pass event.require_password. Fixing the older one alongside mine rather than leaving a broken copy one line above a fixed one. ASSIGNED-ACCOUNT GALLERIES HAD NO BUTTON. The route falls through to the customer-account notice when there is no inline email, and the publish dialog promises that notice can be sent later — but the button only appeared with a customer_email, making the promise unkeepable. WHATSAPP CLAIM SOFTENED. Publish only queues WhatsApp when the config exists and is enabled, which the dialog cannot see. It now says the customer is notified there "if WhatsApp is configured" rather than asserting a send. 10 backend tests (1 new, covering the rehash). eslint clean on every changed frontend file; crud.js keeps its 2 pre-existing errors. * fix(events): don't reset the password for an account-only notice, hide unusable actions (#1235) Round 3 of external review. The first is a harm my own round-2 fix introduced. PASSWORD RESET FOR NOTHING. Round 2 persisted the supplied password before knowing which mail would go out. For a protected gallery with no inline email but assigned accounts, the dialog still demands a password, the hash was rewritten, and then the fallback sent customer_gallery_assigned — which links to the customer portal and never mentions a password. Net effect: the live gallery password silently changed and everyone holding the old one was locked out, in exchange for nothing. It is now persisted only when the mail that carries it is actually being sent. BUTTONS THE BACKEND WOULD REFUSE. The send action rendered for expired and inactive galleries, and counted assigned accounts the endpoint filters out as inactive — walking the admin through a dialog to reach a generic error toast. The card now mirrors the endpoint's eligibility rules, and only active accounts count toward having a recipient. 11 backend tests (1 new, pinning that the hash is untouched on the account path), 24 across the event suites. tsc and eslint clean on the changed files. * fix(events): make the send-later action agree with what the endpoint will do Three findings from an external review round, all the same shape: the UI predicted the endpoint's behaviour and got it wrong. GET /admin/events/:id mapped customer_accounts without is_active, so the "only ACTIVE accounts count" filter in OverviewTab compared undefined and excluded nothing. A gallery whose only assignments were deactivated showed the send action, and the endpoint then filtered every recipient and returned 400. is_active is exposed now, and the count applies the same predicate the fallback uses — active AND holding an address. is_active is coerced through toBoolean rather than compared with === false. On the default SQLite backend it comes back as 0, and 0 === false is false, so an inactive gallery kept offering a send that parseBooleanInput then rejected. Same class as #1028. The password prompt is gated on there being an inline recipient. With no customer_email the backend takes the account fallback, which sends customer_gallery_assigned — a portal link that never mentions a password — and deliberately skips the rehash. Asking for one there blocked the send behind a six-character value nothing consumes, and the dialog's promise that it would be rehashed was false. Frontend suite: 291 passed. tsc and eslint clean. * fix(events): don't mail a portal link to a customer who cannot sign in Round-2 finding from the external review. A passive customer — created directly and never invited — is an active account with a real address whose password_hash IS NULL. The account fallback happily mailed it customer_gallery_assigned, which links to /customer/dashboard, and customerAuth rejects login without a hash: the link goes to a door that will not open. Worse than failing, the route counted it and reported success, so the admin believed the customer had been told. getAssignmentsForEvent now derives can_sign_in (the predicate, never the hash) and the three call sites share one canReceiveGalleryNotice helper — publish, send-later, and the payload the UI predicts from all have to agree or the button appears and then 400s. The UI mirrors it. Sending passive customers an invitation instead of skipping them is the better product answer, and a separate feature. Refusing visibly beats a silent non-delivery in the meantime. Test asserts the refusal; it fails without the can_sign_in arm. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-01 08:18:00 +02:00
Paul Nothaft	bdeb5a2151	chore(main): release 3.121.4-beta.0 (#1249)	2026-09-01 06:10:24 +00:00
Paul Nothaft	c7ce79afb1	chore(main): release 3.121.3-beta.0 (#1242)	2026-08-30 15:07:47 +00:00
Paul NothaftandPaul Nothaft	44a8c416c7	refactor(email): stop reading the webhook response body at all (#1225) (#1239) ... The transport carried 41 lines of bounded-read-with-deadline to recover a messageId a receiver MIGHT return. That value is only ever logged — nothing persists it, there is no email_queue.message_id column — and the code to get it produced two of the last four review findings: the size cap made a DELIVERED message retry (axios throws while reading), and the missing deadline let an unclosed stream hang the queue and resend. Not reading the body is how that whole class stops being reachable rather than defended against. responseType 'stream' still keeps axios from buffering; the stream is destroyed immediately and the id is synthesised as before. The status was always the delivery verdict, and it is known before any of this. An 'error' listener goes on before destroy(): destroy can emit on a socket-backed stream, and an unhandled 'error' on a stream throws — which would have turned a receiver's teardown into a failed send. Net: -45 lines of service code, one fewer constant, one fewer test seam, and three of the hardest cases in the suite replaced by two simpler ones. 23 tests, 63 across the email suites, eslint clean. Co-authored-by: Paul Nothaft <[email protected]>	2026-08-29 13:06:19 +02:00
Paul Nothaft	89e8e41c40	chore(main): release 3.121.2-beta.0 (#1238)	2026-08-29 10:27:50 +00:00