1387 Commits

Author	SHA1	Message	Date
Paul Nothaft	a89057df1d	fix(search): stop escapeLikePattern corrupting bound search values ... Verified against a real SQLite connection -- each of these returned zero rows before and the right row after: "Sarah's" before=[] after=["Sarah's Birthday"] "100%" before=[] after=["Summer 100% Sale"] "Gala_" before=[] after=["Gala_Night"] Two bugs in one helper. It did .replace(/'/g, "''"), which is SQL string-quote doubling -- meaningless and actively corrupting for a value that is bound, so any search containing an apostrophe matched nothing. And its \% escaping had no ESCAPE clause on the LIKE, which is engine-dependent: honoured on Postgres, a literal backslash on SQLite, so % and _ stayed wildcards there. Now mirrors the correct implementation from 59666b59: escape \ % _ only, and a new likeWithEscape(column) emits `col LIKE ? ESCAPE '\'`. Both call sites move to whereRaw with the value still bound; the column argument is a literal, documented in the JSDoc. Callers checked before changing the contract: adminPhotos.js, adminEvents/crud.js, and sqlSecurity's own addLikeCondition(), which has no callers anywhere -- pre-existing dead export, updated to the new shape rather than deleted. Behavioural change: searches containing ' % _ or \ now return the right rows instead of nothing. Case sensitivity is unchanged. Refs testplan REPORT.md, escapeLikePattern finding.	2026-09-02 09:43:10 +02:00
Paul Nothaft	34685505be	fix(analytics): serve self-hosted trackers same-origin so CSP stops blocking ... A self-hosted Umami/Rybbit domain configured in Settings could never load: the CSP script-src allowlist is static, and the earlier pass could only add an admin-visible warning because nginx.conf:58 strips helmet's header and location / serves the SPA document off disk via try_files -- so helmet can never govern it in Docker. Verified by reading the config, not inferred; that kills the "make helmet dynamic" option outright. Rather than templating the CSP, the tracker is now same-origin. The script and every endpoint it talks to are served from /api/analytics/tracker/* and proxied server-side to the configured instance, so script-src 'self' and connect-src 'self' already cover it. The CSP is unchanged: nothing to template, no env var, no restart -- it takes effect when Settings is saved. That also closes A3 structurally rather than by widening a directive. Endpoint mapping taken from vendor sources, not guessed: Umami's host || currentScript.src + /api/send, and Rybbit's documented /track, /site/tracking-config/<id>, /site/<id>/feature-flags/evaluate. data-host-url is set explicitly so a COLLECT_API_HOST-built Umami cannot bypass the proxy. Session replay is deliberately NOT proxied: replaying gallery pages would capture the share token (GHSA-7m6c). nginx still needed one line, for a non-obvious reason: the static-asset regex location outranks the plain /api prefix in nginx's matching order, so /api/analytics/tracker/script.js resolved as a static file. Confirmed empirically against a real nginx:alpine -- 404 before the ^~ block, 502 (proxied) after, with /assets/app.js and /api/public/settings unchanged. The native SERVE_FRONTEND install needed no change; helmet already has 'self' in both directives and the proxy mounts ahead of express.static. Security boundary, since this makes the server fetch an admin-supplied URL: closed per-provider path+method allowlist (4 paths), DNS-resolving isHostAllowed blocking private/internal/metadata addresses in production (matching the s3Storage prod-only precedent), base rebuilt as origin + pathname so userinfo/query/fragment cannot smuggle anything, redirect: 'error', cookie/authorization/referer/host never forwarded, an HTML upstream response re-served as application/octet-stream + nosniff, and 64KB request / 2MB response / 5s timeout / 120rpm caps. X-Forwarded-For and User-Agent are forwarded so geo and device attribution survive. Residual, stated plainly: an unauthenticated rate-limited relay to one admin-chosen public host on 4 paths, and TOCTOU DNS rebinding is unmitigated as it is elsewhere in the repo. The Umami and Rybbit panels now explain they are proxied; the Custom panel keeps a CSP warning -- it is the one mode with nothing to proxy -- naming both script-src and connect-src. Refs testplan REPORT.md A2, A3.	2026-09-02 09:43:10 +02:00
Paul Nothaft	fe5ac9162d	fix(photos): emit visibility and processing_status from the list mapper ... The "hidden photo has no indicator on the admin grid" warning was not a missing badge. The badge markup has existed since #172; the defect was in GET /:eventId/photos, which hand-builds its response literal field by field and never emitted `visibility` -- so the value was always undefined and neither the grid tile nor the list row badge could render. Same omission class as the view_count/download_count bug already commented in that file. (The `visibility` line itself was swept into 4721bd83, whose message does not mention it -- recording that here.) Fixes the adjacent instance too: `processing_status` is missing from the same mapper, so the grid's "Processing…" and "Failed"/Retry placeholders could never render either. On the card, reuses the existing EyeOff badge pattern from the list-view rows, adds a tooltip on both layouts, and drops the category badge to top-9 so the hidden badge can own the top-left corner. Also fixes the Photo Limit spinbutton's aria-valuemax, which read 0 even with a real cap set. Root cause: min={0} with no max -- for input[type=number] Blink's MaxValueForRange returns DBL_MAX, fails isfinite and supplies no max, so a11y tooling prints the default 0. Set to 2147483647, the events.photo_cap column's real signed-32-bit ceiling (migration 074), which also stops an out-of-range value failing only at INSERT. The sibling expires_in_days input already had proper bounds. Known: EventInformationCard carries the identical Photo Limit input with the same defect; it is held by another concurrent change and follows next. Refs testplan REPORT.md, hidden-photo and aria-valuemax warnings.	2026-09-02 09:43:10 +02:00
Paul Nothaft	a28f96b304	fix(gallery): no-store private JSON, and give guest uploads a real status ... B6 -- seven gallery routes returned private, per-guest data with no Cache-Control at all, relying on heuristic freshness. noStoreCache is mounted per route rather than on the router, because the media routes set their own private, max-age=1800/3600 and must keep it. Covered: /photos (own likes/favourites/ratings, hidden photos for a client token), /people, /stats, /verify-token/:token (an authorization decision -- a cached {valid:true} outlives a rotated token), /show/:token/session (the response IS a credential; it mints a gallery JWT), /show/:token/state and /download-jobs/:token (live polls, where a cached "preparing" strands the caller). Deliberately untouched: the photo/thumbnail/hero/preview and css-template routes, which set their own caching, the binary downloads, and /info + /resolve, which are unauthenticated public metadata rather than per-guest private. ETag/304 revalidation is intact and pinned by a test: no-store stops the browser retaining the body, not express agreeing an unchanged payload is unchanged. That matters because the post-upload poll depends on it. B7 -- the guest upload flow had no progress signal, so the UI polled the photo list blind and gave up after 60s with no explanation. Adds GET /:slug/uploads/status?ids=... rather than pending counts in the photos payload: counts there are event-wide, so another guest's or the admin's stuck upload would spin the notice forever and it could never say "your photo failed". Authorization: verifyGalleryAccess already resolves req.event from the caller's token, and the query is scoped `.where('event_id', req.event.id)`, so an id from another gallery matches no row -- neither a cross-event read nor an existence oracle, since it returns all-zero counts rather than a 403/404 that would confirm the id exists elsewhere. Slideshow tokens are denied (a kiosk never uploads). Ids are pattern-validated, max 50. The response is counts only: no filenames and specifically no processing_error strings, which can carry internal paths. Not gated on allow_user_uploads, so an admin flipping the toggle mid-flight does not strand an in-progress guest. The frontend now finishes on the real terminal condition, refetches as each photo lands rather than only at the end, shows a processing pill, and reports real failures instead of silently timing out. Refs testplan REPORT.md B6, B7.	2026-09-02 09:43:10 +02:00
Paul Nothaft	7c9baff751	fix(upload): scope category ids, stop temp-file leaks, split the video cap ... Four related fixes on the admin upload/photo path. B5 -- PATCH /photos/:photoId and POST /photos/bulk-update took any parseInt(...) > 0 straight into the update with no existence or scope check, so a photo could be moved into another event's category. The upload route already validated `event_id = X OR is_global` per #500/#525; extracted that query as findScopedCategory() and used it on all three routes so the 400 body is byte-identical. 0/negative/'individual'/'collage'/null still clear without a lookup, so the clear path costs no extra query. B9 -- three distinct temp-file leaks, not one. The validator's size branch never unlinked; the cleanup lived in the final handler, unreachable on any 400; and multer's `destination` callback runs per file and overwrote req.tempUploadPath, so even the success path only ever removed the last file's directory. Now: discardUploadedFiles() runs on every 4xx and the 500 (ENOENT tolerated, and files are only dropped when the whole request is being rejected, so the passing path is untouched); cleanup registered before multer so it also covers multer's own LIMIT_FILE_SIZE return; one directory per request. B8 -- the admin uploader filtered on MIME only, so an oversized file was uploaded in full before the server's 400. Mirrors UserPhotoUpload's existing per-file toast-and-drop. C4 -- general_max_file_size_mb was a single cap for photos and videos, so the 50MB default meant admins could not upload ordinary video without also raising the photo limit. Adds general_max_video_size_mb (default 500MB, clamped by the same 10GB MAX_ALLOWED_FILE_SIZE_MB ceiling, read per request, 60s cache), editable in Settings -> General. Photo uploads are protected from regressing by keeping multer's type-blind limit at max(photoCap, videoCap) and moving the per-kind decision into validateUploadContent, where file.mimetype exists. It 400s with the existing message shape, so an oversized photo is still rejected with the identical body it produced when multer did the rejecting. Known gap: chunked-upload/init still applies the photo cap to video. Making it video-aware would change an existing assertion that pins a 200MB video init being rejected under a 1MB general cap. No component calls that path today and the direction is strict rather than a bypass, so it is left as-is. Guest video uploads still share the single cap in gallery.js. Refs testplan REPORT.md B5, B8, B9, C4.	2026-09-02 09:43:10 +02:00
Paul Nothaft	57dd084763	fix(events): add archive_size to the immutable column deny-set ... IMMUTABLE_EVENT_COLUMNS is documented as a COMPLETE deny-set that new server-managed columns must be added to. archive_size is written by archiveService from the zip's real byte count and is what the archives list now sorts and displays, so an events.edit holder could otherwise set a cosmetic size on a non-archived event. Follow-up to 59666b59, which added the column.	2026-09-02 09:43:10 +02:00
Paul Nothaft	42ba8351c1	fix(middleware): log ownership lookup failures; drop dead auth surface ... ownership.js caught a lookup failure, returned 500 and logged nothing -- the file had no logger import, so a failing ownership check was invisible in the logs. Added logging matching photoAuth.js/permissions.js ({ error, stack } plus the relevant id), response behaviour unchanged. Fixed both swallowed catches: requireEventOwnership, the reported one, and the byte-identical requireProjectOwnership. Also removes AdminAuthContext.updatePasswordChanged, now dead -- superseded by the deliberate full-page reload in onSuccess, with zero callers left. setMustChangePassword and mustChangePassword stay; nothing else orphaned. Refs testplan REPORT.md B13, B16.	2026-09-02 09:43:10 +02:00
Paul Nothaft	103863cbab	fix(quotes): enforce the status state machine, and correct the table ... VALID_QUOTE_TRANSITIONS was a complete-looking quote state machine that nothing consulted, so status changes were unvalidated. Mapping every writer of quotes.status (quoteService.js is the only one -- dealsService, projectService, adminDashboard and customer.js all read) showed the table itself was wrong: six legitimate transitions were missing. sendQuote allows draft/declined/expired -> sent but the table had draft only; adminAcceptQuote allows draft/sent/expired but had sent only; adminDeclineQuote allows draft/sent/expired but had draft/sent; recordResponse had no same-status entry. Enforcing it as written would have broken accept-on-behalf from a draft, resend-after-decline, every expired revival and the 15-minute response-toggle window. So the table is reconciled to reality first, then assertQuoteTransition() (409, QUOTE_INVALID_TRANSITION) is called at all seven sites. Two things worth carrying forward. Nothing in the codebase ever sets 'expired' -- the header comment says "set by the scheduler" and there is no such scheduler; sent -> expired is retained as documented intent only. And the backstop's added value is narrow: every reachable invalid transition is already caught by a call site's own better-worded guard, which fires first. What it newly catches is a status the machine has never heard of -- a legacy or corrupt row like 'cancelled' sails through adminAcceptQuote's guard, which only excludes accepted/declined/converted, and used to be silently overwritten. That is what the new tests pin. Refs testplan REPORT.md B4.	2026-09-02 09:43:10 +02:00
Paul Nothaft	a7d45ddd0d	fix(workflows): restore the once-per-process seed guard ... `booted` was assigned but never read, so the guard's early return was missing and the builtin workflow seeder ran on every call. Impact was wasteful, not harmful: seedOneBuiltin is idempotent -- it keys on builtin_key and returns early when adminOwned or storedVersion >= def.version, writing a graph only on a fresh insert or a version bump. So repeat calls cost a lookup per builtin plus a graph rebuild, with no duplicate rows. `booted = true` stays inside the try, so a seed that never got off the ground (workflows table not migrated, DB down) leaves the flag clear and retries. A per-builtin failure is still swallowed by the inner catch and does not block the flag, unchanged. Restoring the guard broke workflowEngine.test.js, which calls the boot seeder seven times in one worker and needs the second call to run in two of them. Followed the existing _backupPathsBoot/_restoreSettingsBoot precedent: exported _resetBootForTests(). Refs testplan REPORT.md B3.	2026-09-02 09:43:10 +02:00
Paul Nothaft	41e1de7818	fix(email): repair and seed the gallery lifecycle templates ... Correction: the reported premise held for only one of the three templates, verified by running the core migration set against an empty database. - expiration_warning is German-is-English on every fresh install, exactly as reported. Repaired with migration 194's pattern verbatim. - gallery_expired and archive_complete are NOT German-is-English -- they do not exist at all. Their master rows are inserted only by migrations/legacy/ 010+020, which never run on a fresh install, so 075/099/106/108 seeded zero translations for them (they key off a master row that is not there). A fresh install's email_templates holds 17 keys and neither is among them. The consequence is worse than a translation gap: expirationChecker's sendGalleryExpiredEmails and archiveService's completion mail both hit "Email template not found", retry three times and die silently in email_queue on every expiry and every archive. So 195 also seeds those two (master row + en/de translations + category), but only when the master row is absent -- it never overwrites. English follows legacy 028, which emailProcessor's own comments call the shipped copy; German follows legacy 026's wording. Both are restructured into the plain unstyled shape the other core-seeded templates use, so wrapEmailHtml's configurable palette governs styling rather than hard-coded hex. The support-contact line is wrapped in {{#if support_email}} because getSupportEmail() can return ''. 196 adds the {{#if welcome_message}} block that nl/pt/ru/fr/es/sl already have in gallery_created but en and de lack, so the photographer's personal note was silently dropped for those two locales even though the value is passed at send time. safeTemplateReplace does resolve {{#if}} before variable substitution, so this is a real conditional -- there is a test rendering the migrated body both ways. HTML body only, matching the other locales: emailProcessor rewrites welcome_message through formatWelcomeMessage (escape + nl2br) once for both bodies, so the text part would print literal <br /> and &amp;. Both migrations keep 194's conservative condition -- rewrite only while the German is still byte-identical to English or empty -- so admin-edited and legacy-translated installs are untouched. Idempotent, guarded, no-op down(). Known gap, documented in 195's header: the two newly seeded templates get en/de only. nl/pt/ru/fr/es/sl fall back to en via processTemplate's fallback chain, which is strictly better than today's hard failure but is not real localisation. Refs testplan REPORT.md B1, B2.	2026-09-02 09:43:10 +02:00
Paul Nothaft	afc5779ce7	fix(events): return 409 instead of 500 when a slug is taken ... Correction to the reported cause: both create paths already loop `while (await db('events').where({ slug }).first())` before inserting, so a sequential duplicate never 500s -- it gets -1 appended. The 500 is purely the read-then-insert race: two concurrent creates for the same name+date both clear the check and the loser's INSERT trips events_slug_unique. isDuplicateSlugError(), built on the existing utils/dbErrors.isUniqueViolation, is wired into the catch of POST / and POST /:id/duplicate -> 409 { code: 'EVENT_SLUG_TAKEN' }. The predicate is deliberately narrower than isUniqueViolation: on PG it matches err.constraint, on SQLite the specific "UNIQUE constraint failed: ... events.slug" text. A loose message test would misfire because knex prefixes the whole INSERT -- which always names slug -- to err.message, and events has other unique columns (share_token). PUT /:id cannot collide: slug is in IMMUTABLE_EVENT_COLUMNS. No other adminEvents sub-router writes slug. CreateEventPage already toasts data.error, so no frontend change is needed. The test makes the race deterministic without timers: it hooks knex's `query` event and injects the colliding row the instant the route issues its slug-existence SELECT. The route then spends a full bcrypt hash before its own INSERT, so the injected row always lands first. Refs testplan REPORT.md B10.	2026-09-02 09:43:10 +02:00
Paul Nothaft	da6e34d6a3	fix(archives): sort and total on real archive sizes, escape LIKE wildcards ... Closes the three trade-offs the server-side archives query deliberately accepted. C1 -- the sorted number and the displayed number are now the same one. There was no archive_size column, so the Size column came from a per-row fs.stat done after pagination while the sort fell back to summed photo bytes: the list could be ordered by a number the user was not looking at. Adds events.archive_size (bigInteger -- int4's 2.1GB ceiling is the same limit that forced the restore path off adm-zip), written at archive time from archive.pointer(), which is the exact byte count the completion email already reports. The route now sorts and displays that column and no longer touches the filesystem. The migration backfills by stat-ing every archive_path where the column is null, outside the column guard so a half-finished run self-heals; unstatable rows (missing zip, S3-backed storage) stay null, order last via COALESCE and display 0 -- exactly what the old fs.stat produced for a file it could not read. Restore nulls it alongside archive_path. Accepted: the list no longer notices a zip deleted out of band and shows the last recorded size. The detail route still stats the real file. C2 -- escape \ % _ in the bound value plus an explicit ESCAPE '\'. The ESCAPE clause is load-bearing rather than decorative: SQLite has no default LIKE escape character, so without it the escaped pattern matches literal backslashes and the search silently returns nothing on SQLite while working on Postgres. The value stays bound; no interpolation. C3 -- the four stat cards aggregated only the current page, so every total was wrong for any dataset past page one. The list response now carries totals { archives, photos, archiveSize } computed with the same applyFilters() closure as pagination.total, so cards and footer cannot drift. Two aggregate queries: archive_size sums on the unjoined events query (joining photos multiplies it by photo count) and photos count on the joined one, both read back through Number() for pg's bigint-as-string. The "Showing X of Y" line moved out of the totalPages > 1 guard so it survives a single-page result, now gated on total > 0 so a zero-result search does not render "Showing 1 to 0 of 0"; only the page controls stay conditional. Test fixtures deliberately order zip sizes differently from summed photo bytes, so the sort test can only pass on the right column. Refs testplan REPORT.md C1, C2, C3.	2026-09-02 09:43:10 +02:00
Paul Nothaft	0ae424ff42	test(migrations): pin migration 194's per-field guard ... The per-field fix landed without a test for the case it exists for: an admin-translated subject over a still-English body, and the reverse.	2026-09-02 09:43:02 +02:00
Paul Nothaft	77b11ab874	fix(upload): enforce the chunked-upload cap on bytes received, not declared ... The init route checked the client-declared fileSize against general_max_file_size_mb, but nothing checked what then came through the chunk route: a client could declare `fileSize: 1` and stream any amount, and completeUpload only logged the size mismatch before handing the merged file on. The cap the earlier commit added at init was therefore a gate with no fence. The service now carries the cap from init and enforces it on the running byte total per chunk (aborting the upload once crossed, since the chunks on disk are already over the limit), rejects chunk indices outside the announced range, and re-checks the merged file as a backstop. Both routes answer 413/400 for these instead of a blanket 500.	2026-09-02 09:33:34 +02:00
Paul Nothaft	814f205da0	fix(feedback): make the "block" severity tier actually reject ... The block level is advertised as "comment is rejected immediately", but every non-approved comment was saved with is_approved = false instead of the submission being refused. moderateText now sets an explicit `blocked: true` on the blocking-violation branch -- branching on the reason string in the route would have been fragile -- and the route 400s with code COMMENT_BLOCKED and stores nothing. Everything else that is not approved (moderate/high, the spam and caps checks, and the "Moderation system error" fallback) deliberately omits the flag and keeps the held-for-moderation path, so a moderation failure still fails safe. Also fixes an adjacent defect that made the tier split unobservable: feedbackService.submitFeedback ignored feedbackData.is_approved entirely and hard-derived is_approved from moderate_comments. So a moderate/high word-filter hit on an event with moderation switched OFF was published immediately -- the route's `feedbackData.is_approved = false` was dead code. Now honoured one-directionally: a caller-supplied false is respected, but nothing a caller passes can RELAX the event's setting. That deliberately leaves the route's reputation.autoApprove -> is_approved = true branch inert rather than letting a trusted guest bypass an event's moderation setting. Refs testplan REPORT.md B11. (cherry picked from commit b1b57b1615aaf02fe76e789a86b7e11933288d77)	2026-09-02 09:30:49 +02:00
Paul Nothaft	da8fcc82ef	fix: per-field template guard, LIKE escaping, wait for all uploads ... Codex review round 1 on #1266. Migration 194 gated all three German fields on body_html alone, so an admin who had translated only the subject would lose it the moment the HTML still matched English -- and down() is a deliberate no-op, making that loss unrecoverable. Each field is now judged independently, for both the translations table and the legacy _de columns. Archives search escapes LIKE wildcards. % and _ are literal characters to the client-side includes() this replaced but wildcards to LIKE, so searching "100%" matched every archive and reported a nonsense total. The ESCAPE clause is load-bearing: SQLite has no default LIKE escape character, so without it the escaped pattern matches literal backslashes there while working on PG. The post-upload poll waits for every queued file. Each is processed independently, so stopping at the first new photo left the rest of a multi-file upload hidden until a manual refresh -- the exact symptom the polling was added to prevent. UserPhotoUpload now reports how many files the server accepted. (The latter two are superseded by stronger fixes in #1267 -- the upload-status endpoint and the shared escape helper -- but each PR has to be correct on its own.)	2026-09-02 08:41:36 +02:00
Paul Nothaft	6e5755de02	fix(types): resolve the TypeScript build:check backlog ... 74 errors -> 1. No suppressions: zero `any`, `as unknown as`, `@ts-ignore` or non-null `!` added, and tsconfig is untouched. Each error was triaged as "the type is wrong" vs "the code is wrong" and fixed on that side. Live bugs the checker was pointing at: - admin.service.ts TS1117 duplicate key: admin_password_reset was defined twice and the later one won at runtime. Removed it so the earlier entry wins, which matches the actual emitter in userManagementService.js and carries the email fallback. - PhotoGridWithLayouts dropped allowReactions from its prop type, so the Premium layout's reactions never activated even though GalleryView passes it and GalleryPremiumLayout reads it. - SlideshowPage's poll never copied `order` into next/prev, so live play-order changes never reached a running kiosk. - CustomerLayout compared branding_force_color_mode against 'auto', which is never persisted (only 'dark'|'light'|null), so the customer portal always picked the light logo even in OS dark mode. - EmailConfigPage rendered lang.flag, but SUPPORTED_LANGUAGES exposes Flag, a component -- so nothing rendered. And editing a language with no translation yet spread undefined, storing a partial object missing required fields. - publicQuotes.js projected only 6 line-item fields, omitting parentLineItemId/parentPosition/detailsText, so the migration-119 sub-item hierarchy and details text could never render on the customer-facing quote page -- the frontend code for it was unreachable. It reads from the same quoteService.getQuoteById the admin route uses, where those fields are present; adminQuotes.js projects all three. Fixed the projection rather than adding fields to the frontend type, which would have compiled while leaving the feature broken. - DuplicateEventDialog's helper text was silently dropped: LocalizedDateInput had no helperText prop. Added, mirroring Input.tsx incl. aria-describedby. - ThemeEditorModal/EventThemeSection still passed isPreviewMode, a prop 822be9a9 deliberately removed but missed at these two call sites. - GalleryPage's hero-photo injection was dead: /gallery/:slug/info does not return hero_photo_id (only /photos does) and GalleryView already does it correctly. Removed the dead block rather than adding a field the API never sends. Stale types corrected against the backend route that produces each payload: GalleryInfo (allow_downloads, allow_user_uploads), GalleryData.event (download_zip_ready), UpdateEventData (client_access_enabled, client_password, regenerate_client_token), InvoiceSummary (replacesInvoiceId), ExportOptions (mark_source, plus a snake_case ExportFilter matching the actual wire format), customer.service contracts, AdminUser timestamps widened to string|null, formatMoney currency widened to match its own (currency || 'CHF') guard, faceCropStyle dimensions widened to match its !photoWidth guard, DEFAULT_FLAGS faces, logo_position 'sidepanel', and the hand-rolled t() props replaced with i18next's TFunction in four files. Unused symbols were checked before deletion; UpdateInstructionsDialog's targetVersion prop was completed rather than deleted (declared and passed but never rendered -- now the fallback before the query resolves). Left unfixed, deliberately: GalleryStoryLayout's handleOpenFeedback (TS6133). It is the only caller of setSelectedPhotoForFeedback and is itself never called, so StoryFeedbackSheet can never open on the Story theme. Wiring it needs a new affordance on StoryPhotoCard (no sibling layout exposes one to copy) and deleting it would orphan the sheet -- a product decision, not a type fix. Note PhotoLightbox on the same layout already handles feedback, so the sheet may simply be superseded. Refs testplan REPORT.md #22 (Part 1.3.04).	2026-09-01 17:09:24 +02:00
Paul Nothaft	9143997f8e	style(backend): clear the eslint backlog to zero ... 929 problems (928 errors, 1 warning) -> 0, exit 0. Rule breakdown, which corrects the report's premise -- `indent` dominated, not `quotes`: indent 719, quotes 68, no-unused-vars 54, no-empty 36, no-useless-escape 22, no-case-declarations 17, no-inner-declarations 6, no-control-regex 5, no-useless-catch 1, no-console 1 (warn). --fix handled only indent + quotes (719+68 = exactly the "fixable" count). no-useless-escape was NOT auto-fixable in this eslint version, so the one genuinely risky class never went through the autofixer -- all 22 were done by hand. Two mechanical proofs on the autofix diff: a token-level AST diff (espree, before vs after) shows exactly 68 differing tokens, all quotes, with the 719 indent fixes producing zero token changes; and a cooked-value diff of every string/template/regex literal shows 0 differences. Regex escapes: eslint was correctly conservative and did not flag the load-bearing ones -- \- in [^a-zA-Z0-9_\-\.] (unescaping makes an invalid reversed _ -> . range) or in [!@#$%^&*()_+\-=...] (would become a + -> = range silently matching ",-."). Every removal was a \/ \[ or \. inside a character class; all 11 old/new pairs were brute-forced over 794 inputs with 0 mismatches. Manual fixes: no-empty were all deliberate best-effort catches around activity logging, annotated rather than restructured; no-case-declarations braced in two adminBackup switches; no-inner-declarations converted to const arrows after checking no call precedes the declaration and no this/arguments use; no-control-regex and no-console got targeted disables with stated reasons; one `catch (e) { throw e; }` wrapper removed. Two unused bindings were near-misses worth noting: secureStatic.js's `fullPath` is a path-traversal guard (safePathJoin throws on escape) and restoreService.js's `backupManifest` is the throw-on-corrupt-manifest gate before a rollback -- deleting either would have silently removed a check. Only the bindings were dropped; the calls stay. Two real bugs found and deliberately preserved with a comment plus a narrow disable rather than deleted, since deleting would erase the evidence: _workflowSeedBoot.js's `booted` is written but never read, so the intended once-per-process guard is missing its early return and workflows re-seed on every call; and quoteService.js's VALID_QUOTE_TRANSITIONS is a full state machine nothing consults, so quote status changes are unvalidated. Backend test suite: 253 suites / 2552 tests passing, 0 failures, before and after. Refs testplan REPORT.md #22 (Part 1.2.02).	2026-09-01 16:46:34 +02:00
Paul Nothaft	73b08a7b5c	fix(email): give gallery_created a real German translation ... translations.de for gallery_created was the English copy word for word, while nl/pt/ru/fr/es/sl are all localized. This is the mail sent on every gallery creation, so German-default installs have been silently mailing English. Root cause chain, fresh installs only: 001_init seeds the English template; 059 introduces the multilingual columns and fills subject_de/body_html_de/ body_text_de from their _en counterparts (its own comment: "Copy to German as default"); 075 then materialises exactly those columns as the `de` row. The real German only ever existed in migrations/legacy/026, and run-migrations.js runs core/ only for fresh installs -- so every install created since 059 has the English-as-German row. A code-only fix would have changed nothing: knex will not re-run 059/075, so existing installs would keep the bad row forever. Fixed as a content migration following the repo's precedent for template repairs (094, 172). Conservative about what it touches: the German row is rewritten only while it is still byte-identical to English (or empty) -- precisely the broken state -- so a legacy install whose German came from 026, or any admin-edited template, is left alone. Also repairs the legacy _de columns, which are still emailProcessor's fallback path. Idempotent, hasTable-guarded, no-op down() (reverting would restore English-as-German). Placeholder parity with the English original is exact and test-asserted: host_name, event_name, event_date, gallery_link, gallery_password, expiry_date. Two related gaps found but deliberately not fixed, both outside the reported bug: expiration_warning, gallery_expired and archive_complete are German-is- English on fresh installs through the identical 059 mechanism (legacy 026 fixed all four). And nl/pt/ru/fr/es/sl additionally wrap a {{#if welcome_message}} block that the English original lacks, even though welcome_message is passed at send time -- so EN and now DE drop the photographer's personal note. That is an English-side gap needing its own decision. Refs testplan REPORT.md #16 (Part 3, J.04).	2026-09-01 16:40:02 +02:00
Paul Nothaft	fc7cb226f4	fix(archives): run search, filter and sort server-side ... ArchivesPage fetched one 20-row page and then filtered and sorted only that array in memory, while "Showing X of 802" / "Page 1 of 41" kept reporting the full unfiltered count. Searching for an archive that exists but is not on the current page returned a false "0 results" with no hint the search was page-scoped. The backend did not support the params (it read only page/limit and hardcoded orderBy archived_at desc), so all three are new. Follows adminEvents/crud.js for the shape and customerAccountsService for the case-insensitive predicate: whereRaw with a bound parameter, never interpolated, and sortBy whitelisted to date/name/size before it reaches orderBy. The same applyFilters() closure runs against both the count query and the row query, so the total cannot drift from the rows again. Frontend mirrors EventsListPage: 300ms debounce, reset to page 1 on any query change, placeholderData so keystrokes don't flash the spinner. Two interpretation calls: - sortBy=size orders by summed photo bytes, not the zip's on-disk size. The Size column comes from a per-row fs.stat done after pagination and there is no archive_size column, so a global sort on the real zip size would stat all 802 files per request. Ordering is near-identical except for rows whose zip is missing. Adding events.archive_size would be a migration, out of scope. - No LIKE-metacharacter escaping. escapeLikePattern() does .replace(/'/g,"''"), which corrupts a bound value ("Sarah's Birthday"), and its backslash escaping is a no-op on SQLite without an ESCAPE clause. Matched customerAccountsService instead. A literal % typed by an admin acts as a wildcard in a read-only search; no injection risk. Pre-existing and untouched: the four stat cards still aggregate the current page only. Refs testplan REPORT.md #9 (Part 3, I.01).	2026-09-01 16:31:09 +02:00
Paul Nothaft	3f6c81a846	fix(photos): treat category_id 0 as uncategorized instead of storing it ... Genuine product bug, found behind the adminPhotos.reference suite (which was failing for an unrelated reason -- see below). parseInt('0') is 0 and !isNaN(0) is true, so a '0' category_id was written literally. photo_categories.id is an increments() column, so 0 can never be a real category, and every read path already assumes it cannot happen: the list mapper does `category_id || type` (0 is falsy, renders as uncategorized) and the list filter explicitly skips '0'. The result was a filter black hole -- the photo matches no numeric category filter, and misses the "uncategorized" filter too because that is whereNull(). Displayed as uncategorized, reachable by nothing. null rather than a 400: unparseable input ('abc' -> NaN) already falls through to null, so 400ing on '0' while silently accepting 'abc' would be incoherent, and '0' is just the HTML <select> shape where the "none" option carries value="0". Fixed at all three call sites that share the branch -- PATCH /photos/:photoId, POST /photos/bulk-update, and the upload route, where the dangling 0 was written at creation time and the scope-validation guard (`if (parsedCategoryId && ...)`) skipped on the falsy 0 and let it in unvalidated. Only the PATCH one was behind the failing test; leaving the other two would have left the bad state creatable. The suite's 3 failures were all masked by a fixture gap, not this bug: it stubs middleware/auth but not middleware/permissions, so requirePermission's admin_users JOIN roles query hit tables the fixture never creates and every request 500'd before reaching a handler. Stub it, bring the photos fixture up to the 7 migrations it had drifted behind, and correct a stale 200 that became 202 when uploads went async in 851744c3. Known adjacent gap, not fixed (wider than this bug): PATCH and bulk-update accept any positive category_id with no existence or scope check, unlike the upload route which validates event_id = X OR is_global per #500/#525 -- so a photo can be PATCHed into another event's category. Refs testplan REPORT.md #22 (Part 1.2.01).	2026-09-01 16:30:46 +02:00
Paul Nothaft	1d84c738d8	test: repair four stale backend suites ... All four asserted contracts the product has since moved past. No genuine product bugs behind any of them; assertions were tightened, not loosened. adminAuth (3 tests): never mounted errorHandler, so ConflictError/ ValidationError arrived as empty Express defaults. The route also checks username before email, so the "email conflict" fixture was hitting the username branch. Mount the handler, fix the fixture, match the real response shapes. backupService.enhanced (12 tests): three stacked drifts -- the db mock had no .returning(), so every runBackup threw at the insert; ensureDatabaseDumpForBackup now lazily requires ./databaseBackup inside the run, which fails under mock-fs; and the rsync path moved from exec(shell string) to spawnAsync('rsync', args) with an isHostAllowed SSRF preflight. Also updates getBackupStatus to its current shape (frontend aliases, nextScheduledRun null when no schedule is enabled, #871). adminSettings.logo: POST /logo gained requirePermission('settings.edit'); the hand-rolled db mock returns a bare Promise from select(), so the permission lookup threw a TypeError into a 500. Mock the permissions middleware alongside the already-mocked auth. crmMintPaths (2 tests): macOS-only. The expected prefix was realpath'd while the services persist under the raw STORAGE_PATH -- identical on Linux CI (/var vs /private/var only diverges on macOS), which is why it passed there. The comment justifying the realpath referenced process.cwd() behaviour the services no longer have. Refs testplan REPORT.md #22 (Part 1.2.01).	2026-09-01 16:29:03 +02:00
Paul Nothaft	c5c5a6b0c8	fix(webhooks): write delivery timestamps as ISO strings ... Applies the repo's documented Jest+SQLite guidance (CLAUDE.md) to the webhook delivery path, which was the last one still passing raw Date objects into knex writes. Under jest those store as the literal string "[object Object]", so next_retry_at came back NaN and the retry/backoff test could not assert on it. Production (PG, and SQLite outside jest) was unaffected. Convert the timestamp writes -- and the `next_retry_at <=` due comparison, which has to stay type-consistent with them -- to .toISOString(), matching the existing precedent in downloadJobService.js. Refs testplan REPORT.md #22 (Part 1.2.01).	2026-09-01 16:29:03 +02:00
Paul Nothaft	5fa04e647e	fix(categories): validate category name length instead of 500ing ... photo_categories.name is varchar(100). Neither the input nor the route checked length, so a 267-char name hit a raw Postgres "value too long", came back as a 500, and the form silently stayed open with no toast. Add isLength({ max: 100 }) to POST / and PUT /:id (the update route had the identical gap) so it returns the route family's normal 400 { errors: [...] } shape that the toast helper already renders, and maxLength={100} on the three category-name inputs (create + inline edit in CategoryManager, create in EventCategoryManager). Refs testplan REPORT.md #4 (Part 7.01).	2026-09-01 16:23:28 +02:00
Paul Nothaft	6f7aa59fad	fix(feedback): align word-filter severity vocabulary with the admin UI ... WordFilterManager.tsx sends low/moderate/high/block; the validator only accepted mild/moderate/severe, so 3 of the 4 UI levels 400'd with "Invalid severity level" -- including "block", the strongest advertised tier. Aligning isIn() alone would have made "block" accepted but semantically inert: feedbackModeration.js branches on 'severe'/'moderate', so "block" would fall through to the flag-only branch and behave as the weakest level. Map the UI vocabulary onto the existing outcomes instead, per the legend the UI itself renders: block -> reject, moderate/high -> needs approval, low -> flag only. 'severe' stays an accepted alias in the blocking predicate so any row written through the old validator (the field is optional, so a direct API caller could have stored one) keeps blocking. No data migration needed: the column is a bare varchar(20) default 'moderate' with no CHECK, no enum and no seed rows, and 'mild' already lands in the flag-only branch that 'low' now means. Refs testplan REPORT.md #2 (Part 3, J.11).	2026-09-01 16:23:22 +02:00
Paul Nothaft	e18ab0d842	fix(upload): enforce the configured per-file size limit on admin uploads ... getMaxFileSizeBytes() (general_max_file_size_mb, default 50MB) was only read by adminSettings.js to display the value. The admin upload routes streamed against a hardcoded ceiling instead, so the dropzone's "max. 50MB pro Datei" was never enforced: - adminPhotos.js POST /:eventId/upload -> 10GB hardcoded - adminPhotos.js POST /:eventId/chunked-upload/init -> 10GB hardcoded - v1/events.js POST /events/:id/photos -> 100MB hardcoded Resolve the cap per request (it is admin-configurable at runtime) and build the multer instance from it, mirroring what gallery.js and adminTransfers.js already do. The 400 names the configured limit and reuses gallery.js's exact error string so the frontend surfaces it identically. getMaxFileSizeBytes() clamps to MAX_ALLOWED_FILE_SIZE_MB, so the 10GB hard ceiling still bounds everything. gallery.js (guest upload) already enforced this correctly and is unchanged -- the report's claim that it did not is stale. Interpretation: general_max_file_size_mb is a single per-file cap with no photo/video split, and gallery.js already applies it blanket to guest video uploads, so admin video uploads now share it too. On a default install that means a 200MB video needs the setting raised first -- which is what the UI has been advertising all along. Refs testplan REPORT.md #1 (Part 7.06).	2026-09-01 16:23:04 +02:00
Paul Nothaft	884580d849	chore(main): release 3.122.2-beta.0 (#1258)	2026-09-01 07:30:45 +00:00
Paul Nothaft	7e6bfbecb2	chore(main): release 3.122.1-beta.0 (#1254)	2026-09-01 06:35:22 +00:00
Paul 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 <paul@MacStudio-von-Paul.local>	2026-09-01 08:30:17 +02:00
Paul 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 <paul@MacStudio-von-Paul.local>	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 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 tina@example.com" 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 <paul@MacStudio-von-Paul.local>	2026-09-01 08:18:00 +02:00
peipeimo	bb2f709fdd	fix: single-photo gallery downloads 404 on S3 storage backends (#1048) ... * fix(gallery): route single-photo downloads through the storage backend The route resolved a local filesystem path unconditionally and handed it to res.sendFile. On an S3/R2 deployment managed photos are never on local disk, so every per-photo download failed — while download-all and secure-images worked, because they already went through getStorage(). That asymmetry is why it went unnoticed: the gallery looks healthy until a guest clicks the download button on one photo. Measured rather than assumed: because sendFile is called WITH a callback, Express does not send a response when the file is missing and the callback only logs. The request does not 404, it hangs until the client gives up. The new tests pin this — all five backend-path cases time out against the previous implementation. Two existing pieces do the work, so this mostly deletes code: - renderPhotoForDownload (#858) already owns resize-then-watermark ordering and the storage fetch, and the zip builders in this same file already use it. The inline duplicate of that logic goes. - the pass-through case branches on storage.kind(). Local disk keeps res.sendFile: it emits Content-Length, Accept-Ranges, ETag and Last-Modified and answers Range with a 206, and sharing one bare stream.pipe(res) with S3 would silently drop all of it — a resumed download would append a second full body onto the partial file. On S3 the parts that matter for a download are reproduced via stat() and getRange(). Ranges are parsed defensively; an unchecked parse yields NaN bounds and a 206 with a nonsense Content-Range, which corrupts a resumed download rather than failing it. Malformed or unsatisfiable ranges fall back to a 200. The pre-stream 404s now run before any image header is staged, so the error goes out as JSON instead of a .jpg attachment containing JSON. Co-authored-by: peipeimo <peipeimo@users.noreply.github.com> * fix(gallery): open the stream before staging download headers, honour If-Range Both from an external review round on this PR. stat() succeeding does not mean get() will — a concurrent delete or replace, or a transient backend error, lands between them. The fetch was awaited AFTER the headers went out, so: - the range branch had already called writeHead(206), leaving the outer catch nothing to do but throw ERR_HTTP_HEADERS_SENT. In practice the request hangs: the new regression test sat for the full 120s jest timeout against the previous code instead of returning. - the full branch would have sent its 500 JSON underneath the staged image/jpeg attachment headers — a .jpg file full of JSON, which is the exact failure this PR set out to stop doing on the 404 paths. Opening the stream first also lets a vanished object answer 404 and a transient failure answer 500, instead of both surfacing as a broken body. If-Range: emitting Last-Modified without honouring the validator built from it is the dangerous half of the feature. A client resuming after the object was replaced — the watcher re-importing a swapped file, an admin re-upload — would get 206 from the NEW bytes and splice two versions into one corrupt file. A validator that does not match now falls back to a full 200. 4 new tests; 3 of them fail against the previous commit, the fourth is the matching-validator control that must keep returning 206. * fix(gallery): HEAD without egress, classify render failures, stage 206 headers Round-2 findings from the external reviewer. Express routes HEAD through this GET handler and Node discards the body, but the pipe still drains the whole object out of S3 first — a metadata probe from a download manager cost a full transfer in egress and latency. Everything a HEAD needs is already in stat(). renderPhotoForDownload rejections were all reported as 404. It can equally fail because getToFile timed out, tmp filled up, or sharp died; calling that "photo not found" misleads the guest and hides the incident from us. Now classified the same way the pass-through branch already does. The 206 path uses status()+set() instead of writeHead(). writeHead commits the response immediately, so a stream that resolved and then errored before its first chunk left pipeStreamToResponse able only to destroy the connection. Staged headers flush on the first body write, so an error at byte zero now returns a clean retryable status with keep-alive intact. Credit to the reviewer for the correction — I had assumed deferring the commit required buffering. Writing the test for that surfaced one more: pipeStreamToResponse cleared Content-Type, Content-Length, ETag and Content-Disposition but not the range headers, so the 500 went out still advertising Content-Range: bytes 0-9/40 — telling a resuming client the error body IS the partial content. Not taken: binding response metadata to a fetched object version. That needs an ETag/versionId on the storage abstraction and conditional GETs in both adapters; the reviewer agreed it belongs in its own PR rather than blocking this one. Backend suites: 485 passed. * fix(gallery): answer HEAD before the counters and the render Round-3 finding. The HEAD short-circuit was inside the storage branch, which sits below both the download_count increment / access_logs insert and renderPhotoForDownload — so a download manager's metadata probe was recorded as a real download, and on a watermarked or resized gallery it also pulled the original from S3 and ran sharp over it to build a body Node then throws away. HEAD now leaves the handler right after the access checks, with no side effects and no bytes read. Content-Length is included only when the photo ships untransformed and the size is readable from stat(); a watermark or resize changes the length and the only way to learn the new one is to do the work this branch exists to avoid. HEAD may omit it. Not taken, again: binding the read to the statted object version. The reviewer already agreed in a follow-up that it needs an ETag/versionId on the storage abstraction plus conditional GETs in both adapters, and belongs in its own PR. Re-raising it does not change that. Tests assert the probe moves neither download_count nor access_logs. --------- Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local> Co-authored-by: peipeimo <peipeimo@users.noreply.github.com>	2026-09-01 08:17:32 +02:00
peipeimo	202c553a08	fix(events): delete stored objects when cascading an event delete (#1051) ... * fix(events): delete stored objects when cascading an event delete * fix(events): sweep watermarks and the archive zip on cascade delete too Two more objects in the same class as the originals: both are written through the storage backend, both were only ever removed with fs.unlink, so both outlive the event on S3. - photo.watermark_path — a canonical key, deleted via getStorage() on the single-photo path (watermarkService.deleteWatermarkFile) and on archive (archiveService.js:227). The cascade neither selected nor removed it. - event.archive_path — written by storage.putFromFile (archiveService.js:160) and typically the largest single object an event owns. event.hero_logo_path is deliberately NOT included: multer writes logos to local disk with diskStorage regardless of backend (adminEvents/logo.js:19-28), so they are never bucket objects and the existing fs.unlink is correct. Collect into a Set — an unresized gallery can carry one object in both hero_path and preview_path, and the second delete would log a spurious failure. * fix(events): sweep the download caches, and delete objects concurrently Both from an external review round on this PR. The download caches are the subtle case: the pre-built "Download All" zip (events.download_zip_path) and one zip per custom-resolution download job (download_jobs.zip_path) both live under events/active/{slug}/.download-cache/. On local disk the recursive fs.rm already covered them, which is exactly why they were easy to miss — on S3 that prefix is not a directory, nothing covered them, and both are gallery-sized. downloadZipService exposes a cleanup() documented as "used on event deletion" that the cascade never called. The job rows are read before the transaction for the same reason the photo rows are: download_jobs.event_id is ON DELETE CASCADE, so on Postgres they vanish with the event and take their keys with them. Guarded with hasTable so a pre-#173 install doesn't abort the delete. Deletes now run through a bounded pool instead of one await per key. A 400-photo gallery owns ~1600 objects once derived tiers are counted, and that many sequential DeleteObject round trips runs to minutes — long enough for a proxy to time the request out AFTER the commit, leaving the event deleted and the sweep half-finished. A pool rather than Promise.all over every key, so the fan-out can't exhaust the S3 client's connection pool. * fix(events): never delete a derivative another gallery still uses Round-2 findings from the external reviewer. Canonical thumbnail/hero/preview keys are not event-scoped: the basename is the photo's filename (imageProcessor passes no outputBasename for managed photos, so the key is thumbnails/thumb_w300_<filename>), and filenames are not unique across events — the responsive-tier code says so in as many words, which is why THOSE keys carry a p{id}_ prefix. A legacy gallery can therefore share a canonical derivative with a photo in another event, and deleting it here blanked a surviving gallery's tile. Derived keys are now checked against photos outside this event and anything still referenced is left alone; if the check itself fails, every derivative is kept. An orphan costs storage, a deleted derivative costs someone else's gallery. Originals need no check — their keys embed the slug. Also cancel any in-flight or debounced Download All build before snapshotting paths. A builder that started before the delete would otherwise upload a gallery-sized zip after the sweep and write its path onto a row that no longer exists, orphaning it permanently. downloadZipService.cleanup() is the service's own entry point for this and does all three things: bumps the version so an in-flight build discards its result, clears the debounce so nothing rebuilds for a deleted event, and removes the current object. * revert(events): drop the Download All build cancellation Reverted for the same reason as on the stable twin, where it was caught: downloadZipService.cleanup() reaches getStorage() through _cleanup(), so where the S3 backend is configured but unreachable every cascade delete pays the adapter's retry backoff. On stable that took the backend CI job from ~2 minutes to past its 10-minute budget, twice, reproducibly. This branch's suite happened not to trip it, but the same cost lands in the request path of a real delete — and the twins have to carry the same code. The race it addressed is narrow and costs one orphaned zip; documented as a follow-up instead. The shared-derivative guard from the same review round stays — that one prevented deleting a surviving gallery's thumbnail. --------- Co-authored-by: Peifu Mo <peipeimo@Peifus-MacBook-Pro.local> Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>	2026-09-01 08:17:04 +02:00
Paul Nothaft	bdeb5a2151	chore(main): release 3.121.4-beta.0 (#1249)	2026-09-01 06:10:24 +00:00
peipeimo	4f352dec39	fix(auth): treat zxcvbn suggestions as advice, not blocking errors (#1050) ... validatePassword() appended zxcvbn's feedback.suggestions to the errors array unconditionally, and validity is errors.length === 0 — so any password that merely earned a suggestion was rejected even when it satisfied every configured rule. The effective policy was stricter than the configured complexity level and invisible to the admin. Suggestions now surface only alongside a real strength failure. They stay available to callers in result.feedback.suggestions, so a UI can still show them as guidance while typing. The weak-password fixture is assembled from parts rather than inlined: an 8-char alphanumeric literal next to validatePassword( reads as a hardcoded credential to the required GitGuardian check. Both fixtures pin their zxcvbn score — the compliant one is load-bearing at exactly the moderate minimum (2), and a future zxcvbn bump promoting it to 3 would leave the test green while no longer covering the bug. Co-authored-by: Peifu Mo <peipeimo@users.noreply.github.com>	2026-09-01 08:05:42 +02:00
Paul Nothaft	c7ce79afb1	chore(main): release 3.121.3-beta.0 (#1242)	2026-08-30 15:07:47 +00:00
Marian	0d340f4e81	fix(archives): take the restored category from the manifest (#1240) ... * fix(archives): take the restored category from the manifest The archive writer already persists `category_name` per photo in photos_manifest.json — that is why the manifest exists, and the comment above it says so: "(and category linkage) can't be derived from the extracted files alone". The restore route then read only `original_filename` out of it and kept deriving the category from the ZIP's first path segment. Archives store photos exactly as they sit on disk, so an event whose photos live in the gallery root produces a FLAT zip. `path.dirname()` is '.' for every entry, no category is resolved, and every restored photo lands with `category_id = null` — silently, behind a 200. Seen on a real restore: 596 photos back, 0 with a category, while the nine category rows sat untouched in the table. Now the manifest is the source of truth and the first path segment is the fallback, so foldered archives and legacy archives without a manifest behave exactly as before. The find-or-create is pulled into `resolveCategoryId` so both paths share it and each name is resolved once per restore. Tests: __tests__/integration/adminArchives.restoreCategories.test.js builds real ZIPs (flat with manifest, flat with an existing category row, foldered without manifest) and drives POST /:id/restore. Without this change the two manifest cases fail and the foldered one passes — the fallback is unchanged. * fix(archives): let the manifest be authoritative when it says "no category" Review follow-up on #1240, pushed with the author's agreement. The manifest won for "category X" but not for "none": an entry with a null category_name fell through to the directory fallback, so a photo the archive recorded as uncategorized came back filed under a category anyway. That matters because the directory is not a category. Archive entry names are the storage key minus `events/active/{slug}`, and that layout is `individual/{filename}` / `collages/{filename}` — categories have never been directories there. Reading the first path segment on a real archive invents categories literally named "individual" and "collages", so the fallback was overriding an accurate record with a junk one. The fallback is now confined to photos with NO manifest entry at all: archives written before the manifest existed, where the directory is the only signal left and inventing those names still beats losing every category. Tests: the legacy case now uses `individual/`, the shape a real archive actually has, instead of a category-shaped folder no archive produces — so it documents what the fallback really does. Plus a new case pinning that a manifest saying uncategorized leaves the photo uncategorized and creates no category row. It fails without this change; the legacy fallback keeps passing. --------- Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>	2026-08-30 17:02:14 +02:00
Paul 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 <paul@MacStudio-von-Paul.local>	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 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 <paul@MacStudio-von-Paul.local>	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 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 <paul@MacStudio-von-Paul.local>	2026-08-29 12:15:31 +02:00
Paul 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 <paul@MacStudio-von-Paul.local>	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 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 <paul@MacStudio-von-Paul.local>	2026-08-29 11:10:05 +02:00
Paul 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 <paul@MacStudio-von-Paul.local>	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
Luca	8db8527f9e	feat(api): Lightroom round-trip — read proofing marks, put finished edits back (#745) (#1165) ... * feat(api): Lightroom round-trip — read marks, put edits back (#745) Gets a client's proofing verdict into a desktop catalogue and a finished edit back over its proof, without anyone re-matching files by hand. Three parts: **Keep the camera filename.** photos.original_filename is the only carrier of `IMG_1234.JPG` — the stored filename is rewritten by generatePhotoFilename. But replacePhoto() overwrites original_filename with whatever name the new file arrives under, so the first re-upload of a renamed render destroys the key the NEXT round-trip needs. Migration 185 adds photos.source_filename, written once at ingest and never touched by a replace, backfilled from original_filename so existing galleries can still match on their first pass. The backfill sits outside the column guard and keys on whereNull, so a run that dies partway self-heals instead of leaving half the rows empty forever. **Read the marks.** GET /api/v1/events/:id/photos returns each photo with its client colour tallies, the caller's own marks, and a merged colour + rating. Guards copied from the sibling upload route (apiTokenAuth + read scope + photos.view + requireEventOwnership). Filters: marked_only, mark_source, color_labels, my_color_labels, min_rating, my_min_rating. The route filters to a page of ids with PhotoFilterBuilder, then enriches just those through photoExportService.getPhotosWithFeedback — the two halves already existed and neither does both, and going id-first keeps the per-colour tally query bounded by page size. services/markMerge.js decides how three possible opinions (guest colours, guest star average, the photographer's own row in photo_admin_marks) collapse into the one colour and one rating Lightroom has room for. Colour goes to the photographer on a tie — one deliberate choice beats an aggregate a tie-break already had to guess at. Rating takes the max, because a rating is a magnitude and losing the higher one quietly demotes a photo somebody rated highly. Its roundRating matches XmpGenerator.mapRating exactly so the API and an XMP sidecar can never disagree about how many stars a photo has. **Put the edit back.** POST /api/v1/events/:id/photos accepts an optional replaces_photo_id and routes to the existing replacePhoto(), preserving the photo's id, feedback, comments and position. The plugin stores the picpeak id on the catalogue photo, so the id survives the editor renaming the render — which makes it the reliable key, not the filename. Scoped to the event in the URL: a token inherits its owner's powers across every event they can see, so an unscoped id would let one gallery overwrite another's photo. For renders whose RAW never went through the plugin, findReplacementCandidate gains an opt-in number_token mode matching on the trailing digit run. Deliberately the LONGEST run and never a fixed last-N slice: multi-camera shoots disambiguate by prefixing the camera index into the number (cam11234.jpg / cam21234.jpg), and a last-4 slice reads 1234 from both bodies and reintroduces exactly the collision the prefix removes. Ambiguity is refused, never guessed. Also drops the multer temp file on the two new early returns — this route only unlinks in its catch block. * refactor(api): one rating-rounding rule, and apply match_mode where it counts Three things the pre-review pass turned up on the round-trip work: - `match_mode` reached the photo-cap pre-count but not the loop that actually picks the replacement target, so asking for `number_token` would have been counted and then quietly ignored. Both call sites now take it. - `number_token` matching read `select('*')` over every photo in the event to compare one digit run. It now reads the three columns the match needs and re-reads the single winner in full, so a 5000-photo event doesn't pull 5000 full rows through memory to answer one question. - `XmpGenerator.mapRating` and `markMerge.roundRating` were the same five thresholds written twice — the second way to do one thing that drifts the moment either is touched. The thresholds now live in markMerge and the generator delegates, which is what keeps a sidecar and the v1 API from ever disagreeing about a photo's star count. * fix(api): keep the new route in the generated OpenAPI spec The `color_labels` description carried an inline JSON example. In an unquoted YAML scalar `{ "green": 2 }` parses as a flow mapping, so swagger-jsdoc threw YAMLSemanticError and dropped the WHOLE route from the spec — visible only as a warning on boot, with the route still serving normally, which is exactly the kind of failure that survives to release. Found by booting a real instance rather than by reading the diff. * fix(api): close the four blockers from review on #1165 1. Replacing an external photo silently kept serving the old file. resolvePhotoStorageKey gives photo.source_origin precedence and returns null for 'reference'/'external', so the edit was uploaded, the row updated and 200 returned while every viewer kept getting the untouched NAS original and the upload sat orphaned. replacePhoto now repoints the row to managed and clears external_relpath. The file on the share is never touched — this moves the pointer, not the data. 2. Every replacement leaked its temp file. putFromFile COPIES on local and uploads on S3; neither consumes the source, and replacePhoto never unlinked it — while the v1 route had disabled its own cleanup on the belief that replacePhoto moved the file. Cleanup now lives in replacePhoto, which closes the admin path too (adminPhotos only unlinks in its new-files branch, so replaced files leaked there as well). The v1 route also unlinks on the FAILURE path, which returned before any cleanup ran. 3. The download-all ZIP is invalidated after a replacement, as adminPhotos.js already does. Without it guests kept downloading the pre-edit photo indefinitely, which defeats the point of the feature. 4. The round-trip could not see reference or watcher galleries at all. fileWatcher and adminExternalMedia never set original_filename — the camera name lives in `filename` for those rows — so the backfill and the GET fallback both produced NULL for exactly the galleries most likely to be driven from Lightroom. The backfill now COALESCEs, both ingest paths set source_filename, and the GET falls back to filename. Concerns: - number_token no longer reads every photo row in the event per file. A LIKE on the digit run narrows the candidate set in SQL first; the exact trailing-run check still decides, so semantics are unchanged. The token is a regex-extracted digit run, so it cannot carry a wildcard. - The replacement's activity entry is scoped to event.id instead of null. The dashboard feed excludes NULL-event rows for scoped callers (GHSA-jhcf), so it was vanishing from the audit trail of the photographer who owns the event. Nit: dropped the unused higherPriorityColor export from markMerge. Three regression tests cover the external repoint, the temp cleanup and the COALESCE backfill. 21/21 pass. * chore(migrations): renumber 185 -> 193 after gallery-folders landed 185_add_category_is_folder.js merged to main while this was in review, so the number the PR reserved is taken and main is now at 192. Knex keys on filename rather than the prefix, so both would have run — but picpeakImportService guards restores with migrationOrder(), which parses that prefix, and two files answering 185 make the forward-only check pass a backup onto a schema missing its columns. Renumbered with every reference: the header comment, the test that requires the path, and the four call-site comments that cite it. The 'migration 182' reference inside it is the colour-labels migration and is unrelated; gallery.js:1134 cites upstream's 185 and is untouched. * fix(api): keep external_relpath when a replacement converts the row The external-photo blocker fix cleared external_relpath along with flipping source_origin, which closed one hole and opened another. adminExternalMedia dedupes a re-scan on (event_id, external_relpath) — routes/adminExternalMedia.js:195 — and migration 186 puts a unique index on exactly that pair. With the column nulled, the next scan of the share would not recognise the NAS original as already imported and would insert it again, so the gallery would end up holding both the edit and a fresh copy of the file it replaced. Only source_origin needs to change: it is what resolvePhotoStorageKey keys on, and every other consumer of external_relpath reads the two together and lets source_origin decide. The stale relpath on a managed row is inert for resolution and still correct as a dedupe key. Test updated to assert the value is kept rather than cleared. * fix(uploads): say when exiftool is missing instead of blaming the RAW A server without exiftool reported `No usable embedded preview in RAW file X.CR3: spawn exiftool ENOENT` for every RAW upload. The headline describes a corrupt photo; the actual cause is a package that was never installed, demoted to a trailing detail. It sends people hunting through their camera files. Hit while testing the Lightroom round-trip (#745): an export of RAW originals failed 11 times with that message, and the file was fine. RAW upload is the only feature that needs exiftool, so an install can be missing it indefinitely and only find out when someone uploads a CR3 — which makes the wording the whole diagnosis. ENOENT now produces a message naming the dependency and the install command for Debian/Alpine/macOS, and breaks out of the tag loop instead of spawning the same missing binary twice more to report the last failure as if it described the photo. A genuinely preview-less RAW still gets the original message. Verified both paths by making exiftool unreachable via PATH rather than mocking: missing tool and unreadable file now report differently. * fix(external): a delivered edit must win a relpath-fold collision Follow-up to keeping external_relpath on a replaced photo. Keeping it is what lets adminExternalMedia still dedupe the folder re-scan, but it also leaves the row inside externalRelpathFold's sweep — and that sweep does not merely rewrite paths, it DELETES collision losers via externalPhotoDedupe. The survivor was whichever row happened to be claimed first, which is iteration order. So a replaced photo — source_origin 'managed', holding the edit the photographer just delivered — could be deleted in favour of the untouched camera original sitting next to it on the share. Managed rows now claim first and therefore survive. The external row that loses is the recoverable one: it is still on the share and a re-scan re-imports it. The edit is not recoverable. Note this is deliberately NOT the "skip managed rows in the fold" shape suggested in review. Skipping would leave those rows holding a base-relative path while every other row moved to root-relative, so the scanner — which computes root-relative — would stop matching them and import the camera original again as a duplicate. That is the exact bug keeping external_relpath exists to prevent, reintroduced through a different door. Rebasing them and protecting them from deletion keeps both properties.	2026-08-28 15:45:56 +02:00