100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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	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
Paul NothaftandPaul Nothaft	6ca8baab23	fix(watcher): stop re-importing a photo whose file was replaced (#1226) (#1237) ... The existence check matched on filename OR path. replacePhoto regenerates both — a fresh generated filename and a fresh managed path — so a watched-folder photo that had its file replaced stopped matching either arm. The original is still sitting in the watched folder, so the next sweep imported it again and the gallery ended up holding the delivered edit AND the untouched original: the same duplicate shape external_relpath prevents for reference galleries. source_filename is now a third arm. It is the stable key here — written once at ingest by this same path and preserved across a replace by design. Rows predating migration 193 are covered by its backfill: COALESCE(original_filename, filename), and this path never wrote original_filename, so for watcher rows that resolves to the basename being compared. The query is lifted into an exported findExistingPhoto() so the test drives it rather than a copy — the thing under test IS the query, so a query-builder mock would only assert that knex was called the way the test expects. Predates the Lightroom round-trip and applies to the admin replace path too; it became reachable when #1165 brought watcher galleries into round-trip scope. Six tests against a real SQLite database. The load-bearing one fails without the change, verified by removing the arm and re-running; the other five pin what must not move — filename and path matching, the pre-193 backfill shape, a genuinely new file, and event scoping. Co-authored-by: Paul Nothaft <[email protected]>	2026-08-29 12:22:50 +02:00
Paul Nothaft	064b1bcb14	chore(main): release 3.121.1-beta.0 (#1236)	2026-08-29 10:21:22 +00:00
Paul NothaftandPaul Nothaft	4105c099c9	test(external): make the fold-collision guard test the real code (#745 follow-up) (#1234) ... The regression test added with #1165 re-implemented the claim ordering and the claim loop inside the test file and asserted against its own copy. It never required externalRelpathFold, so changing the real sort left it green — a guard against silently deleting a client's delivered edit that guarded nothing. The ordering is now a named, exported claimOrderFor() and the test drives it. Verified by sabotage: replacing the comparator with `return 0` fails the test, where before it passed. Three cases added while the seam existed: the managed row wins from BOTH input orders (the original bug was that the survivor was whichever came first, so one order proves nothing), the sort is stable for rows of the same kind, and it does not mutate the caller's array. No behaviour change — the comparator is byte-identical, only lifted out. Co-authored-by: Paul Nothaft <[email protected]>	2026-08-29 12:15:31 +02:00
Paul NothaftandPaul Nothaft	0d41fe5bf1	fix(email): keep the webhook payload out of the logs, and bound the response read (#1225) (#1233) ... Round 4 of external review, on the merged commit. Both findings are consequences of the round-3 streaming change, which is exactly why the round was worth running. An AxiosError carries the request it failed on: `config.data` is the ENTIRE serialised message, base64 attachments included, and `config.headers` holds the signature. emailProcessor logs the error object and winston serialises it, so a DNS blip or a refused connection wrote password-reset links, guest recovery codes and multi-megabyte invoices into combined.log — verified against axios rather than assumed. Every rejection is now caught and replaced with a message-and-code-only error, so nothing downstream can serialise the request back out of it. readBounded had no deadline. axios' `timeout` covers the response HEADERS, and with responseType 'stream' it has already resolved by the time the body is read — so a receiver that answered 2xx and never closed its body left the await hanging, the queue row stayed pending, and the next processor pass sent the same message again. An unclosed stream was duplicate email. There is now a 10s wall clock that destroys the stream, with the timer unref'd so a hung read cannot hold the process open at exit. 23 transport tests (2 new, both failing without these fixes), 63 across the email suites, eslint clean. Co-authored-by: Paul Nothaft <[email protected]>	2026-08-29 12:15:25 +02:00
Paul Nothaft	25a7e64951	chore(main): release 3.121.0-beta.0 (#1232)	2026-08-29 09:16:49 +00:00
Paul Nothaft	d62407f431	feat(email): webhook transport as an alternative to SMTP (#1225) (#1231) ... Setting EMAIL_WEBHOOK_URL makes PicPeak stop sending mail itself and POST each composed message as JSON instead, for something downstream (n8n, Make, a self-hosted relay) to deliver. Unset, every SMTP path is unchanged. Settles the four things #1225 left open: - SSRF: the URL goes through the same DNS-resolving check the outbound webhook worker uses, before every send. Private receivers are opt-in. - Transport security: https is required for anything leaving the machine. The HMAC proves who sent the body, not who can read it, and these bodies carry password-reset links and guest recovery codes. The private-network opt-in doubles as the plaintext opt-in. - Authentication: EMAIL_WEBHOOK_SECRET is required and signs the body as X-PicPeak-Signature, the same scheme as gallery webhooks. A URL without a secret leaves the transport OFF and says so once. - Attachments: carried as base64, not dropped. Oversized ones fail and stay queued rather than arriving without the invoice. Configuration is environment-only on purpose: this redirects every outbound message including password resets, so it must not be changeable from a compromised admin session. Three wiring details decide whether it works at all: docker-compose.yml declares an explicit environment block, so the vars had to be forwarded there; a fresh webhook-only install has no email_configs row (migration 001 seeds it only when SMTP_HOST is set), so the From identity falls back to EMAIL_FROM; and processEmailQueue used to return early when SMTP could not initialise, which would have left the queue permanently unprocessed. guestRecoveryService and the admin test-email endpoint were bypassing the transport — the first dereferenced a null transporter, the second told webhook-only admins to go configure SMTP. emailIntakeService deliberately stays on SMTP: it round-trips a specific mailbox's own credentials. Response handling is streamed and read bounded by hand rather than capped via axios: maxContentLength throws while reading, so a receiver that delivered the mail and then echoed a large body would have been recorded as failed and the message sent again. Note: docker-compose.dev.yml is gitignored and local-only, so the equivalent entries there are not part of this change. docker-compose.production.yml needs none — it passes .env through with env_file. Three rounds of external review; 21 transport tests, 61 across the email suites.	2026-08-29 11:10:32 +02:00
Paul NothaftandPaul Nothaft	f4c054a661	fix(export): name the camera master in photo exports, not the delivered render (#1229) (#1230) ... #1165 added photos.source_filename to this service's select, with a comment saying it was there so the Lightroom round-trip could still match after a re-upload — and then nothing read it. Every output path still used original_filename, which is overwritten the first time an edited render is uploaded over a proof (#745). So after a round-trip the exports named the render. Each of these formats exists to help a photographer find the master on disk, and the render's name does not. The XMP case is the sharpest: the sidecar is written next to a RAW master, so a wrongly-named one is never associated with it. Two helpers, because the sites want different things when nothing is known: cameraName() source_filename || original_filename || null cameraFilenameOrStored() the above, else the stored name The dedicated `original_filename` fields (CSV column, JSON key) keep reporting blank/null when unrecorded — echoing the sanitized stored name there would invite a match against a file that does not exist under it. The places that must emit some name (text list, CSV filename cell, XMP sidecar) fall back to the stored one, as they did before. filename_format='stored' is untouched, and rows with no source_filename still resolve to original_filename, so nothing moves for installs that have never run a replacement. Co-authored-by: Paul Nothaft <[email protected]>	2026-08-29 11:10:05 +02:00
Paul NothaftandPaul Nothaft	4f684eb482	fix(feedback): name the camera original in the exports, not just the stored file (#1224) (#1228) ... Both feedback exports carried only `photos.filename` — the sanitized stored name (`wedding-smith_individual_1755892345.jpg`). Acting on client picks means finding the master on disk, and that name matches nothing in a Lightroom catalog, so the export could not be joined to anything. Adds the camera-original name to the long and pivot shapes, and by extension to the archive's feedback_data.csv/.json, which reuse the same query. COALESCE(source_filename, original_filename), not original_filename alone: the latter is overwritten the first time an edited render is uploaded over a proof (#745), so an export taken after a round-trip would name the render rather than the master and silently stop matching. source_filename is written once at ingest and survives a replace by design (migration 193). That case is the load-bearing test. Aliased to `original_filename` — the name the sibling photo export already uses for this column, and the question the reader is asking. Left empty when neither is known rather than echoing the stored name: blank reads as "no match possible", where repeating the sanitized name invites a match attempt against a file that does not exist under it. The column is added, not swapped: `filename` is untouched, so anything reading the old column keeps working. Reported by the 8digit/picpeak fork, which has carried a narrower version of this patch (original_filename only) across rebases. Co-authored-by: Paul Nothaft <[email protected]>	2026-08-29 11:09:59 +02:00
Paul Nothaft	a8a8b7cc64	chore(main): release 3.120.0-beta.0 (#1227)	2026-08-28 13:50:35 +00:00
Paul Nothaft	1d88fa01ce	chore(main): release 3.119.0-beta.0 (#1223)	2026-08-28 06:41:39 +00:00
Paul NothaftandPaul Nothaft	1f3f7e9c02	fix(gallery): make the returning-guest recovery findable (#1210) (#1217) ... * fix(gallery): make the returning-guest recovery findable (#1210) A guest who fills the registration form in again becomes a second gallery_guests row, and their earlier likes and favourites stop counting as theirs. Recovery has always existed to prevent exactly that — as a small link under the submit button, which people reasonably read as fine print and skipped, so duplicates kept accumulating even for guests who had given an email the first time and were eligible for it. Given its own block below a divider, and worded around what the guest loses by missing it: 'Been here before? Your earlier picks are still saved.' rather than 'I've been here before', which reads as a greeting rather than a reason to stop. The affordance itself becomes 'Get them back'. Still a choice the guest makes, not a check the server runs. Looking up whether the typed address is already registered would answer 'is this person in this gallery' to anyone who asked — which is why /guest/recover always returns 200 and cannot be used that way. The alreadyHere key is retired rather than reworded: a key by that name holding 'Get them back' would mislead the next translator. Both new strings are in all seven locales that carried the old one. Three tests: the hint is present, the affordance routes into recovery rather than registering, and an ordinary first-time registration is unchanged. * fix(i18n): match the German formality in the returning-guest hint (#1210) The dialog addresses the guest as Sie throughout — "Willkommen — wie heißen Sie?", "Ihre Auswahl wird unter diesem Namen gespeichert" — and the new line came out in du. Mixing the two in one modal reads as sloppy to a German speaker. Caught by looking at the rendered dialog rather than the string, which is the argument for screenshotting a copy change at all. * fix(gallery): theme tokens for the recovery block, formal register in nl (#1210) External review of #1217. **The dark variant never fires in a gallery.** A dark gallery preset is delivered through CSS variables; ThemeProvider does not add Tailwind's .dark class. So `text-neutral-600 dark:text-neutral-400` on a dark surface stayed dark grey on dark, and the divider stayed light. My block was the only place in this modal using neutral-* classes at all — the rest already uses text-theme and text-muted-theme for exactly this reason. The divider now takes --color-surface-border, which is the token index.css actually defines. **Dutch had the same mixed register German did.** The dialog says uw/u throughout — 'wat is uw naam?', 'Uw selecties worden opgeslagen' — and the new hint came out with 'Je'. Same slip, same fix, found the same way. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-28 08:33:12 +02:00
Paul NothaftandPaul Nothaft	f18bc568c8	feat(admin): shift-click range selection in the photo grid (#1212) (#1213) ... * feat(admin): shift-click range selection in the photo grid (#1212) Selecting photos was one tile at a time. Select All is all-or-one, so 're-assign these two hundred' meant two hundred clicks — which is how #1209 ran into it, re-categorising a large imported set. Shift-click now selects the span from the last plain click to the tile under the cursor, the way a file manager does. It extends the selection rather than replacing it: the grid already lets you accumulate tiles one at a time, so a range is another addition to that set. And it only ever adds — deselecting by dragging a range back over itself is a different gesture, and guessing at it would let a mis-aimed shift-click destroy a selection instead of growing it. The anchor stays put across repeated shift-clicks, so the second one re-aims the same span from the original point instead of walking along behind the cursor. The anchor carries the id of the tile it was set on, not just the index. An index means a different photo after a filter or a re-sort, and a range measured from a stale anchor would select the wrong span with nothing to show for it; the write checks the anchor still points where it was set and falls back to a plain toggle when it does not. Validating at use rather than clearing on every list change means a background refetch, which hands back an equal list, leaves the anchor usable. Seven tests, four of which fail without the change; the other three pin the plain-click and no-anchor behaviour that must not move. * fix(admin): clear the range anchor whenever the selection is cleared (#1212) External review. Cancel Selection, Deselect All and a successful bulk move or delete all emptied selectedPhotos and left the anchor behind. The anchor is invisible, and the list is usually unchanged, so it stayed valid — the next shift-click reached back into a selection session the user had already ended and selected a range they never started. Cleared at all four reset points now. Test fails against the un-fixed code. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-28 08:27:46 +02:00