1206 Commits

Include renames

Author	SHA1	Message	Date
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	3acb452090	fix(settings): remove the duplicated section heading on 11 tabs ... A generic shell heading stacked on top of each tab component's own internal heading. The report named five tabs "at least"; auditing all 28 found 11: downloads, sso, apiTokens, webhooks, businessProfile, crm, accounting, whatsapp, slideshow, moderation, styling. On the first eight the two headings resolve to the identical string -- sso and businessProfile literally render the same key twice. The other three were near-identical stacked titles ("Moderation"/"Word Filters", "Custom CSS"/"Custom CSS Templates", "CRM behaviour"/"CRM settings"). Clean, and left alone: general, events, categories, thumbnails, security, seo, imageSecurity, status, analytics (its first heading is a genuine sub-section), plus the eight already in TABS_WITH_OWN_HEADER. Removed the component side and kept the shell heading: the shell heading is the consistent one (icon + label + divider on ~20 tabs) and always matches the nav item the admin clicked, and none of these components are mounted outside SettingsPage, so nothing loses a title. Subtitles and intro copy preserved throughout; orphaned icon imports removed. The guard test was checked against the pre-fix blobs and does fail on them. Refs testplan REPORT.md, "duplicate H2 section heading" warning.	2026-09-02 09:43:10 +02:00
Paul Nothaft	22cada9082	fix(ui): drop themed text colours from the last three admin surfaces ... SystemHealthPage, CrmOverviewSection and HoursSection used text-theme (color: var(--color-text)) explicitly, so on a dark-toned branding theme they render near-invisible on the light admin background -- and because the class is explicit it beats the AdminLayout default that protects everything else. Converted to the neutral scale using the convention from da9ceb14. Swept the whole of each file rather than the cited lines: 3 in SystemHealthPage, 5 in CrmOverviewSection (two of them h3 elements with no colour class at all), 17 in HoursSection. All three are admin-only -- call sites verified as AdminDashboard, CustomerDetailPage, HoursLoggingPage and /admin/system-health -- so no customer-portal or public-token surface is affected, where these utilities are correct by design. Zero themed utilities remain in the three files. Refs testplan REPORT.md B14.	2026-09-02 09:43:10 +02:00
Paul Nothaft	bd44708a03	fix(contracts): widen the block-library list column ... Block names ellipsized to ~4-6 characters ("Vertr...", "Bildr..."). The tooltip added earlier made them recoverable but the list still was not scannable. The file's "intentionally mirrors EmailConfigPage's Templates tab" comment was the reason the ratio was left alone. Re-evaluated: both pages render in the same Settings shell so the ratio is shared, but the content is not. A block tile spends a fixed ~105px of its row on the "System" badge plus the n/6 pill, and block names are long German noun phrases; EmailConfigPage's tiles carry one badge and short display names ("Gallery Created"). So the shared ratio is not simply wrong -- it is wrong here. Diverged only here: lg:grid-cols-3 / col-span-2 becomes lg:grid-cols-5 with a 2/3 split (40/60). Mobile stack untouched, and the comment now names the divergence and why. Refs testplan REPORT.md A5.	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	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	355fe4ff43	fix(email): give every template a real display name in the config UI ... D4 audit found defaultTemplateKeys was worse than stale sample data: - Only .name was ever read. The subject/body/variables triple on each entry was dead data -- and it is where {{password}} and {{expiration_date}} originated, neither of which exists in any shipped template (they are gallery_password and expiry_date). - It covered 4 keys out of ~40. A fresh install already carries 17 templates, and ~40 with the CRM flags on. Every key not in the list rendered its raw snake_case template_key as its display name in both the sidebar and the read-only "Template name" field -- customer_gallery_assigned, database_backup_completed, invoice_collections_handoff, all five event_reminder_*, and so on. Replaced with TEMPLATE_DISPLAY_NAMES covering every key from migrations/core/*.js plus the crm/contract/eventReminder template services, falling back to the raw key. Drops the now-orphaned password sample value. Adjacent drift found, not fixed (different const, and fixing it would be scope creep): eventReminderTemplates.js inserts with category 'crm' / subcategory 'event_reminder', neither of which is in CATEGORY_ORDER or CORE_SUBCATEGORY_ORDER, so all five reminder templates fall through the unknown-category fallback into core -> "other". They are visible, just filed in the wrong bucket. Refs testplan REPORT.md D4.	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	4c2eeab2f4	refactor(gallery): drop the unreachable Story feedback sheet ... StoryFeedbackSheet could never open: handleOpenFeedback was the only caller of setSelectedPhotoForFeedback and was itself never called. This was the last remaining build:check error (TS6133). Removed rather than wired up, on three findings: - The sheet offered nothing PhotoLightbox does not, and was strictly worse. It held comments and ratings in layout-local useState and never called feedbackService.getPhotoFeedback, so existing server-side feedback was invisible; it rendered stars and a comment form unconditionally, ignoring allow_ratings/allow_comments; and it had no reactions, colour labels, identity modal or rate-limit handling. This layout already renders PhotoLightbox with feedbackEnabled, which does all of that against the server. - It was not a mobile affordance. The CSS styled it as a fixed right-edge desktop drawer (right: 0; max-width: 28rem) with no media query. - Every sibling layout routes feedback through the lightbox. Grid, Masonry, Timeline, Mosaic and Carousel expose a per-card onQuickComment that calls onOpenPhotoWithFeedback to open the parent's lightbox on the feedback tab; none has a standalone feedback surface. The closest sibling, GalleryPremiumLayout, renders its own lightbox and deliberately voids _onOpenPhotoWithFeedback with no per-card control -- exactly the shape Story now has. Drops the component, its state and handlers, the feedbackOptions destructure (only the sheet read it) and 251 lines of orphaned CSS. savedIdentity also fed guest_name/guest_email into the like call; those were always undefined at runtime since the unreachable sheet was their only writer, so no behaviour changes. Also widens the Story nav search input, which clipped its placeholder. At the input's computed 14px the placeholder measures en 121px, de 145, ru 152, fr 174 against a 128px box -- so German was 17px over and French 46px over. 8rem -> 13rem collapsed, 12rem -> 17rem focused, keeping expand-on-focus; verified at 1280px and at the 768px breakpoint where the search appears. Refs testplan REPORT.md A1 and the gallery-story placeholder warning.	2026-09-02 09:43:10 +02:00
Paul Nothaft	72894e22c2	fix(gallery): stop browser zoom tripping the devtools viewport heuristic ... innerHeight is in page CSS pixels and shrinks under browser zoom; outerHeight does not. At 150-200% zoom a normal window therefore shows an absolute outer/inner gap of 400-500px, past every threshold, so an accessibility zoom read as a docked DevTools panel and - at protectionLevel "maximum" - redirected the guest off the gallery on load. Pre-existing (the previous threshold was 100px), but the rewrite kept the shape. The gap is now measured relative to a baseline taken at mount, and the baseline is re-taken whenever devicePixelRatio changes, which a zoom step does and a docked panel does not. Only a gap that grows past the threshold at a constant ratio counts. The mount-time check is dropped: a panel that is already open at load is indistinguishable from a zoomed window.	2026-09-02 09:33:34 +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	5dbb43549c	fix(i18n): make i18n:ci pass by fixing the extractor config ... exit 1 -> exit 0. Three findings, none of which matched the reported symptoms. 1. The two "unparseable .d.ts files" are not malformed. RestoreWizard.d.ts and BackupHistory.d.ts are valid declaration files sitting next to their .jsx implementations; i18next-cli feeds them to SWC as ordinary .ts modules with no ambient flag, where an uninitialised `const` is a hard syntax error. They should never have been scanned at all. Root cause is the input glob: i18next-cli passes `input` straight to `glob`, which does NOT honour `!`-prefixed negation inside the pattern list, so '!src/**/*.{test,spec,d}.{ts,tsx}' was a silent no-op and all four .d.ts files plus 57 test files were being scanned. Moved the exclusions to extract.ignore, where they take effect; the extracted key set is unchanged. 2. The "missing French keys" were not English-vs-French drift. The extractor wanted to add ~2771 keys to fr.json with value "" -- and src/i18n/config.ts does not set returnEmptyString, whose i18next default is true, so those empty strings would be returned as valid translations and render as blank UI rather than falling back to English. Filling nl/pt/ru/fr with ~11000 empty strings would have been a worse regression than the failing check. The check was demanding parity for locales this project deliberately keeps partial, so `locales` is now ['en','de'] -- the two actually kept at parity. nl/pt/ru/fr join sl/es as hand-maintained partial locales on fallbackLng 'en'. No French was written. 3. de.json is a parity locale, and the extractor legitimately found 307 keys missing from both en and de (shipped t() calls never added to the locale files). Rather than accept 307 blank German strings these were written by hand: 105 are _one/_other variants derived from existing German bases with correct singular/plural, the rest translated against each section's register (Sie on admin/public-billing surfaces, du in the customer portal to match customer.quotes/customer.bills) reusing terms already established in de.json. Verified: 0 interpolation-placeholder mismatches between en and de across all 308 new keys, 0 empty and 0 key-shaped values remaining, and the diff is strictly additive (en +308, de +307, 0 removed, 0 changed). removeUnusedKeys is now false, replacing the dead preservePatterns: []. It wanted to delete ~355 live keys per locale across ~90 prefixes -- families built at runtime (admin.activities.*, admin.notificationMessages.*, projects.status.*) or held in constant tables the extractor cannot resolve (AdminSidebar nameKey, CrmDevelopmentPage titleKey/descKey). Covering them would need ~30 wildcards spanning most of the key space; disabling pruning is the same behaviour, honestly stated, with the call sites named. Refs testplan REPORT.md #22 (Part 1.3.03).	2026-09-01 17:07:07 +02:00
Paul Nothaft	d16137bb2a	fix(contracts): add tooltips to the ellipsized block-library names ... The Blocks list column ellipsizes names to ~4-6 characters ("Vertr...", "Bildr...") with no title attribute, so the list is unscannable without clicking into each block. Add title on the name and description, plus min-w-0 so the name shrinks instead of pushing the badges out. Did not widen the column: the file carries an explicit design-intent comment that its two-column grid "intentionally mirrors EmailConfigPage's Templates tab", and changing the span would break that deliberate parity. The tooltip resolves the reported unscannability on its own. Refs testplan REPORT.md #21 (Part 8, S13).	2026-09-01 16:48:24 +02:00
Paul Nothaft	78b1ddd0db	fix(admin): interpolate activity and notification message values ... Users were shown raw "{{quoteNumber}}", "{{name}}" and "{{count}}" tokens. Two distinct render-side causes; nothing is persisted as a rendered string (messages are stored as type + metadata JSON and formatted client-side), so no backend change was needed. {{quoteNumber}} / {{name}} -- AdminDashboard's getActivityMessage built a hardcoded five-value allowlist (eventName, email, count, template, categoryName) and passed it to t('admin.activities.<type>'). The backend does record quoteNumber (quoteService.js) and name (adminWebhooks.js); the values just never reached i18next, so every activity string interpolating anything outside that allowlist rendered its literal token. Spread activity.metadata first, keeping the five derived entries as overrides since they resolve from columns that are not in metadata. Extracted as buildActivityParams for testability, mirroring the formatDayHeader extraction. {{count}} -- different cause, the notification-bell path: archiveBulk.js logs successfulCount, but the locale string expects count and bulk_archive_completed had no explicit case, so the default branch spread a metadata object without one. Added a case next to the existing bulk_delete_completed, following that idiom. Also fixes bulk_delete_completed, which has the identical mismatch: it reads metadata.deleted || metadata.count while archiveBulk.js writes successfulCount, so that notification always rendered "0 events deleted". It degrades to a wrong number rather than a visible placeholder, which is why it was not among the three reported instances -- but it is the same one-token bug. Refs testplan REPORT.md #15b.	2026-09-01 16:48:24 +02:00
Paul Nothaft	d8bd0cd449	i18n: close the admin translation coverage gaps ... Recurring pattern of components and strings shipped without translation coverage, found across unrelated feature areas. +212 keys each to en.json and de.json, provably additive (flattened-key diff: removed=0, changed=0; formatting round-trips byte-identically). Genuinely un-wired components (grep -c useTranslation == 0), now wired: BulkArchiveModal (8 strings, count-pluralised), WebhookDeliveriesPage (27), CMSEditor's TipTap toolbar/link dialog/status bar/help modal (64). Hardcoded strings fixed in code: ImageSecurityTab's 4 spinbutton hints, ProjectsListPage's unlocalized status enum. Keys-only (component already calls t() correctly): General "Time format", Branding Social Media + Promotional Banner, Quotes detail/editor, cms.showInFooter. Two corrections to the report's attribution: - BlockLibraryPage was NOT un-wired -- it calls t() on every string with English defaults; all 32 contracts.blocks.* keys were simply absent from both locale files, so everything fell back to the JSX default. Same for ContractsListPage, where the report cited 3 missing keys and there are actually 9 (all 5 table column headers plus the pagination line). - CustomerDetailPage has full t() coverage; its single English "Contracts" was a missing customer.nav.contracts key behind a dynamic labelKey. Locale convention followed: i18next.config.ts manages en/de/nl/pt/ru/fr, but only en and de are kept at parity (5198/5200 keys); the rest are ~50% partial and rely on fallbackLng 'en'. Added to en + de only rather than inventing 212x6 unreviewable translations. Also added the 25 missing businessProfile.* keys (PDF-letterhead section, bank-accounts QR disclaimer). That component already calls t(), so those strings localize as soon as the keys exist; no wiring needed. Refs testplan REPORT.md #15a.	2026-09-01 16:48:24 +02:00
Paul Nothaft	da9ceb14ca	fix(ui): stop branding-theme text colour rendering headings invisible ... Components that render headings with no explicit text-colour class inherit `body { color: var(--color-text) }`, and the branding theme sets --color-text on <html> app-wide -- so on a dark-toned theme they render near-invisible (#f5f5f5 on #fff), including inside the admin panel in light mode. Compliance-adjacent: /impressum and /datenschutz are two of the surfaces. Convention copied from AccountingTab, the QA control that is visually identical but not affected: h2 -> text-neutral-900 dark:text-neutral-100, labels -> neutral-700/300, checkbox labels -> neutral-800/200, hints -> neutral-500/400. Fixed beyond the reported lines, after sweeping each file: - LegalPage: the CMS prose wrapper and the single-segment 404 heading. - CMSContentBlock: the multi-segment CMS 404 and the admin unknown-route 404 turn out to be the same component (App.tsx path="*"; there is no admin-level catch-all). Its text already used var(--color-text); the actual defect was .card hardcoding bg-white under themed text, so the surface was fixed, not the text. - SettingsBusinessProfilePage (11), CrmSettingsPage (15, incl. both shared checkbox-label helpers covering ~20 rendered rows), ReminderTemplatesPage (7, incl. text-theme/text-muted-theme on an admin page where they are wrong). - The <select> elements on those tabs: Tailwind preflight sets color:inherit on form controls, so they picked up the near-white body colour on a white background. Same root cause, not previously reported. Plus one line of defence-in-depth on the admin shell (AdminLayout): an explicit text colour there stops the whole admin panel inheriting the themed body colour. Components with their own class, including text-theme, still win. Interpretation -- the robust fix was evaluated and rejected. Scoping the theme tokens to gallery contexts is not feasible: the leak is deliberate product behaviour (GlobalThemeProvider applies branding on every non-gallery page), 40 files read var(--color-*) with only 9 under components/gallery, and it would break the customer portal, the public token pages, AdminLoginPage and the Branding live preview. It also cannot be done at container level without moving `body { color: ... }` and the whole .text-theme/.bg-surface/.card-themed utility family, which are global by construction. Known remaining instances, not converted: SystemHealthPage, CrmOverviewSection and HoursSection use text-theme explicitly on admin surfaces, so they keep the themed colour and stay affected. Outside the reported surfaces. Refs testplan REPORT.md #14 (Part 8, S3/S4/S13).	2026-09-01 16:41:13 +02:00
Paul Nothaft	ac50f0b48b	fix(admin): portal the update-available modal to document.body ... AdminSidebar's root div carries a Tailwind `transform` utility for the mobile slide-in, and per the CSS spec a transformed ancestor becomes the containing block for position:fixed descendants. The modal renders inline inside VersionInfo/AdminSidebar, so its `fixed inset-0` backdrop was trapped in the 256px sidebar column (measured 256 vs window 1440) -- copy buttons overlapping text, content truncating. Reuse the codebase's one existing portal convention, from gallery/FeedbackLimitReachedModal: assign the JSX to a const and return createPortal(node, document.body). Checked for other modals with the same trap; there are none. UpdateInstructionsDialog is also fixed inset-0 but is mounted from AdminDashboard inside <main>, and CustomerLayout has an identical transformed aside with no modal inside it. Refs testplan REPORT.md #13 (Part 3, B.07).	2026-09-01 16:41:13 +02:00
Paul Nothaft	1be27404fa	fix(email): derive preview sample data from each template's variables ... The preview modal's hardcoded sampleData had drifted from the templates' declared variables arrays: it carried `password` and `expiration_date` and no `host_name` at all, so {{host_name}}, {{gallery_password}} and {{expiry_date}} rendered as literal placeholders in the gallery_created preview while event_name/event_date/gallery_link substituted fine. Derive the key set from the template's own `variables` instead, so nothing can be missing again. editedTemplate already carries the array at the call site, so no plumbing was needed. A small module-level lookup keeps sensible shapes for the ~11 variables where shape matters (dates look like dates, links like URLs), with a readable [name] fallback for anything uncurated -- curating all ~60 distinct variable names across the ~32 template seeds would just recreate the drift trap. Preview-only; real sent mail was never affected. Refs testplan REPORT.md #17 (Part 3, J.04).	2026-09-01 16:40:02 +02:00
Paul Nothaft	76a1453fa7	fix(calendar): don't put a fixed reference date in the month header ... dayHeaderContent assumed arg.date is always the real column date. It is in the time-grid views, but FullCalendar v6 fills it from an internal reference week (1970-01-04..10) for dayGridMonth headers, so the month header read a fixed "Mo 05.01. ... So 04.01." regardless of the visible month. Body dates were correct; only the header row was wrong. Interpretation (flagged as ambiguous): a month-view column header labels seven generic weekday columns shared by every week in the grid -- it has no single date, so forcing one in is wrong by construction rather than just mis-computed. Month view now renders the localized weekday alone, which is also FC's own default there; timeGridWeek keeps weekday + DD.MM. since each column really is one date. Branches on view.type === 'dayGridMonth' exactly, not a dayGrid prefix: dayGridWeek/dayGridDay do have real per-column dates and a prefix match would break them if either is ever added. Extracted to an exported formatDayHeader so it is testable without mounting the page; the test mounts a real FullCalendar in both views, so an upgrade that changes the arg.date contract fails rather than silently regresses. FullCalendar dependency untouched. Refs testplan REPORT.md #10 (Part 8, S9).	2026-09-01 16:31:09 +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	18715b5efd	fix(gallery): show a guest's own upload without a hard reload ... Correction to the QA root cause: the 304 is correct server behaviour, not a stale cache. The guest upload route answers 202 and queues the file, so the row lands as processing_status 'pending', and the photos list returns only completed rows. The immediate post-upload refetch therefore produces a byte-identical payload, express's body-derived weak ETag matches, and the browser is answered 304. Cache-busting would not have fixed it -- a busted request 200ms after the upload returns a 200 whose body still lacks the photo. The hard reload only worked because it happened seconds later. Poll instead: refetch immediately and every 2s until the photo count exceeds the pre-upload baseline, with a 60s deadline and cleanup on unmount. This also replaces two window.location.reload() callbacks, which could not have waited for the worker anyway and threw away scroll and folder state. Not done (out of scope, recommended follow-ups): GET /api/gallery/:slug/photos sets no cache headers at all for private per-guest data and relies on heuristic freshness -- noStoreCache.js already exists and would fit. And the guest upload flow has no progress signal, so the UI polls blind where a processing-status endpoint (or pending counts in the photos payload) would let it say "processing...". Refs testplan REPORT.md #12 (Part 4, P4-E.01).	2026-09-01 16:30:06 +02:00
Paul Nothaft	9d4bd7ab30	fix(gallery): stop devtools protection from breaking the whole page ... With enable_devtools_protection on, every click on the gallery failed and trivial script evaluation hung -- confirmed on two independent events. A guest with DevTools open for an unrelated reason (network tab, a CDP-attaching extension) got a silently unresponsive gallery with no error shown. Mechanisms found, all in the hook (both callsites were innocent): 1. detectByDebugger ran a bare `debugger;` on every tick at medium/high sensitivity -- and the per-event flag maps to medium. With any debugger or CDP client attached the renderer paused there continuously. This is why Runtime.evaluate hung on 1+1 and clicks reported their target gone. 2. Four separate detectors called console.clear() -- the observed clear loop. 3. handleDevToolsDetected was useCallback([options]) over a fresh object literal, so runDetection changed identity every render and the effect tore down, rebound and re-ran detection on every render -- a 1s interval turned into a tight loop. 4. detectByConsole monkey-patched console.log/error/warn/info every tick inside a try/catch that swallowed throws, so a throw between patch and restore left the guest's console permanently hijacked. 5. contextmenu was preventDefault'd document-wide regardless of target, killing the menu on text, links and form fields -- disable_right_click is the separate setting meant to cover the whole page. Kept: the DevTools shortcut keys (only those exact combos; everything else passes through), the docked-DevTools viewport heuristic as a pure measurement on resize plus one check at mount, right-click blocked on IMG/CANVAS/VIDEO targets only. The public API (onDevToolsDetected, redirectOnDetection, redirectUrl, isDetected, reset) is unchanged, so PhotoLightbox needed no edit. Removed: debugger traps, console.clear, console monkey-patching, the timing/element/toString probes, the polling interval, document-wide contextmenu blocking. Undocked DevTools is now deliberately undetectable -- every technique that catches it costs the page its responsiveness for everyone. This is a deterrent, not a security boundary. Also raised the viewport threshold (100 -> 160/200/260 by sensitivity): browser chrome with a bookmarks bar is ~140px, so the old check false-positived on ordinary windows, which at protectionLevel 'maximum' redirected legitimate guests off the gallery. Refs testplan REPORT.md #3 (Part 4).	2026-09-01 16:30:06 +02:00
Paul Nothaft	c6cb01865e	fix(settings): derive the sidebar preview from the real sidebar declaration ... SidebarPreview kept its own hand-maintained 6-item array with only two gates wired (analytics, userManagement), so toggling e.g. Workflows changed nothing in the preview even though it does add a real sidebar entry once saved. Export AdminSidebar's `navigation` as `adminNavigation` (2 lines) and derive the preview from it, so every gate -- transfers, messaging, analytics, userManagement, clients incl. its featureFlagsAny set, accounting, workflows -- is covered and the two can't drift again. Note the report's item list was partly wrong: Quotes, Contracts, Invoices, Hours, Projects, Calendar and the CRM dev tools have no top-level sidebar entries at all -- they are sub-nav inside /admin/clients and surface in the preview through the CRM entry's featureFlagsAny. Permission filtering is deliberately not applied (unchanged): the preview answers "what do these flags do to the sidebar", not "what can this admin see". Refs testplan REPORT.md #20 (Part 3, J.14).	2026-09-01 16:29:33 +02:00
Paul Nothaft	3e16b81be8	fix(settings): clear the accounting flag when its parent is turned off ... Turning Invoices off left the Accounting master flag -- and its sidebar entry -- silently on and freshly unlocked, because the bills=true => accounting=true force-enable had no reverse. A dependency model already exists and handles every true parent->child pair (quotes->bills, calendar->calendarBooking, accounting->{taxReport, incomingInvoices,expenses}), mirrored client-side in applyDependencyRules and server-side in adminFeatureFlags.js. The gap is only this asymmetric rule. Interpretation, two decisions: - Cascade on the client at toggle time, not on the server at persist time. applyDependencyRules is a pure invariant over a single state (the GET handler runs it too), so it structurally cannot distinguish "accounting is on because the admin wants it" from "...because bills forced it". The Features tab PUTs the full flag set, so on the wire an explicit true and a stale forced true are byte-identical -- a server-side transition rule would silently discard an admin who turns Invoices off and deliberately keeps Accounting on in the same save. The client is where the gesture is known. The persisted result is still server-enforced: the client sends accounting:false and the existing server invariant forces the sub-flags off. - Re-enabling the parent does NOT restore children. Flags are state, not history, and silently re-lighting a sub-feature with its routes and sidebar entries is the exact failure this bug is about. Refs testplan REPORT.md #8 (Part 8, S9).	2026-09-01 16:29:33 +02:00
Paul Nothaft	3790156fc9	fix(accounting): let "bill to a customer" work with the portal off ... CustomerAccountPicker returns null when customerPortal is off. That is right for its original use -- the event form assigns portal logins that bypass the gallery password -- but the Accounting flows reuse it as-is, so their required "Client" field rendered a bare label with no input and the submit button could never enable, with no explanation. Accounting-on + CRM-off is a valid, UI-supported flag combination. Took option (a): the bill-to-customer path does not depend on the portal. POST /admin/expenses/:id/invoice is gated by requireExpenses + accounting.manage only, and /admin/customers{,/search} are permission-gated rather than flag-gated -- POST /admin/customers exists precisely to create passive, portal-less customers "to attach a quote / invoice / gallery to". The un-gated CustomerPicker used by the quote/bill/contract editors is the precedent. (The comment claiming search 410s with the flag off was stale.) Add portalAssignment (default true) so the gate and the portal-specific label/help text apply only in event-assignment mode; the accounting call sites render their own label. Event-form behaviour is unchanged. Also fixes AccountingInboxPage's TriageModal, which has the identical label-only failure on the rebill disposition from the same root cause -- outside the reported surface, but leaving it would half-fix the bug. Refs testplan REPORT.md #7 (Part 8, S10).	2026-09-01 16:29:33 +02:00
Paul Nothaft	31ffbc8ae4	fix(users): give the cancel-invitation dialog a distinct confirm label ... The cancelInvitation dialog type fell through to the generic t('userManagement.cancel'), colliding with ConfirmDialog's own dismiss button -- two buttons both reading "Cancel", where clicking the wrong one does the opposite of what the user intends. Reuse the existing userManagement.cancelInvitation key: "Cancel Invitation" vs "Cancel" (EN), "Einladung abbrechen" vs "Abbrechen" (DE). No new key. Refs testplan REPORT.md #19 (Part 3, I.04).	2026-09-01 16:28:31 +02:00
Paul Nothaft	c19e944b99	fix(events): guard create-event submit against re-entrant submissions ... Correction to the QA root cause: the submit Button has carried `disabled={createMutation.isPending}` since 3424bd22, and it does disable synchronously after the first click (validateForm's setErrors forces a re-render that re-reads the mutation snapshot), so an ordinary double-click could not by itself produce two POSTs. What was actually missing is a re-entrancy guard in handleSubmit, so any submission that never touches the button -- implicit form submission, a programmatic requestSubmit, or two submit events dispatched in one task, which is the likely shape of the QA repro -- still fired two mutate() calls racing the same computed slug, one of which 500'd on events_slug_unique. Add isSubmittingRef (matching the isMountedRef idiom already in this file), cleared in onSettled. Test proves 2 submit events -> 1 POST. Not done: turning the backend's raw 500 on events_slug_unique into a graceful "event already exists" 409. That is an adminEvents.js change and a separate concern from the client-side race. Refs testplan REPORT.md #6 (Part 7.03).	2026-09-01 16:28:31 +02:00
Paul Nothaft	673f05556d	fix(settings): don't crash on a fresh load before permissions resolve ... On a hard navigation or deep link, usePermissions() starts out empty, which filters every settings nav group down to nothing. allItems is then [], so `allItems.find(...) ?? allItems[0]` yields undefined and `<activeItem.icon>` threw -- sometimes into the error boundary, sometimes racing past it. Reproduced 6+ times across the webhooks/moderation/slideshow/security/events tabs; in-app SPA navigation never hit it. Extend the file's existing early-return to `isLoading || permissionsLoading`. activeTab lives in useState seeded from ?tab= at mount, independent of the gate, so deep links still land on the right tab once permissions arrive. Also null-guard activeItem before the section heading: a role holding zero settings-tab permissions crashes identically even after permissions finish loading, which the loading gate alone does not cover. Refs testplan REPORT.md #11 (Part 3, J.08).	2026-09-01 16:28:21 +02:00
Paul Nothaft	c2428aa23a	fix(events): render a not-found state instead of hanging on a 404 ... EventDetailsPage gated on `if (eventLoading || !event)`. The backend returns a clean 404 for a nonexistent id, but once isLoading settled false `event` stayed undefined forever, so /admin/events/999999 sat on the loading spinner permanently with no error state. Destructure isError and split the gate: spinner while loading, then a not-found Card. Reuses the existing `events.notFound` key (already used by EventFeedbackPage for the same entity) and the Card padding="lg" not-found shape from contracts/ContractDetailPage. No new i18n keys. Refs testplan REPORT.md #5 (Part 7.02).	2026-09-01 16:28:21 +02:00
Paul Nothaft	3489610cb8	fix(analytics): warn about the CSP allowlist on every tracker provider ... A self-hosted Umami/Rybbit domain configured in Settings -> Analytics is always blocked by the static script-src allowlist, silently, with only a console error. The amber CSP warning that explains this already existed but was rendered only inside the "custom" provider panel -- not on the two providers where an admin actually types a self-hosted URL. Extract it to a local CspWarning and render it in the Umami and Rybbit panels too. Both translation keys already exist in en.json/de.json. Interpretation: the dynamic-CSP option was investigated and rejected as not reachable for the header that actually governs these documents. In the Docker deployment nginx.conf:58 does `proxy_hide_header Content-Security-Policy`, so helmet's CSP and the res.setHeader CSP at server.js:445 are stripped before they leave the stack -- nginx's static server-level CSP is the only one the browser sees for the SPA documents the tracker is injected into. nginx.conf is COPYied verbatim by the Dockerfile (only index.html goes through envsubst), and the tracker URL lives in the DB rather than the environment, so making it reflect the setting would need start-time templating plus a DB read. The CSP itself therefore still has to be edited by hand; the warning now says so where the admin can see it. Refs testplan REPORT.md #18 (Part 3, B.02).	2026-09-01 16:23:40 +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	884580d849	chore(main): release 3.122.2-beta.0 (#1258)	2026-09-01 07:30:45 +00:00
3 people	66989d70f1	fix(upload): let Android guests reach the camera without breaking video (#1244) ... * fix(upload): let Android guests reach the camera without breaking video Recent Android versions route an <input> whose accept list is entirely image/video types to the system photo picker, which has no camera entry — so a guest standing at the event can only pick an existing photo, not take one. Including a type that picker can't handle forces the general chooser, which does offer the camera. Two corrections to the original approach in #1117: - the .pdf is gated on the Android UA. It was appended unconditionally, so desktop and iOS pickers — which behave correctly — gained a selectable PDF that only produces an error when chosen. - no image-only guard. #1117 rejected every non-image file before the existing allowlist check, which breaks video uploads outright on any install configured for them (fileTypes.ts maps mp4/m4v/webm/mov/avi and general_allowed_file_types is admin-editable). The guard was also redundant: extensionsToMimeTypes only emits types it has a mapping for, so application/pdf can never be in allowedMimeTypes and the existing "Invalid file type" check already rejects a picked PDF. The empty-string fallback to 'image/*, .pdf' goes too — extensionsToMimeTypes already falls back to the configured default set, and image/* was broader than the admin's allowlist. Lives in fileTypes.ts as a pure function so the UA behaviour is testable; the component keeps a one-line useMemo. Co-authored-by: Zszywany <[email protected]> * fix(upload): use android/allowCamera instead of .pdf for the chooser fallback Same mechanism, better token. Chrome on Android 14/15 sends an input whose accept list is all media types to the photo picker, which has no camera tile; adding a value that picker cannot satisfy makes it fall back to the general chooser, which does offer the camera. `.pdf` achieves that but advertises PDFs as selectable — pick one and the existing allowlist check answers "Invalid file type", which is a dead end we put in front of the guest ourselves. `android/allowCamera` is the token the workaround converged on: not a real MIME type, matches no file, so it flips the picker without offering anything. Neither token ever widened what is accepted — addFiles validates against extensionsToMimeTypes, which only emits types it has a mapping for — but not showing the guest a choice that cannot work is worth the one-line change. Verified in a browser rather than asserted: the real component rendered under an Android UA emits image/jpeg,image/png,image/webp,android/allowCamera and under a desktop UA image/jpeg,image/png,image/webp with the visible modal identical in both, and the format hint still reading "JPG, JPEG, PNG, WEBP" — the token does not leak into anything a guest sees. * fix(upload): keep the camera token off Firefox for Android External review round. The gate was a bare /Android/i, which Firefox for Android matches — so it received a token invented to reroute Chromium's photo picker, a picker it does not use. The doc comment two lines up already said Firefox behaves correctly; the code did not agree with it. Inert at best, and at worst it perturbs a chooser that was working. Narrowed to Android minus Firefox, which is the Chromium-family set the behaviour was actually observed on (Chrome and Edge, Android 14/15), with a UA test to pin it. --------- Co-authored-by: Paul Nothaft <[email protected]> Co-authored-by: Zszywany <[email protected]>	2026-09-01 09:24:24 +02:00
Paul Nothaft	7e6bfbecb2	chore(main): release 3.122.1-beta.0 (#1254)	2026-09-01 06:35:22 +00:00
Paul Nothaft	63f3fb4629	chore(main): release 3.122.0-beta.0 (#1251)	2026-09-01 06:27:11 +00:00
Paul NothaftandPaul Nothaft	1ef2b3c85b	feat(events): publish without notifying, and send the gallery email later (#1235) (#1241) ... * feat(events): publish without notifying, and send the gallery email later (#1235) Publishing queued the gallery_created email whenever any customer email existed, with no opt-out. A photographer working with a client who has no address yet — the Instagram-team case in discussion #1086 — had to type their OWN address into the required field, publish, receive the client-facing email themselves, and hand the link over by DM. Turning off `event_require_customer_email` is not the answer either: that is global, and the same photographer usually does collect addresses. Two halves, because a checkbox alone is only half a workflow: - `notify_customer` on publish, default TRUE. Absent means notify, so the v1 API, an older frontend and any script keep behaving exactly as before. When false the gallery goes live and nothing is queued — not the gallery_created email, not the assigned-customer-account notice, not WhatsApp. Publishing still logs activity and still fires the event.published webhook, because those describe a state change rather than a message to a customer. - POST /:id/send-gallery-email for an already-published gallery. Deliberately not restricted to galleries published quietly: re-sending is a normal thing to want (spam folder, wrong address since corrected) and refusing would push people to unpublish and republish, changing gallery state to work around a mail problem. Refused for a draft, whose link would not work yet, and for an event with no recipient. The email composition is now one helper shared by both, so an email sent a week later is identical to one sent at publish. UI: a checkbox in the publish dialog (checked by default, hidden when nobody would be notified anyway), and a "Send gallery email" action on published galleries that have a recipient. The password field follows the checkbox — unchecking it means nothing is being sent, so there is no plaintext to carry and no reason to demand it. EN + DE strings. 7 integration tests. Two fail without the change, verified by forcing notifyCustomer true and re-running; the rest pin the default, the draft and no-recipient refusals, and that a gallery with no recipient still publishes. * fix(events): make the publish dialog description follow the checkbox (#1235) Caught by screenshotting it. With "Send the gallery email now" unchecked, the paragraph above still read "...and sends the notification email to [email protected]" while the control directly beneath it said nothing would be sent — the dialog contradicted itself at exactly the moment the admin is deciding whether anything goes out. It now reads "No email will be sent — you can send it later from this page." when the box is clear. EN + DE. * fix(events): close six gaps in publish-quietly found by external review (#1235) TWO CORRECTIONS TO MY OWN VERIFICATION FIRST. `npx tsc --noEmit` in frontend/ is a NO-OP — the root tsconfig is solution-style with references and no include, so it checks nothing. Every "tsc clean" I claimed on this branch came from that. The real check, `tsc -p tsconfig.app.json`, showed two TS2339s I had introduced: `event.host_email` does not exist on the frontend Event type, which the admin API normalises away. Both recipient checks now use `customer_email`. PASSWORD ON SEND-LATER. The action promised to send the link and password but always called the endpoint without one, so a protected gallery got the "(set at creation)" sentinel — unusable — and this is most needed right after a quiet publish, the path that never collects a password. New SendGalleryEmailDialog asks for it, same shape and reasoning as the publish dialog (#627). Galleries with no password skip the field. WHATSAPP-ONLY GALLERIES COULD NOT PUBLISH QUIETLY. willNotify ignored customer_phone, so a phone-only gallery hid the opt-out AND told the admin nothing would be sent — while publish queued the WhatsApp anyway. Phone now counts, with its own description line. ASSIGNED-ACCOUNT NOTICES COULD NOT BE SENT LATER. The dialog promised it; the endpoint rejected anything without an inline recipient. It now falls through to the same customer-account path publish uses. EDITORS COULD NOT SEE THE ACTION. The send button was nested inside the events.archive gate, so the default editor role — events.edit, no archive — never saw a button for an endpoint it is allowed to call. Separate gates now. DEAD LINKS. The endpoint only checked is_draft, so an archived, inactive or expired gallery would send a link the gallery middleware rejects. All three are refused with a reason. 9 backend tests (2 new), 22 across the event suites. eslint clean on every changed frontend file; crud.js keeps its 2 pre-existing errors. * fix(events): persist the send-later password, and fix a long-standing isGalleryPublic misuse (#1235) Round 2 of external review. THE EMAIL COULD CARRY A PASSWORD THE GALLERY REJECTS. The send-later dialog invites "or pick a new one", but the route queued that plaintext without touching password_hash — so the customer got credentials that do not open the gallery. Worse than the sentinel it replaced, because it looks usable. The route now hashes and persists first, exactly as publish does. isGalleryPublic TAKES A VALUE, NOT AN EVENT — and this is pre-existing. normalizeRequirePassword returns its default for anything that is not a boolean/number/string, so isGalleryPublic(event) is ALWAYS false and `requirePassword` was always true. The publish dialog on main has demanded a password for public galleries for exactly this reason. Both call sites now pass event.require_password. Fixing the older one alongside mine rather than leaving a broken copy one line above a fixed one. ASSIGNED-ACCOUNT GALLERIES HAD NO BUTTON. The route falls through to the customer-account notice when there is no inline email, and the publish dialog promises that notice can be sent later — but the button only appeared with a customer_email, making the promise unkeepable. WHATSAPP CLAIM SOFTENED. Publish only queues WhatsApp when the config exists and is enabled, which the dialog cannot see. It now says the customer is notified there "if WhatsApp is configured" rather than asserting a send. 10 backend tests (1 new, covering the rehash). eslint clean on every changed frontend file; crud.js keeps its 2 pre-existing errors. * fix(events): don't reset the password for an account-only notice, hide unusable actions (#1235) Round 3 of external review. The first is a harm my own round-2 fix introduced. PASSWORD RESET FOR NOTHING. Round 2 persisted the supplied password before knowing which mail would go out. For a protected gallery with no inline email but assigned accounts, the dialog still demands a password, the hash was rewritten, and then the fallback sent customer_gallery_assigned — which links to the customer portal and never mentions a password. Net effect: the live gallery password silently changed and everyone holding the old one was locked out, in exchange for nothing. It is now persisted only when the mail that carries it is actually being sent. BUTTONS THE BACKEND WOULD REFUSE. The send action rendered for expired and inactive galleries, and counted assigned accounts the endpoint filters out as inactive — walking the admin through a dialog to reach a generic error toast. The card now mirrors the endpoint's eligibility rules, and only active accounts count toward having a recipient. 11 backend tests (1 new, pinning that the hash is untouched on the account path), 24 across the event suites. tsc and eslint clean on the changed files. * fix(events): make the send-later action agree with what the endpoint will do Three findings from an external review round, all the same shape: the UI predicted the endpoint's behaviour and got it wrong. GET /admin/events/:id mapped customer_accounts without is_active, so the "only ACTIVE accounts count" filter in OverviewTab compared undefined and excluded nothing. A gallery whose only assignments were deactivated showed the send action, and the endpoint then filtered every recipient and returned 400. is_active is exposed now, and the count applies the same predicate the fallback uses — active AND holding an address. is_active is coerced through toBoolean rather than compared with === false. On the default SQLite backend it comes back as 0, and 0 === false is false, so an inactive gallery kept offering a send that parseBooleanInput then rejected. Same class as #1028. The password prompt is gated on there being an inline recipient. With no customer_email the backend takes the account fallback, which sends customer_gallery_assigned — a portal link that never mentions a password — and deliberately skips the rehash. Asking for one there blocked the send behind a six-character value nothing consumes, and the dialog's promise that it would be rehashed was false. Frontend suite: 291 passed. tsc and eslint clean. * fix(events): don't mail a portal link to a customer who cannot sign in Round-2 finding from the external review. A passive customer — created directly and never invited — is an active account with a real address whose password_hash IS NULL. The account fallback happily mailed it customer_gallery_assigned, which links to /customer/dashboard, and customerAuth rejects login without a hash: the link goes to a door that will not open. Worse than failing, the route counted it and reported success, so the admin believed the customer had been told. getAssignmentsForEvent now derives can_sign_in (the predicate, never the hash) and the three call sites share one canReceiveGalleryNotice helper — publish, send-later, and the payload the UI predicts from all have to agree or the button appears and then 400s. The UI mirrors it. Sending passive customers an invitation instead of skipping them is the better product answer, and a separate feature. Refusing visibly beats a silent non-delivery in the meantime. Test asserts the refusal; it fails without the can_sign_in arm. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-09-01 08:18:00 +02:00
Paul Nothaft	bdeb5a2151	chore(main): release 3.121.4-beta.0 (#1249)	2026-09-01 06:10:24 +00:00
Paul Nothaft	c7ce79afb1	chore(main): release 3.121.3-beta.0 (#1242)	2026-08-30 15:07:47 +00:00
Paul Nothaft	89e8e41c40	chore(main): release 3.121.2-beta.0 (#1238)	2026-08-29 10:27:50 +00:00
Paul Nothaft	064b1bcb14	chore(main): release 3.121.1-beta.0 (#1236)	2026-08-29 10:21:22 +00:00
Paul Nothaft	25a7e64951	chore(main): release 3.121.0-beta.0 (#1232)	2026-08-29 09:16:49 +00:00
Paul Nothaft	a8a8b7cc64	chore(main): release 3.120.0-beta.0 (#1227)	2026-08-28 13:50:35 +00:00
Paul Nothaft	1d88fa01ce	chore(main): release 3.119.0-beta.0 (#1223)	2026-08-28 06:41:39 +00:00
Paul NothaftandPaul Nothaft	1f3f7e9c02	fix(gallery): make the returning-guest recovery findable (#1210) (#1217) ... * fix(gallery): make the returning-guest recovery findable (#1210) A guest who fills the registration form in again becomes a second gallery_guests row, and their earlier likes and favourites stop counting as theirs. Recovery has always existed to prevent exactly that — as a small link under the submit button, which people reasonably read as fine print and skipped, so duplicates kept accumulating even for guests who had given an email the first time and were eligible for it. Given its own block below a divider, and worded around what the guest loses by missing it: 'Been here before? Your earlier picks are still saved.' rather than 'I've been here before', which reads as a greeting rather than a reason to stop. The affordance itself becomes 'Get them back'. Still a choice the guest makes, not a check the server runs. Looking up whether the typed address is already registered would answer 'is this person in this gallery' to anyone who asked — which is why /guest/recover always returns 200 and cannot be used that way. The alreadyHere key is retired rather than reworded: a key by that name holding 'Get them back' would mislead the next translator. Both new strings are in all seven locales that carried the old one. Three tests: the hint is present, the affordance routes into recovery rather than registering, and an ordinary first-time registration is unchanged. * fix(i18n): match the German formality in the returning-guest hint (#1210) The dialog addresses the guest as Sie throughout — "Willkommen — wie heißen Sie?", "Ihre Auswahl wird unter diesem Namen gespeichert" — and the new line came out in du. Mixing the two in one modal reads as sloppy to a German speaker. Caught by looking at the rendered dialog rather than the string, which is the argument for screenshotting a copy change at all. * fix(gallery): theme tokens for the recovery block, formal register in nl (#1210) External review of #1217. **The dark variant never fires in a gallery.** A dark gallery preset is delivered through CSS variables; ThemeProvider does not add Tailwind's .dark class. So `text-neutral-600 dark:text-neutral-400` on a dark surface stayed dark grey on dark, and the divider stayed light. My block was the only place in this modal using neutral-* classes at all — the rest already uses text-theme and text-muted-theme for exactly this reason. The divider now takes --color-surface-border, which is the token index.css actually defines. **Dutch had the same mixed register German did.** The dialog says uw/u throughout — 'wat is uw naam?', 'Uw selecties worden opgeslagen' — and the new hint came out with 'Je'. Same slip, same fix, found the same way. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-28 08:33:12 +02:00
Paul NothaftandPaul Nothaft	f18bc568c8	feat(admin): shift-click range selection in the photo grid (#1212) (#1213) ... * feat(admin): shift-click range selection in the photo grid (#1212) Selecting photos was one tile at a time. Select All is all-or-one, so 're-assign these two hundred' meant two hundred clicks — which is how #1209 ran into it, re-categorising a large imported set. Shift-click now selects the span from the last plain click to the tile under the cursor, the way a file manager does. It extends the selection rather than replacing it: the grid already lets you accumulate tiles one at a time, so a range is another addition to that set. And it only ever adds — deselecting by dragging a range back over itself is a different gesture, and guessing at it would let a mis-aimed shift-click destroy a selection instead of growing it. The anchor stays put across repeated shift-clicks, so the second one re-aims the same span from the original point instead of walking along behind the cursor. The anchor carries the id of the tile it was set on, not just the index. An index means a different photo after a filter or a re-sort, and a range measured from a stale anchor would select the wrong span with nothing to show for it; the write checks the anchor still points where it was set and falls back to a plain toggle when it does not. Validating at use rather than clearing on every list change means a background refetch, which hands back an equal list, leaves the anchor usable. Seven tests, four of which fail without the change; the other three pin the plain-click and no-anchor behaviour that must not move. * fix(admin): clear the range anchor whenever the selection is cleared (#1212) External review. Cancel Selection, Deselect All and a successful bulk move or delete all emptied selectedPhotos and left the anchor behind. The anchor is invisible, and the list is usually unchanged, so it stayed valid — the next shift-click reached back into a selection session the user had already ended and selected a range they never started. Cleared at all four reset points now. Test fails against the un-fixed code. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-28 08:27:46 +02:00
Paul NothaftandPaul Nothaft	5c85e0c0e4	fix(guests): surface duplicate guest registrations, and stop making so many (#1210) (#1216) ... * fix(guests): surface duplicate guest registrations, and stop making so many (#1210) Guest registration always inserts. A client whose token expired — or who opens the gallery on a second device — becomes a new gallery_guests row, and their likes and favourites split across the copies. The photographer's 'final selection' is then only trustworthy if somebody notices two Tinas with half the picks each. Two halves, neither of which touches the registration path. **Say which rows are the same person.** Merging already worked, endpoint and UI both; nothing said WHICH rows to merge. The guests list now marks each row with the others sharing its email and returns a count for the banner, and the admin list offers the group straight to the merge mode that already exists. Case-folded and trimmed, because the same person types Tina@ one day and tina@ the next and both read as distinct rows. Email only — two guests called Anna are not evidence of anything, and rows without an email are not grouped at all since require_name_email is off by default and a shared link produces plenty of them. It preselects rather than merges: which row survives decides the name and verification state the merged guest keeps, and that is the admin's call. **Create fewer of them.** The guest token was 24h and every call site took that default, so even the same browser lost its identity after a day of inactivity. Now 30 days, GUEST_TOKEN_TTL to override. A guest token is scoped to one event, carries no admin capability, and the gallery is already behind whatever protects it — 30 days is the shape of a real proofing cycle. Deliberately NOT done: reusing a guest row when a typed email matches, which the report suggests first. It would let anyone who knows an address inherit that person's identity and selections, and answering differently for a known email would leak which addresses are in the gallery — the thing /guest/recover already goes out of its way to avoid. Prevention at the entry path needs the verification round-trip, which is a separate decision about friction. 13 tests; 8 of the 9 backend ones fail without the change. The frontend ones caught a real bug while being written — the new useMemo sat after the loading early-return, so the hook count changed between renders. * fix(guests): merge must not strand a pending invite (#1210) Three findings from external review of #1216. **A merge could kill an emailed invite link.** Creating an invite inserts a real gallery_guests row, so an admin who pre-mints one and then sees the guest self-register has two rows sharing an email — which this feature now points out and offers to merge. Redemption resolves guest_invites.guest_id with is_deleted: false, so merging soft-deleted the row the link pointed at: the client got 404 guest_missing while the invite dialog still showed the invite as Pending. Nothing anywhere said the link was dead. Unredeemed, unrevoked invites now move to the survivor first. Spent ones stay put — a redeemed invite records who redeemed what, and retargeting it would rewrite that. **The preselection silently chose the survivor.** performMerge keeps mergeSelection[0], and the group was handed over in API order, which is newest-first — so Review then Merge discarded an older, email-verified row holding most of the picks in favour of a fresh re-registration. The proposal is now ordered deliberately: verified first, then whoever holds the most feedback, then the oldest. Still only a proposal, and the confirmation now names the survivor by email as well as name, because duplicates share a name and 'Merge 2 guests into Tina?' said nothing. **duplicate_of was quadratic.** Every row carried the other n-1 ids, so a group of n serialised n² of them — and nothing consumed the list: the UI asked only whether a row was in a group, then regrouped by email itself. Replaced with duplicate_group, the normalised email, which keeps the payload linear and the case/whitespace folding in one place instead of reimplemented on the client. Two new backend tests for the invite paths, one frontend test asserting the merge call keeps the verified row. The invite test fails against the un-fixed code. * fix(guests): keep guest-controlled input out of who survives a merge (#1210) Round 2 of external review on #1216. **The survivor ranking used an attacker-controlled signal.** Preferring whoever holds the most feedback looked like the obvious tiebreak and is exactly the wrong one: registration does not verify the address, so anyone who knows a guest's email can register with it, mark enough photos to out-rank the real person, and be preselected as the survivor. An admin accepting a confirmation between two rows with the same name and email would then move the victim's picks onto an identity whose token the visitor still holds. distinct_photos is guest-controlled and has no business deciding this. The ranking is now email_verified_at then created_at — both server-set. **A merge could make the survivor unrecoverable.** Rows are grouped with case and whitespace folded out, so a merge can be proposed between [email protected] and [email protected]. /guest/recover lowercases what the guest types and then matches on equality, so a survivor left holding the raw value can never be recovered by email again. The kept row's address is now canonicalised during the merge. Both write paths normalise today, so this covers rows that predate that — which are exactly the rows case-folded grouping surfaces. Two more backend tests. The residual, stated plainly: an admin can still merge two unverified rows in either order. What is gone is the tool ranking them by something a visitor controls. * fix(compose): pass GUEST_TOKEN_TTL through to the backend (#1210) The override was documented in .env.example and could never take effect: the backend service takes an explicit environment list, so a variable not named there never reaches the container. An operator following the documentation would have shortened the guest session and seen nothing change. docker-compose.production.yml uses env_file: .env and already passed it through; docker-compose.dev.yml is gitignored, so only this file needs it. * fix(guests): the admin picks the merge survivor, the tool does not (#1210) Fourth review round on the same point, and the right conclusion is that there is no correct automatic answer. Every rule tried was wrong somewhere. Most-feedback is guest-controlled — the address is never verified at registration, so anyone who knows it can register and mark photos until they out-rank the real person. Oldest-first, the replacement, is worse for the ordinary case: when a token expires the OLD row is the dead identity and the new one is the visitor's live session, so keeping the oldest deletes the identity they are actually using, and the frontend holds that deleted guest in sessionStorage without clearing it on a 401. Registration timing is visitor-controlled too. The data does not say which row is really the person. So the UI asks: merge mode gains a Keep column, the button stays disabled until a row is nominated, and only rows included in the merge can be nominated. The group is still preselected — finding the duplicates was always the point — but nothing about who survives is decided by sort order any more. This also makes the claim in the PR description true. It said the admin decides which row survives; until now the preselection quietly decided it for them. Two rewritten frontend tests: the merge is blocked until a survivor is chosen and then keeps exactly that row, and a row outside the group cannot be nominated. The test i18n mock now interpolates, so aria-labels are queryable by their rendered text. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-28 08:27:15 +02:00
Paul Nothaft	27aff7c04e	chore(main): release 3.118.0-beta.0 (#1222)	2026-08-28 06:25:14 +00:00
Paul NothaftandPaul Nothaft	22e00f80b6	feat(feedback): a third identity mode with one shared colour tag per photo (#1197) (#1208) ... * feat(feedback): a third identity mode with one shared colour tag per photo (#1197) Split out of #1178, where @boergu asked for a colour tag with no identity dimension at all: not everyone sharing a device's state, but everyone — on any device — sharing the PHOTO's state. Guest A marks it green, guest B later marks it orange, and the tag simply becomes orange. One collaboratively-agreed verdict per photo instead of per-person tallies. identity_mode gains 'shared'. The mode is scoped to the colour tag: likes, ratings, comments, favourites and reactions stay per-visitor exactly as in 'simple', because that is what was asked for and widening it would change what every other control means. Stored as an ordinary photo_feedback row under a reserved identifier rather than as a column on photos. That is what keeps the rest of the system working untouched — the per-colour tally simply has exactly one entry, so dominant_color_label, color_label_count, the admin colour filter and the XMP/CSV export that #745 reads all keep their existing shapes, and no consumer has to learn a second one. The identifier cannot be claimed: real ones are sha256 hashes or server-minted UUIDs, and the per-guest write path rejects it outright. Last write wins, inside a transaction that locks the photo row. Without the lock two guests tapping different colours in the same instant both read 'no tag', both insert, and the photo ends up carrying two shared tags — the per-guest tally this mode exists to remove. Re-sending the colour already on a photo clears it, from any guest: the same toggle every other colour path uses, and the only way to remove a tag without inventing a second control. Switching modes is non-destructive. Existing per-guest labels are left alone and simply not read while shared is on; the shared tag starts empty rather than collapsing marks nobody agreed on, and switching back restores every original exactly. An event can hold both sets, only one of which is live. The tag stays visible with show_feedback_to_guests off — it arrives through the per-viewer channel, being the photo's own state rather than someone else's opinion — while the per-colour tallies stay hidden. The colour filters answer from it for the same reason, so a gallery with sharing off cannot show colours on tiles that no filter can find. Attribution is gone by design, and the settings panel says so before an operator picks the mode. Decisions (1), (4) and (5) from the issue were settled up front, as it asked. Decision (3) turned out not to need anything: guest colour filters already read my_color_label, and the admin's my_color_labels filters photo_admin_marks (#1183), not guest identity — so nothing collapses on either side. * fix(feedback): shared mode saves on Postgres, and dormant labels stay dormant (#1197) Three findings from external review, all confirmed against source before fixing. **The mode could not be saved on Postgres at all.** Migration 078 created identity_mode with a CHECK constraint pinned to ('simple','guest'), guarded on `client === 'pg'` — so SQLite never has it and no SQLite test can see it, while the database every default production install runs rejects the new value outright. Migration 192 drops and re-adds the constraint with 'shared' included; its down() resets any event using the mode to 'simple' first, or the narrower constraint could not be restored. Verified against a real Postgres on a scratch database: the insert fails before, succeeds after, up() is re-runnable, and down() puts the old constraint back. **Dormant labels were still being read.** Switching modes is deliberately non-destructive, which leaves both sets of colour labels in the table with only one live — and every read that did not say which set it meant kept counting the other. The per-colour tallies, color_label_count, the admin grid badge, the XMP/CSV export, both admin colour filters and the guest colour filter all saw labels the mode does not show; switching back exposed the shared row as an anonymous other guest's dot. The settings panel promises these are 'kept but not shown', and that has to mean every surface, not just the badge. Scoped at the source — the two count helpers resolve the mode themselves — so the admin grid and the export are fixed without touching either. **The create form's identity mode was dropped.** CreateEventPage has always rendered the chooser and the create route never read it, so a gallery created as 'guest' came out 'simple' and had to be set again on the event afterwards. A pre-existing bug that adding a third option made worse; threaded through now, which fixes it for all three modes. Six regression tests, each verified to fail against the un-fixed code. * fix(feedback): keep every colour surface consistent across a mode change (#1197) Second review round, four findings, all confirmed in source first. **Stored counters went stale on a mode switch.** photos.color_label_count is denormalized and recomputed on feedback writes, so changing identity_mode — which changes nothing about the rows, only which of them are live — left the old mode's totals on the tiles, the admin grid and the filter summary until each photo happened to be touched again. On a finished gallery that is never. Recounted for the event when the mode actually changes, as two statements rather than a per-photo recompute: four of the five counters cannot have moved. **Duplicating an event dropped the mode**, the same shape as the create-form bug from the last round — a gallery cloned to reuse its proofing setup came back in 'simple'. **The event feedback summary counted dormant labels**, inflating total_feedback in the admin analytics and the guest /feedback-summary while every other surface hid them. **The swatch trusted its optimistic guess over the server.** In shared mode the tag belongs to the photo, so another guest can move it between this viewer's last read and their click: a viewer still showing green clicks green, the server sets green because the tag had become red meanwhile, and the optimistic 'same colour, so clear' blanked the swatch against a server that holds one. The response already says which happened, so it is used. The per-guest modes are unaffected — only the guest can move their own label, so guess and answer always agreed there. Three regression tests, each verified to fail against the un-fixed code. * fix(feedback): shared tag is not a participant, and the keyboard path reconciles too (#1197) Third review round, two findings. **feedback_count counted the shared tag as a guest.** It is COUNT(DISTINCT guest identity) across all feedback types, and the reserved identifier looked like a person: a photo with one rating and a shared tag reported two. The column is exported as rating_count (photoExportService), so merely tagging a photo inflated its rating count in the CSV and JSON exports. **The lightbox keyboard path still trusted its own guess.** The reconciliation from the last round covered clicks through PhotoColorLabels, but the proofing shortcuts call PhotoLightbox.submitColorLabel directly and set local state from a locally computed toggle. That is the path a proofing client actually uses, so it had the divergence the previous fix was for: another guest moves the tag, this viewer presses the key, the server sets a colour and the swatch blanks. Both branches now read the outcome off the response. One regression test, verified to fail against the un-fixed code. * fix(feedback): identity-mode lookup must survive a migration-time caller (#1197) updatePhotoFeedbackStats is called from migrations as well as from the request path — migration 186's duplicate-photo dedupe (#1162) recomputes the survivor's totals — and a migration runs against a half-built schema where event_feedback_settings need not exist yet. The new inner join threw there, which took the whole stats update down with it, so the reparented rows were never counted and eight assertions in the 186 suite failed. Falls back to 'simple', which is the right answer rather than merely a safe one: an install with no feedback settings table has no event in shared mode, so the non-shared scope is exactly correct. Caught by CI, not by me — I had been running affected suites rather than the full one after each review round. * fix(feedback): atomic shared-tag write, scoped feedback list, safe PG fallback (#1197) Round 4 of external review, and one of the three is about the fix I made for the CI failure two rounds ago. **The identity-mode fallback could poison a Postgres transaction.** The join was wrapped in try/catch so a migration-time caller with a half-built schema would fall back to 'simple'. On Postgres a failed statement aborts the entire transaction, so catching it and carrying on left the caller's trx poisoned and the aggregate that follows failed with 'current transaction is aborted' — defeating the very compatibility the fallback was added for. It now asks whether the table exists before issuing the join, which is safe to ask and aborts nothing. Memoised once true, since a table does not un-create itself and this sits on the feedback write path. **The shared-tag stats were recomputed after the commit.** A failure there returned 500 for a tag that had already been written, so the client reverted its swatch and the next tap on the same colour toggled the committed tag off instead of setting it. Two concurrent writers could also race their aggregate updates. Recomputed inside the transaction now, while the photo row is still locked. **The raw feedback list still carried both label sets.** Only the tallies and my_feedback had been scoped, so a dormant per-guest label was still visible to anyone reading the list — and with sharing off it came back flagged is_mine. getPhotoFeedback now filters colour labels to the active set. One test for the list; the migration suite that caught the original CI regression still passes. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-28 08:19:41 +02:00