78 Commits

Author	SHA1	Message	Date
Luca	9431b9f094	feat(setup): configure the public address and SMTP in the wizard, not .env (#1104) ... * feat(setup): configure the public address and SMTP in the wizard, not .env A fresh install could not configure its own public address. `general_site_url` and the `email_configs` row already existed as admin settings, but nothing could reach them: - docker-compose.yml injected FRONTEND_URL=${FRONTEND_URL:-http://localhost:3000} and Dockerfile.aio baked in ENV FRONTEND_URL=http://localhost:3000, so getFrontendBaseUrl() returned on its first branch every time and the setting was never read. .env.example shipped the same value as an uncommented placeholder for FRONTEND_URL / ADMIN_URL / API_URL. - the wizard never asked for the address at all, and skipped its whole config step unless a CRM-ish feature was selected — so a gallery-only install was also never offered SMTP, despite gallery links, guest invites and expiry warnings all going out through email_configs. - eleven call sites read process.env.FRONTEND_URL directly rather than the resolver, three of them defaulting to placeholder hosts that reached real recipients: https://app.example.com in payment-reminder emails, localhost:3005 in admin invitation emails, https://app.example.com in dev template previews. Stop injecting a default anywhere, and resolve the origin instead: FRONTEND_URL -> general_site_url -> the origin the request arrived on -> whichever exists -> ''. A loopback candidate is treated as unconfigured so the installs that already have http://localhost:3000 baked into their environment self-heal; the same guard previously lived inline in routes/gallery.js for the slideshow QR (#848) and is now shared. The empty return is preserved because shareLinkService and the SSO redirects in routes/auth rely on it to emit relative urls — callers needing an absolute url use getAbsoluteFrontendUrl(), which still ends at http://localhost:3000. The wizard now persists window.location.origin right after the admin account is created, so an install that skips the rest still has a usable origin for background jobs that have no request to derive one from, and offers it as an editable "Public address" field. Settings -> General shows the field read-only when FRONTEND_URL pins it, instead of silently ignoring edits. Also drop the `|| 'mailhog'` fallback when seeding email_configs: that host only exists in the dev compose profile (which does not even start by default), so a fresh install came up with a live config pointing nowhere while the wizard showed empty SMTP fields. With no row, blank fields are the truth and emailProcessor logs "No email configuration found". Developers set SMTP_HOST=mailhog explicitly. backend/src/services/emailService.js is deleted: nothing in backend/ references it, and it was the only consumer of the SMTP_* variables, which misrepresented how mail is configured. Refs #705 * fix(setup): keep FRONTEND_URL ahead of ADMIN_URL/APP_URL when resolving links The previous commit routed two call sites through the resolver but put the site-specific variable FIRST, silently reversing precedence: userManagementService was: FRONTEND_URL || ADMIN_URL || localhost:3005 became: ADMIN_URL || resolver adminEvents/crud was: FRONTEND_URL || APP_URL || '' became: APP_URL || resolver An install with both variables set would have flipped which one won. Call the resolver first instead — it starts with FRONTEND_URL, so the original relative order is preserved and only the final fallback changes: localhost:3005 (not even the frontend's port) and '' (a relative link inside an email) both become the resolved origin. Refs #705 * fix(setup): unpin loopback FRONTEND_URL, keep ADMIN_URL/APP_URL reachable Review feedback on #1104. isEnvPinned() reported ANY FRONTEND_URL as authoritative, including the loopback values getFrontendBaseUrl() deliberately demotes. An install upgrading with the old compose default FRONTEND_URL=http://localhost:3000 therefore resolved its origin from general_site_url correctly, but got the Site URL field rendered read-only in Settings and skipped by the wizard's seeding - locking the exact operators this change exists to unblock out of configuring a public address anywhere. The predicate now mirrors the resolver, and the derived general_site_url_effective the General tab reads comes from the same helper instead of re-normalising process.env inline. APP_URL and ADMIN_URL had become dead code: getFrontendBaseUrl() only returns falsy when NOTHING is configured, so `|| process.env.ADMIN_URL` after it never ran once a site URL existed - which after this PR is the normal case. A split-origin install pointing ADMIN_URL at a separate admin host got invite links on the public gallery origin instead. They are now passed as an explicit `override` that resolves directly below FRONTEND_URL, preserving the historic FRONTEND_URL-before-ADMIN_URL order while beating the database- and request-derived fallbacks. general_site_url now feeds the CORS allowlist and the Access-Control-Allow-Origin header, not just email links, so a schemeless value is an allowlist entry no browser origin can match. Validate it server-side in PUT /general (isURL with require_protocol, require_tld off so LAN/NAS installs on http://nas:3000 still work) and client-side in both surfaces that write it - type="url" never fires in either, since neither input sits inside a form. Two more wizard fixes: the General tab no longer reposts general_site_url while it is env-pinned, because the field then holds the effective env value rather than the stored one and the round-trip read as a change to a protected key, 403ing a settings.edit-without-settings.domains admin on an unrelated save. And SetupConfigStep validates the From address before posting - /admin/email/config rejects a blank one, which used to surface as a generic warning while the wizard advanced from its finally block anyway, discarding every SMTP value the user had typed, password included. A failed save now keeps them on the step. * fix(setup): surface a rejected public address instead of swallowing it Review round 2 follow-up on #1104, pushed onto the branch. saveSiteUrl() caught and discarded every error. That was defensible before round 2 added a server-side URL check, but PUT /general can now answer 400 — and the two validators disagreed: http://my_nas.local client: accepted server: rejected http://foo_bar:3000 client: accepted server: rejected validate() let those through, the 400 was swallowed, `failed` stayed false and onDone() ran. The operator finished the wizard believing the public address was stored when nothing had been. That is the silent misconfiguration this whole change exists to remove, landing on the LAN and NAS installs it targets. Three parts: - saveSiteUrl() throws. finish() resolves it before anything else is posted and puts the message on the address field rather than the generic "some settings could not be saved" warning. Skip for now still always leaves, by contract, but warns instead of dropping the value in silence. - allow_underscores on the server check, for the same reason require_tld is off: browsers resolve http://my_nas.local and the client accepts it, so rejecting it server-side only produced the mismatch above. Both validators now agree across the LAN/NAS, IDN, bare-IP and scheme-less cases. - LOOPBACK_BASE_RE anchors its host token. Bare prefix matching also demoted https://localhost-nas.example.com, and now that this predicate gates the whole resolver rather than just the slideshow QR, being demoted means a configured address is silently ignored. 127. stays a bare prefix on purpose: all of 127.0.0.0/8 is loopback. Resolver suite 31 passing, up from 26. Mutation-checked: restoring the unanchored regex fails the three new host-boundary cases. * fix(settings): don't lock the General tab on a site URL nobody typed Review follow-up on #1104, pushed onto the branch. general_site_url was free-text until this PR added a server-side check, so an upgraded install can hold something schemeless that predates it. The tab flagged that on load, and `disabled={!!siteUrlError}` then killed Save for EVERY General setting. An admin holding settings.edit but not settings.domains could not clear it either: correcting the address is a change to a protected key and 403s. The tab has no permission gating, so that role was simply locked out of the tab with no self-service way back. That is the same role adminSettings.js:85-95 documents the no-op round-trip allowance for. The allowance only helps if the request is made, and this blocked it in the browser first. Validation now waits until the field is actually edited, and an unchanged value is dropped from the payload rather than reposted — matching what the env-pinned case already does one line above, and for the same reason. stored value invalid, untouched Save works, key not sent edited to something unusable Save blocked edited to a usable absolute url saved Four tests, first coverage for this feature. Mutation-checked: removing the dirty gate fails the untouched-value case. --------- Co-authored-by: Paul Nothaft <53005142+the-luap@users.noreply.github.com>	2026-08-21 12:54:14 +02:00
Paul Nothaft	b69dd134d0	feat(faces): People in this gallery — face recognition via an optional ML sidecar (#1074) (#1075) ... * feat(ml): optional face-detection sidecar, opt-in and inert by default (#1074) First of four PRs for "People in this gallery". This one ships only the sidecar, its wiring and its CI — no schema, no backend code, no UI. Nothing in PicPeak calls it yet. picpeak-ml is a single FastAPI + onnxruntime container: three endpoints (/health, /info, /faces), no database, no volumes, no egress, no model download at runtime. Clustering, person identity and every privacy decision stay in the backend where the data already lives. Models are YuNet (detection) + FaceNet-512 (embedding), both MIT, both pinned by URL and SHA-256 and verified at build time. The licence analysis is in ml/LICENSES.md: the more accurate InsightFace weights are non-commercial-only and PicPeak's users are working photographers, so they are never baked into an image we publish. Two things worth review attention: - Alignment uses a least-squares similarity transform (Umeyama), NOT cv2.estimateAffinePartial2D. RANSAC and LMEDS exist to reject outliers among many correspondences; given five landmarks and no outliers they fit a three-point subset exactly and let the rest drift. Measured on a real off-frontal portrait: eyes and nose pinned to 0.11px, mouth corners 11.8px out on a 160px crop. Umeyama distributes it (max 6.5px, rms 5.1 vs 7.4). The failure mode is silent — a bad warp still yields 512 confident floats — so tests/test_pipeline.py pins it numerically. - FACENET_ONNX_URL has no default and the build fails loudly without it. deepface distributes FaceNet-512 as Keras .h5 only, so the ONNX is produced once by tools/convert_facenet.py and published as a release asset. Converting inside the build would drag TensorFlow through both architecture legs of every build to produce a byte-identical file. The CI jobs are gated on the FACENET_ONNX_URL repository variable and skip cleanly until it is set. Off by default, twice over: the sidecar is behind the `faces` compose profile, and the backend will gate on a `faces` feature flag that defaults to false. FACE_ML_URL defaults to http://picpeak-ml:8000 so the standard deployment needs no configuration — nothing dials that host while the flag is off, which is why a non-resolving default is harmless. Verified: 27 pytest tests green; YuNet loads and detects against a real portrait with its landmark order matching the alignment template index-for-index; both compose files validate and the faces profile is correctly excluded from a default `up`; workflow YAML parses and the job graph resolves. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(ml): pin the converter toolchain, verify parity, drop a false reproducibility claim (#1074) Ran the FaceNet-512 conversion for real and corrected what the previous commit assumed about it. The conversion works: 23,497,424 parameters, 89.6 MB ONNX, and the converted graph matches the Keras original to 2.086e-06 absolute / cosine 1.0000000000. That check is now part of the script rather than something I did once by hand — a subtly wrong graph still returns 512 plausible floats, so it refuses to leave the file on disk if parity fails. Also ran the full pipeline against both real models end to end. The embedding is L2-normalized to 1.000000, and the same face survives being re-rendered: half scale 0.973, double scale 0.984, JPEG q40 0.987, rotated 8 degrees 0.984, brightness +40 0.988. Scale invariance in particular is evidence the alignment warp is doing its job. Corrected claim: the conversion is NOT byte-reproducible. Two runs with the same pinned versions on the same machine gave different SHA-256s. The graphs are functionally identical — same 336 nodes, same 271 initializers, every weight matching to 0.000e+00 — but a few initializer names differ because tf2onnx's traced-op naming is not deterministic (Keras layer naming is deterministic; I checked). The previous commit message and README both claimed byte-identical output. They were wrong, and it matters: anyone re-running the conversion gets a different hash, and without this note that reads like tampering. The build-time SHA-256 pins one published artifact so its URL cannot start serving different bytes; validating a fresh conversion is the parity check's job. requirements-convert.txt now pins the exact set that produced the artifact, including transitive keras/protobuf/numpy, and documents that the converter needs Python 3.11 while the image runs 3.12. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * feat(faces): schema, queue, clustering and API for People in this gallery (#1074) Backend half of the feature. Migration 177, a face-detection queue, the clustering engine, the gallery and admin APIs, and the privacy wiring. No UI yet; nothing is reachable until the `faces` feature flag is on, which defaults to false. The flag is the gate, not FACE_ML_URL. That variable now has a working default (the compose service name), so its presence proves nothing about intent — if it were the gate, every install would poll a hostname that does not resolve. faceQueue re-checks the flag every tick, so turning it off stops the workers without a restart. Visibility scoping is the part worth reviewing closely. Face rows have no concept of photo visibility, but guests are restricted to photos.visibility='visible'. A raw count leaks how many hidden photos someone appears in, and an unscoped cover face renders a crop of a photo the guest may not open — with the best-scoring face being the likeliest pick, so it would happen often rather than rarely. facePeopleService recomputes both per request against the caller's own scope, and event_people.face_count_total is named to be conspicuous in a guest path. Six tests cover it, including the case where a person's photos are ALL hidden and they must vanish entirely. Face data is excluded from backups and .picpeak exports, per the decision in the thread: it is derived, so a restore re-scans rather than carrying biometrics between operators. Three separate mechanisms, because the engines cannot be filtered alike — EXCLUDED_TABLES for export, --exclude-table-data (not --exclude-table; the CREATE TABLE must survive or restore breaks on the first query) for Postgres, and DELETE + VACUUM on the temp copy for SQLite, which has no way to exclude a table from a whole-file .backup. The VACUUM is not cosmetic: without it the pages stay in the file and the claim is false on disk. Archiving now purges face data explicitly. photo_faces cascades off photos, but archive deletes neither the photo rows nor the event, so without this an archived gallery kept its biometrics indefinitely. Other decisions: clustering keeps names across a re-cluster by majority inheritance (without it, one button click silently discards every name the photographer typed); consolidation refuses to merge two people who were named differently; assignment never compares across model_version, since embeddings from two pipelines are not comparable; low-quality faces are stored but left unassigned so they show in "this photo contains" without spawning junk people. Migration is 177, not 174 — 174/175/176 landed on main while this branch was open. 29 tests green: 7 migration (idempotency, down(), cascade, and that installing it enqueues NOTHING), 11 clustering, 11 privacy/visibility. Lint clean; the pre-existing error counts in databaseBackup.js and server.js are unchanged. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * feat(faces): People strip, face filter and admin controls (#1074) Frontend half. Renders nothing anywhere unless the `faces` feature flag is on AND the photographer enabled detection for the gallery — the whole guest surface hangs off one boolean, event.people_enabled, which the server computes from the flag, the per-event toggle and the show-to-guests toggle together. Guest side: a People strip between the filter bar and the grid, circular crops from each person's cover face, an active-filter chip row, and a "Show all" bottom sheet. The face filter composes with category, search, media type and the liked/saved/rated filters in the same useMemo rather than replacing them, so "photos of Anna that I liked" works. Two people selected means AND by default — that is what picking a second face almost always asks for — with a toggle to OR that appears only once a second person is picked. Unnamed people show a photo count and never "Person 7". A number is honest about what the system knows; an invented name is not. There is a test asserting we don't do it. The strip renders nothing below two people, collapses to one line when dismissed (persisted per slug, so dismissing one gallery says nothing about the next), and appears mid-backfill with a progress line rather than blocking the gallery behind a spinner. Avatar crops are computed in ratios of the source dimensions so they survive whatever rendition the browser gets; without width/height they fall back to an uncropped thumbnail, since a wrongly-offset crop is worse than no crop. No new download endpoint: "download these N" rides the existing photoIds path, which already enforces access level and per-category permissions server-side. Adding a person_id selector would have been a second thing to authorize for no gain. Guest-facing copy never says "biometric" or "recognition" — those words describe our implementation, not the guest's experience. The sheet's footnote answers the first question every guest has (where does this go?) inline. The admin card, by contrast, is explicit: it states the controller obligation next to the toggle, and warns that scanning materializes the preview tier on galleries that never generated one, which is real CPU and disk an admin should know about before a 2,000-photo backfill. EN + DE translations. 140 frontend tests green (8 new), tsc and eslint clean. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(faces): measured match threshold, working build defaults, 89MB smaller image (#1074) Ran the Phase 0 spike that had been outstanding, published the model, and fixed what both turned up. THRESHOLD IS NOW MEASURED, NOT GUESSED. LFW's standard 1000-pair protocol run through this exact pipeline (YuNet -> Umeyama alignment -> FaceNet-512 ONNX), 100% detection on 2000 images: same person cosine 0.6958 +/- 0.1415 diff person cosine 0.0849 +/- 0.1674 separation 0.6109 peak accuracy 96.60% @ 0.405 So the pipeline separates people well — the thing I could not previously claim, since every earlier number was the same face re-rendered. Default moves 0.62 -> 0.50. The old value was a placeholder and a bad one: it gave 0% false merges but 22.4% false splits, i.e. roughly one in four same-person pairs failing to join, which fragments a gallery badly. 0.50 gives 1.0% false merge / 8.2% false split. Peak accuracy (0.405) is deliberately NOT chosen: for clustering the two errors do not cost the same. A false split is a duplicate row the photographer can merge away; a false merge puts a stranger into someone's "download my photos" — and until the Phase 2 merge/split UI ships, there is no way to undo one. So this sits on the conservative side of the optimum. The spike is committed as ml/tools/benchmark_threshold.py rather than thrown away, so "why 0.50?" has an answer in six months and a re-tune is one command. BUILD DEFAULTS. FACENET_ONNX_URL/_SHA256 now default to the published ml-models-v1 release asset, so `docker build ml/` and `docker compose --profile faces up` work with no arguments. Blanking either still fails loudly — a URL without a checksum is never acceptable, since the checksum is what makes the URL safe to trust. Found by running compose for real: it failed exactly as designed, which was correct behaviour and a bad out-of-box experience now that a canonical artifact exists. IMAGE SIZE. 389MB -> 300MB single-arch. `chown -R` after COPY rewrote every copied file into a fresh layer, duplicating the 90MB model for nothing; the user is now created before the copies and ownership set via COPY --chown. Also drops pip/setuptools from the runtime image. Measured RSS is 186MiB idle, and the container answers /faces end-to-end in well under the 80-150ms/photo the issue budgeted. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(faces): threshold 0.50 -> 0.60 from real clustering, theme-aware People strip (#1074) Both fixes come from running the feature on an actual gallery — 61 photos, 5 real identities — rather than reasoning about it. THRESHOLD. The LFW pairwise sweep in the previous commit said 0.50, and it was wrong. On a real gallery at 0.50, three of six visible clusters were contaminated: two different people merged into one strip entry, which is the exact failure that puts a stranger into someone's "download my photos". Pairwise error rates do not predict cluster purity. Greedy assignment compounds — one wrong face drags the centroid toward the midpoint between two identities, making the next wrong face likelier. A 1% pairwise false-merge rate is not a 1% chance of a clean gallery, and no amount of staring at an ROC curve would have shown that. Sweep against ground truth (5 identities): 0.50 -> 6 clusters, 3 contaminated 0.56 -> 6 clusters, 0 contaminated 0.60 -> 5 clusters, 0 contaminated <- exactly right 0.64 -> 5 clusters, 0 contaminated, fewer faces assigned 0.60 recovers the right number of people with no contamination; higher only loses coverage. Migration 177 carries the full reasoning so the next person to touch this knows why the obvious pairwise answer is the wrong one. THEME. The People strip hardcoded `text-neutral-800` for named people. On a dark gallery — which the screenshot immediately showed — that renders a named person's label almost invisibly, while UNNAMED people stayed legible. Exactly backwards. Labels, headings, the collapsed summary, the scan line and the filter chip row now read the gallery's own theme tokens (--color-text / --color-muted-text / --color-accent / --color-surface-border) like the rest of the gallery surface. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(faces): keep the mobile filter row inside the viewport (#1074) At 390px the photo count and Clear link were pushed against the right edge by ml-auto and clipped. Only apply it from the sm breakpoint up, where there is room; below that they flow after the chips. Found by screenshotting the real thing on an iPhone-sized viewport. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * feat(faces): complete Phase 1, add People management and auto-categories (#1074) Closes the two Phase 1 gaps, then builds Phase 2 and Phase 3. PHASE 1 GAPS. "Download these N" was specified, described as done in an earlier summary, and never actually built — I had verified the backend needed no new endpoint and let that stand as if the button existed. It now hands the filtered photo ids to the same path as a manual selection, so the server re-applies access level and per-category permissions on the way through. Photos in a downloads-disabled category are excluded client-side too, so the number on the button is the number the guest receives. Hidden entirely when downloads are off for the gallery. Lightbox person chips ("In this photo: Anna") are the second way into the face filter — a guest looking at a photo of themselves can act on it without scrolling back to the strip. Tapping one closes the lightbox and filters the grid behind it. PHASE 2. A People management modal over the endpoints that already existed and were already tested: rename inline, merge (multi-select, first pick is the target so the name a photographer typed survives), split via a face picker, hide, ignore. This matters more than it sounds — clustering deliberately errs toward splitting because a wrong merge puts a stranger into someone's download, and that trade only works if merging is easy. PHASE 3. Rule engine over face_count plus face-area ratio: 0 -> Details, 1 large -> Portraits, 2-5 -> Small groups, >5 -> Groups. The area ratio is what separates "a portrait of someone" from "someone is in this landscape". Three guarantees, all tested: it only ever fills an EMPTY category (enforced in the query AND re-checked in the UPDATE, so a photographer setting one mid-run still wins), everything it touches is marked auto_categorized so undo is exact, and it is a no-op unless separately enabled. Migration 178 adds the column — separate from 177, which has already run wherever this branch is deployed. Verified on the real gallery: 61 photos -> 48 portraits + 13 small groups, undo cleared exactly 61 and left the manual ones alone. Merge moved faces and removed the source. Both confirmed against the database, not just the UI. TWO BUGS THE BROWSER CAUGHT, both invisible to tsc: - The lightbox destructure never landed — my patch targeted a line that has a default value, matched nothing, and failed silently. `people` resolved to something else entirely and the chips would never have rendered. eslint's "outer scope value" warning is what surfaced it. - Admin face thumbnails 403'd because <AuthenticatedImage> attaches whatever gallery token is in session storage; an admin who has also opened one of their own galleries sends a type:"gallery" bearer to an admin route. Admin routes authenticate from the httpOnly cookie, which a plain same-origin <img> sends by itself. Worth noting AdminPhotoGrid has the same latent shape; not touched here. Also: the admin card now reports "N people (M shown to guests)" when those differ, so the settings page and the gallery stop disagreeing without explanation. 45 backend tests (8 new) and 140 frontend tests green; tsc and eslint clean. EN + DE for every new string. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * perf(faces): batch migration DDL and drop the face stack from server.js import (#1074) CI's backend job timed out at 10 minutes on the first run of this branch. Nothing failed — 132 of 182 suites passed and the wall clock ran out. Main does the same 182 in 124s, and where main has 12 suites slow enough for jest to print a duration, this branch had 77. Two changes, both worth making regardless of how much of the gap they close: - Migration 177 added its columns one ALTER TABLE at a time (four on photos, three on events, plus a separate index statement) and seeded settings with a SELECT and an INSERT per key. It now uses one alterTable per table and one SELECT plus one bulk INSERT. 178 folds its index into the same statement as its column. That chain replays in ~90 suites, so statement count there is multiplied by 90. - server.js required faceQueue at module scope, which pulls in axios and — through imageProcessor — sharp. Every supertest suite that imports server.js was paying for a module graph it never uses. Now required inside the startup block, next to the call that needs it. Honest about the evidence: locally the migration delta measures at zero (1.15s vs 1.13s for the same suite, three runs each), so batching alone does not explain an eight-minute regression. A fast local disk and many cores mask per-statement and per-import costs that a two-core runner with a shared disk does not. These are the two real costs this branch added to a path that runs in almost every suite; whether they are sufficient is a question for CI, not for another round of local speculation. 37 face tests still green after the change. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * i18n(faces): complete EN and DE coverage for the face feature (#1074) The admin card and the Features toggle were rendering entirely from inline English `defaultValue` fallbacks — 22 keys existed in no locale file at all, so a German admin saw an English consent notice, English toggles and English buttons. The gallery side was already translated; the admin side was not, and nothing in the toolchain flags this because a `defaultValue` always renders something. Adds the missing `admin.faces.*` (19), `settings.features.faces.*` (2) and shared `common.clear/saved/saveFailed` in both languages. Existing keys are left alone (setdefault, not overwrite), so the shared `common` strings other features rely on are untouched. Committed the audit as frontend/scripts/i18n-faces-audit.py rather than throwing it away: it extracts every t() key the face components actually use and diffs it against each locale, and it also reports German values that are byte-identical to English, which is the usual shape of an untranslated copy-paste. Currently: 69 keys in use, EN complete, DE complete, no identical pairs. Verified in the browser, not just in the JSON — the German card reads "61 / 61 Fotos durchsucht · 16 Personen (5 für Gäste sichtbar)" end to end. Also checked the components for hardcoded user-facing text (JSX nodes, title/aria-label/placeholder attributes) outside t(); there is none. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(faces): 13 defects from external review — coordinates, counts, erasure, races (#1074) Codex reviewed the branch against main. Thirteen findings, nine P1. I checked every one against the code and could not dismiss a single one as a false positive, so all thirteen are fixed here. THE WORST ONE: bounding boxes were stored in the wrong coordinate system. The sidecar reports coordinates in the space of the image it was HANDED — which is the ≤1920px preview, not the original — while every consumer compares them against photos.width/height, the original dimensions. A 6000px photo therefore produced boxes ~3x too small and areas ~9x too small: avatar crops landed in the wrong place and the Portraits rule could never fire. It is invisible on any photo already under 1920px, which is exactly why the demo gallery and every screenshot looked correct. Now scaled once in faceProcessor so everything downstream can assume original-image coordinates. ERASURE. The FK cascade on photo_faces is decorative on SQLite: PicPeak never enables `PRAGMA foreign_keys`, so deleting a photo left its embeddings behind. I first enabled the pragma globally and reverted it — six unrelated suites immediately failed on pre-existing dangling references, and switching it on would start rejecting inserts on every existing install. That is a real change worth making, but it is its own PR, not a rider on this one. Instead deletion purges explicitly: purgePhotoFaces in the photo paths (single, bulk, service) and photo_faces/event_people in deleteEventCascade. Tests assert this with the pragma explicitly OFF, so they can only pass if the code does the work. COUNTS. A re-scan deleted the old face rows without undoing their contribution to event_people, so counts inflated on every re-scan and ghost people survived. Now the affected people are recomputed before the replacements are assigned. My own "must not double its faces" test only checked photo_faces rows, which is why it passed throughout. RACES. A worker that finished after an admin purged the event committed its rows anyway — erasure reported success and the data reappeared. The commit is now conditional on the row still being 'processing'. And assignFaces is read-modify-write over an event's people, so two workers lost each other's updates; it is now serialised per event with an in-process mutex plus a Postgres advisory lock for the multi-pod case the queue advertises. METADATA LOSS. Merging discarded the source's name and suppression flags, so a merge could erase a typed name or un-hide someone. Reclustering remembered only people with a label, so an unnamed-but-hidden bystander came back guest-visible after one "Re-group people" — and suppression now propagates to every descendant cluster, not just the majority one. Also: export reset face_status so a restored gallery re-scans instead of claiming to be scanned forever; manual category edits clear auto_categorized so "undo automatic" cannot delete a photographer's own choice; external photos are skipped rather than failed (resolvePhotoStorageKey returns null for them by design); the gallery refetches photo memberships as a scan progresses so filtering is not stale; a failed VACUUM now fails the backup rather than publishing one that may retain biometric pages; and the ML Dockerfile's `|| true` is scoped to the uninstall — as written it was `(install && uninstall) || true`, so a failed dependency install produced a green layer and an image with no onnxruntime. Four new regression tests. Full backend suite failure set verified identical to origin/main; frontend 140 green; tsc and eslint clean. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(faces): 12 more defects from review round 2 — cross-event purge, leaks, lifecycle (#1074) Second Codex round on the same diff, now including round 1's fixes. Twelve findings, seven P1. Again none were false positives. SECURITY, AND MINE FROM ROUND 1: the bulk-delete face purge iterated the raw `photoIds` from the request instead of the event-scoped `photos` rows the handler had already validated. purgePhotoFaces has no event scope of its own, so an editor could pass another gallery's photo id and delete its face data — even though the photo deletion right below it was correctly scoped. Fixing one thing and introducing another is exactly why the second round was worth running. ANOTHER VISIBILITY LEAK, same class as the one round 1 fixed: /people returns scan progress, and getScanStatus counted every photo with a face_status — including hidden ones. Guests could read the hidden-photo count off the progress bar while the people list and covers beside it were properly scoped. Now scoped by the same predicate, with the caller passing its audience. RECLUSTER, ROUND 1'S FIX WAS INCOMPLETE. I made suppression follow every descendant but still copied the flags from the majority ANCESTOR. When reclustering merges a visible named person with a hidden one, the majority ancestor is often the visible one — republishing the hidden person's photos. Suppression is now OR-ed across every ancestor contributing faces. The name also now goes to the genuine largest descendant; the previous code took whichever cluster came first in map order, which the comment already claimed it did not. LIFECYCLE. Face data is excluded from backups and exports, but photos. face_status came across intact, so a restored install claimed every photo was scanned while holding no faces — and the worker only claims 'pending', so it stayed that way forever. Now: the SQLite backup requeues in the dump, restore requeues after the pool reinit (the Postgres path cannot rewrite rows inside pg_dump), the portable importer purges LOCAL face tables (they were excluded from the replace list, so another instance's embeddings survived an import with FK checks suspended) and requeues, and archiving disables detection so a restored archive is honestly off rather than enabled-and-empty. WRITE PATHS. Only processPhoto enqueued. The synchronous upload path (chunked-upload completion, watch-folder) left photos unscanned, and replacePhoto kept the OLD image's faces on a row now pointing at a different picture — stale identities shown on the new photo. FRONTEND. PeopleSheet and the admin manager rendered centred thumbnails and ignored the bbox, so on group photos the avatar showed whoever stood in the middle and two people from one photo were indistinguishable — in the manager whose entire job is telling faces apart. The crop maths is now one shared helper (faceCrop.ts) so the three surfaces cannot drift again. Full-page layouts (gallery-premium, gallery-story) render their own lightbox and never received the people props. Backend failure set verified identical to origin/main; frontend 140 green; tsc and eslint clean. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * fix(faces): round 3 — five of round 2's fixes were wrong or no-ops (#1074) Third and final Codex round. Eight findings, four P1 — and the important part is that FIVE of them are defects in round 2's fixes, not in the original code. - The sync-upload enqueue I added was a silent no-op. It queried through `trx` after the transaction had already been committed, which throws "Transaction query already complete" straight into the catch I had wrapped it in. Chunked uploads and watch-folder imports were still never scanned, and the code read as though they were. Uses `db` now. - The post-restore requeue ran BEFORE the files were restored, in both the portable importer and the native restore. The face worker is live during a restore, so it could claim those rows and scan the previous instance's files, or fail them for originals not yet on disk — with nothing to requeue them afterwards. Both now run after file restoration; the native one is extracted into requeueFaceScans() and called from the full and database-only paths. - The admin face crop mixed coordinate spaces: an original-pixel bbox scaled against the THUMBNAIL's natural size. The API now returns the source dimensions alongside the box, so there is one space to reason about. - Forwarding people props through layoutProps did not make them work — the full-page layouts never destructured them. GalleryStoryLayout now threads them to its own lightbox. Genuinely new findings, all in the same class as ones already fixed: - releaseToPending updated unconditionally, so a photo purged while its sidecar request was in flight came back as 'pending' and was rescanned — biometric rows reappearing after the purge reported success. Round 2 fixed exactly this on the COMMIT path and I did not carry it to the retry path. Now guarded on 'processing'. - purgePhotoFaces left face_status alone, so a worker mid-scan still satisfied its commit guard and could write fresh faces into a photo being deleted — orphans, since the FK cascade is inert on SQLite. It now clears the claim as part of the purge. - Phase 3 was unreachable: the migration seeds face_auto_categorize_enabled false and nothing could ever write it, so the rule engine and its undo endpoint returned "disabled" in every real flow. Added GET/PUT and a toggle on the admin card, EN + DE. NOT fixed, deliberately: GalleryPremiumLayout uses yet-another-react-lightbox rather than the shared PhotoLightbox, so person chips there are a real port rather than a prop forward. Recorded as open rather than bodged. Backend failure set identical to origin/main; 41 face tests and 140 frontend tests green; i18n audit reports EN and DE complete at 71 keys. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * feat(faces): block face recognition on the all-in-one image (#1074, #1042) The single-container image cannot run this feature, so it is refused there rather than left to degrade. WHY, since the reason is not obvious from the code: the AIO image runs the backend, the frontend, SQLite and every background worker inside one container aimed at "one photographer plus guests browsing". It has no Redis, SQLite gives it a single writer, and it contains no ML sidecar to talk to. Face detection would add a second image-processing pipeline competing with Sharp for the same CPU and memory. That failure is not loud — the install just becomes slow and looks broken, which is the worst possible shape for a deployment whose whole promise is one container and no decisions. Gated on an explicit PICPEAK_SINGLE_CONTAINER marker, NOT inferred from SERVE_FRONTEND or a SQLite path: plenty of legitimate multi-container setups serve the frontend from the backend or run SQLite, and none of them should lose the feature by accident. Three layers, because the first is the only one that enforces: - faceSettings.isFeatureEnabled() returns false before consulting the flag, so a database restored from a full deployment with `faces` enabled still cannot switch it on here. - The feature-flag API forces `faces: false` in both directions, so the admin UI reflects reality instead of offering a switch that refuses to stay on. - The Features tab renders the card disabled with a plain-language reason, read from a new `single_container` field on /admin/system/version (an endpoint the admin UI already calls). Documented in ml/README.md and .env.example. Three tests pin the behaviour, including that the marker only accepts explicit truthy values. NOTE FOR PR #1068: this expects `Dockerfile.aio` to set `ENV PICPEAK_SINGLE_CONTAINER=true`. That one line lives on that branch and is not in this commit — until it lands, an AIO build would still offer the feature. Worth adding alongside the `Limits` section of docs/single-container.md. 44 face tests green; EN + DE complete at 72 keys. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc * test(faces): pin the bbox coordinate space with a real scale factor (#1074) The coordinate-space bug — boxes stored in preview space while every consumer reads them as original-image pixels — had no test, and could not have been caught by the ones that existed: every photo in the demo gallery is 750px, so the scale factor was always exactly 1.0 and the correction never executed. Verified by hand first, on a real 4000x3000 upload with the face placed off-centre so a wrong crop would be unmistakable. Before the fix the stored box was 1493,204 (preview space, face actually at x≈2850-3618); after, 3110,426 — a factor of 2.083, exactly 4000/1920, landing inside the face. The admin crop then resolved to left=-395px/top=-46px on a 64px window, which is the face centred. That verification is now a test rather than a memory. Three cases: a 4000px photo must scale by 4000/1920, a 1920px photo must NOT change (the case that hid the bug), and a row with no width must fall back to unscaled rather than storing NaN. Note for anyone extending these: jest hoists mock factories above the file, so anything they close over has to be `mock`-prefixed. Getting that wrong fails at transform time with a message that does not name the variable. 47 face tests green. Claude-Session: https://claude.ai/code/session_01Ra4hcsYiKuQLbbRsg6EjAc --------- Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>	2026-08-18 22:37:28 +02:00
Paul Nothaft	8e3573788b	feat(downloads): per-gallery download resolutions (#858) (#1022) ... Clients who need smaller files no longer make the photographer re-export. Two capabilities, both off by default. STANDARD RESOLUTION — the size a gallery hands out for every ordinary download (single, selected, download-all). Global default in Settings, overridable per gallery with the NULL=inherit tri-state. The pre-built download-all zip is built AT the standard resolution, so changing it invalidates those archives, including a fan-out to inheriting galleries. RESOLUTION PICKER — opt-in modal letting guests choose a different size. Custom archives are built as a DB-backed job the client polls, never cached. The picker never offers a size above the standard, and Original reappears only when the admin explicitly allows it. Resize is fit:'inside' + withoutEnlargement — aspect preserved, never upscaled — applied before the watermark, since the mark is sized relative to its input. Three rounds of external review hardened this: job archives are bound to the requester's visibility scope and re-validated at delivery, the streamed download-all path applies the cap, queue admission is bounded, and rejected resolutions no longer inflate download stats. Closes #858.	2026-08-11 09:46:46 +02:00
Luca	2e495d7c48	feat(transfers): add PicTransfer — cross-event file transfers (#998) ... Closes #997. Send original files from any event as a token-protected download link, with an optional client-upload channel. Strictly opt-in behind a new `transfers` feature flag, default OFF. Migrations 170-172 (transfers, transfer_files, transfer_extra_files, transfer_uploads, transfer_recipients, transfer_downloads, default settings and two email templates) — all hasTable/hasColumn-guarded and idempotent, with destructive statements confined to down(). Backend: transferService (CRUD, 256-bit download token, 6-char upload token, cross-event ZIP streaming of originals), admin CRUD routes, and two public token routes. transferCleanupService runs an hourly retention sweep; source-event photos are never touched. All three routers fail closed via requireFeatureFlag('transfers'). Review closed two ownership blockers, both the same root cause — permissions used where ownership was needed: - photoIds arrived from the request body and were validated only for existence, so a scoped admin could bundle any event's originals and hand them out through the public download token. filterOwnedPhotoIds now resolves ids to their events and gates them through filterOwnedEventIds, on both the create and add-files paths. - The transfer list was unscoped and carried each row's download token, so any admin with events.view could read another's token and fetch their originals. The list is now scoped by created_by, the token/url fields are stripped from the list payload, and a single router.use('/:id', requireTransferOwnership) covers all twelve /:id routes, 404ing foreign and missing alike. The admin photo picker filters its event list to the same rule, so the UI stops offering picks the API would discard. Fork-PR workflows had not been approved since the fix commits, so the PR's green checks were stale against the pre-fix head. Verified by dispatching tests.yml against the actual head: backend and frontend both green. Follow-up: neither ownership guard has a regression test yet. Co-authored-by: Luca-Timo <Luca-Timo@users.noreply.github.com>	2026-08-09 13:40:03 +02:00
Luca	165cebdb5c	feat(accounting): re-bill proof attachment, CRM panel & hours↔re-bills cross-add (#979) ... Closes #866. Three features, all behind the `incomingInvoices` feature flag: 1. Attach the stored supplier proof PDF to the client-invoice email when a captured invoice is re-billed/passed through, as a SEPARATE attachment so invoice immutability holds. Global default (off), per-customer tri-state override, and per-file selection in a new Send dialog. A missing proof at issue time stamps inbound_documents.proof_attach_error rather than silently dropping, and never blocks the send. Proof filename is a configurable template with {INVOICE} {SUPPLIER} {YEAR} {MONTH} {SEQ}/{SEQ:0Nd} tokens. 2. Re-bills & passthrough panel under CRM → Customer, grouped Open/Sent/Paid with status derived from the linked invoice lifecycle rather than a duplicated column. 3. Cross-add dialog rolling open hours and open re-bills into one invoice, symmetric from both entry points. The two stay distinct, contiguous line groups — never merged into shared line items. Migration 169 is additive, hasColumn-guarded and idempotent. Review (two rounds) closed two concerns: - Storno stranding: nothing cleared inbound_documents.billed_invoice_id when a covering invoice was cancelled, so a Storno'd re-bill showed as Open in the new panel while every billing path filters on that column being NULL — the supplier cost could never be re-billed. releaseRebillsForCancelledInvoice now detaches the linkage on both invoice-cancel paths, with a regression test on the issued-cancel path. - Permission gating: the new controls rendered on data presence alone while their endpoints require accounting.view / accounting.manage / customers.edit. Now gated at both the query and render layers. Known follow-up: two cross-add counter queries are gated on a permission their endpoint does not check (HoursSection.tsx:174, CustomerCrmPanels.tsx:270) — degrades safely, one line each.	2026-08-03 22:03:31 +02:00
Paul Nothaft	219d07b04a	feat(auth): OIDC logout-to-IdP — phase 3 (#798) (#865) ... * feat(auth): OIDC logout-to-IdP — phase 3 (#798) RP-initiated logout behind a new oidc_logout_from_idp setting: logging out of PicPeak also ends the IdP session. The SSO callback stores the raw ID token in an HttpOnly cookie (also the marker that the session came in via SSO — local-password sessions never bounce to the IdP); /logout builds the end_session URL from discovery metadata with id_token_hint + post_logout_redirect_uri + client_id and returns it as ssoLogoutUrl for the frontend to navigate to. Any failure (no end_session_endpoint, IdP unreachable, feature off) degrades to the plain local logout. Settings surface exposes the toggle plus the computed post-logout redirect URI to register at the IdP. Session timeouts deliberately stay local-only. 6 integration tests over the mock IdP; live-verified against Keycloak 26 (logout ends the Keycloak session, no confirmation prompt). * fix(auth): harden the SSO logout marker cookie (#798 phase 3) Codex review round 1: - Derive the oidc_id_token cookie options from the shared cookie policy (COOKIE_SAMESITE / COOKIE_DOMAIN / secure resolution) — hardcoded Lax meant split-origin deployments running on SameSite=None never sent the marker to the cross-site /logout XHR, silently disabling logout-to-IdP. - Oversized ID tokens (>3.9KB) now store a bare 'sso' marker instead of no cookie, so the claimed client_id-only end-session fallback actually happens; /logout only passes the value as id_token_hint when it is a real JWT. - establishAdminSession clears any stale marker on every fresh login — sessions can die without /logout (deactivation, expiry, restore), and a surviving marker would bounce a later local-password session to the IdP. The SSO callback re-sets the marker for its own session. Tests: oversized-token marker + hint-less end-session URL, stale-marker cleared on local login; helper updated for the clear+set cookie pair. * fix(auth): validate the logout hint against the current OIDC config (#798 phase 3) Codex review round 2: an ID token stored at login can outlive an issuer/client config change; sending it to the newly configured IdP as id_token_hint strands the user on the IdP's error page (providers validate iss/aud on the hint). buildEndSessionUrl now decodes the hint (no verification — routing only): different issuer → skip the round-trip entirely (the session belongs to another IdP); same issuer but changed client → keep the round-trip, drop the unusable hint. Two tests pin both paths. --------- Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>	2026-07-24 11:42:09 +02:00
Paul Nothaft	f8a95d29d2	feat(auth): OIDC role mapping + login policy — phase 2 (#798) (#854) ... * feat(auth): OIDC role mapping + login policy — phase 2 (#798) Role mapping: configurable dot-path roles claim (Keycloak realm_access.roles, Authentik/Pocket ID groups, Entra roles), IdP-value → PicPeak-role mapping table validated against the roles table, re-evaluated on every SSO login with highest-priority-wins on multiple matches. The last active super_admin is never demoted. Optional require-mapped-role policy refuses logins whose token maps to no role (sso_error=no_role). Login policy: oidc_disable_local_login makes the API refuse password logins (403 LOCAL_LOGIN_DISABLED) and the login page render SSO-only; only effective while SSO is enabled+configured, and OIDC_BREAK_GLASS=true always re-opens local login. Public settings expose the EFFECTIVE flag only. Settings UI: Role-mapping card (claim path, mapping rows editor, strict toggle) and Login-policy card with break-glass hint, EN+DE. 14 new integration tests over the mock IdP. * fix(auth): harden phase-2 review findings (#798) - memoize the scrypt-derived OIDC key and serve /public/settings from a 10s-TTL flag cache — the unauthenticated endpoint no longer pays a 13-key config read + blocking scryptSync per request (login route still checks uncached) - make the last-super-admin demotion guard atomic (FOR UPDATE on the active super rows) — concurrent mapped callbacks could previously both count 2 and demote both supers - own-property lookup in role mapping: IdP values like `constructor` now count as unmapped instead of corrupting the roles query - SsoTab clears oidc_disable_local_login in the same save that turns SSO off — the full-form payload otherwise hit the server-side 400 * fix(auth): guarantee break-glass reachability for SSO-only mode (#798) - wire OIDC_BREAK_GLASS and OIDC_ENCRYPTION_KEY through the quick-start docker-compose.yml env allowlist (production compose already passes .env via env_file) and document both in .env.example - refuse enabling oidc_disable_local_login unless an active local-password super_admin exists: OIDC_BREAK_GLASS only re-opens the password route, which OIDC-owned accounts can never use, and settings.edit is super_admin-only — an all-OIDC instance would be unrecoverable during an IdP outage * fix(auth): close SSO-only lockout gaps from review round 3 (#798) - role sync never demotes the last active LOCAL-password super_admin (an OIDC-owned super does not count as break-glass), and isLocalLoginDisabled() disarms itself when no such account remains — self-healing against manual demotion/deactivation/deletion paths - the local-super save-time check now validates the MERGED state, so re-enabling SSO with a stored disable flag is checked too - ALL oidc_* keys are reserved from the generic settings upserts/reads (prefix match) — policy and mapping invariants can only go through the validated PUT /sso - /admin/login/mfa re-checks the policy so an mfa_pending token minted before the flip cannot complete into a local session --------- Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>	2026-07-22 20:59:19 +02:00
Paul Nothaft	ed5fc5ad5c	feat(auth): OIDC SSO for admin users — phase 1 (#798) ... Authorization-code + PKCE against a single configurable IdP via openid-client v5, with JIT provisioning. Verified end-to-end against a real Keycloak 26 (realm + confidential client + verified-email user): settings → discovery test → login button → Keycloak → dashboard. Backend: - migration 162: admin_users.auth_provider ('local' default) + external_subject, composite unique index - oidcService: settings-driven config (client secret AES-256-GCM at rest, mfaService pattern, OIDC_ENCRYPTION_KEY fallback JWT_SECRET), cached discovery, sub-based identity binding — email linking of existing admins only with email_verified=true; JIT behind oidc_autoprovision with configurable default role and an unusable random password hash - GET /api/auth/admin/sso/login + /callback: state/nonce/PKCE verifier cross the redirect in a 10-min signed httpOnly SameSite=Lax cookie; the callback reuses the local login's session establishment (completeAdminLogin split into establishAdminSession + JSON wrapper) so SSO sessions are identical downstream; every failure lands on /admin/login?sso_error=<key> as a translated toast - dedicated /admin/settings/sso GET/PUT/test endpoints (secret write-only, redacted to a set-flag; registered ABOVE the generic /:type matcher which would shadow them); oidc_client_secret added to the reserved keys stripped from generic settings upserts - public settings expose only oidc_enabled + oidc_button_label for the login page Frontend: - Settings → Single Sign-On (OIDC) tab: issuer/client/secret, scopes, autoprovision + default role, button label, enable toggle, redirect URI copy box, server-side discovery test - login page: SSO button (custom label) when enabled; sso_error query param surfaced as translated toasts; EN+DE i18n Tests: 11 integration cases against an in-process mock IdP (real discovery/JWKS/PKCE/ID-token validation) — JIT on/off, sub-vs-email binding, unverified-email rejection, deactivated admin, missing/forged state cookie, nonce tamper, secret encryption round-trip, disabled 404. MFA is delegated to the IdP on the SSO path; local login stays available as break-glass. Role-claim mapping and logout-to-IdP follow in phase 2/3.	2026-07-16 08:54:26 +02:00
Luca	0ed3bbefa1	chore(messages): describe the feature as 'unified' rather than by a third-party product name	2026-07-07 11:10:00 +02:00
Luca	b96ad36f5d	fix(messages): make the Messaging feature flag toggleable ... The Messaging FeatureCard was a hardcoded-disabled 'roadmap' placeholder (no-op toggle), so the messaging flag could never be turned on — the Messages sidebar item + page stayed hidden. Wire the toggle to setFlag, mark it 'new', and describe the actual admin Messages client.	2026-07-07 11:06:16 +02:00
Paul Nothaft	96e3c68b9d	feat(admin-ui): TOTP MFA enrollment + two-step login; remove stub 2FA toggle ... Frontend for #738. - mfa.service.ts + MfaSettingsCard (Settings → General → Admin Account): per-user setup (QR + manual secret + verify), recovery codes shown once (copy/download/confirm), status, regenerate, disable. Renders for super_admin (closes #735). - Two-step login in AdminLoginPage: on {mfaRequired,mfaToken} swap to a code step (TOTP or recovery), call /auth/admin/login/mfa; handle MFA_INVALID / MFA_SESSION_EXPIRED / 423 lockout. - Removed the non-functional global enable_2fa checkbox from SecurityTab (and its persistence) — replaced with a note pointing to per-user setup. - en + de i18n. Verified live in-browser: enroll (QR→code→recovery codes), logout, and the two-step challenge into the dashboard as super_admin.	2026-07-03 11:44:07 +02:00
Paul Nothaft	15be3b8d32	Merge pull request #667 from Luca-Timo/feat/workflow-engine ... feat: admin-configurable workflow engine + dunning/Mahngebühr rework (RFC — feedback welcome)	2026-06-25 19:17:03 +02:00
Paul Nothaft	ab501459a4	feat(analytics): pluggable trackers — Umami + Rybbit + Custom (#663 Phase 1) ... Implements the hybrid scope agreed on in #663: two native adapters (Umami + Rybbit) for trackers we'd keep maintained, plus a Custom script-paste mode for everyone else (Plausible, Matomo, Pirsch, GA4, GoatCounter, Fathom, Cloudflare Web Analytics). Phase 2 (Plausible native, deeper metrics) explicitly deferred until someone asks. ## Architecture **Backend `services/trackers/`**: - `TrackerAdapter` shape (single method): `fetchDeviceBreakdown` → `{ desktop, mobile, tablet } | null`. Null = route falls back to access_logs heuristic. - `umamiAdapter.js` — extracted from the `services/umamiClient.js` that landed in #662. Same 10 test contract preserved. - `rybbitAdapter.js` — new. Hits `/api/site/{id}/breakdown?dimension= device` with Bearer auth, accepts both bare-array and `{data:[...]}` envelope variants, tolerates `sessions`/`visitors`/`value`/`count` metric keys. - `customScriptSanitiser.js` — sanitize-html with a tracker-tight allowlist (`<script>` / `<noscript>` / `<link rel=preconnect| dns-prefetch>` / `<meta>`). Strips event-handler attributes, `javascript:` and `data:` URLs. - `index.js` factory: `resolveAdapter()` reads `analytics_tracker_provider` setting → dispatches. Back-compat: when provider is unset, infers `umami` from the legacy `analytics_umami_enabled` flag so #662 installs keep working without an admin touching settings. **Backend routes**: - `adminDashboard.js /analytics`: now goes through `resolveAdapter()`. Old `fetchUmamiDeviceBreakdown` direct import removed; both `umamiClient.js` and its test file deleted (replaced by the adapter shape). - `adminSettings.js PUT /analytics`: validates the new `analytics_tracker_provider` enum, sanitises any incoming `analytics_custom_head_html` on save via the sanitiser. Masks the new `analytics_rybbit_api_key` on every GET — same pattern as Umami's API key and recaptcha secret. - `publicSettings.js`: emits `analytics_tracker_provider`, `rybbit_url`/`rybbit_website_id` (only when provider=rybbit), and the pre-sanitised `analytics_custom_head_html` (only when provider=custom). Legacy `umami_*` fields stay for back-compat. **Frontend**: - `analytics.service.ts` reworked into a provider-aware shape. `initialize({provider, ...config})` dispatches to Umami / Rybbit / Custom / None. `track()` calls dispatch to `window.umami.track` / `window.rybbit.event` / no-op based on the loaded provider. - `App.tsx` `AnalyticsBootstrap` reads `analytics_tracker_provider` from public-settings and routes to the right `initialize` call. Legacy `umami_enabled`-based path preserved as fallback when the new field is missing. - `AnalyticsTab.tsx` (Settings → Analytics) reworked with a "Provider" dropdown switching between None / Umami / Rybbit / Custom panels. Each panel renders its own config fields; Custom panel surfaces an explicit CSP-reminder banner. - `useSettingsState.ts` shape extended with `tracker_provider`, `rybbit_url`/`rybbit_website_id`/`rybbit_api_key`, `custom_head_html`. Save mutation keeps `umami_enabled` in sync with `tracker_provider==='umami'` for back-compat with downstream consumers (publicSettings shape, embedded iframe). - `publicSettings.service.ts` type extended. **i18n**: EN + DE for the provider heading + description + dropdown options + Rybbit fields + Custom HTML field + CSP warning. ## Custom mode — script execution caveat When the gallery `<head>` receives the custom HTML, simply assigning innerHTML to a container element wouldn't execute the embedded `<script>` tags (per the HTML spec, dynamically-inserted scripts via innerHTML are non-running). `analytics.service.ts:120-130` re-creates each `<script>` element manually so the browser actually evaluates it. Non-script nodes (link, meta, noscript) move in directly. ## Tests **Backend** (42 cases, all pass locally): - `umamiAdapter.test.js` (10) — pinned from the original `umamiClient.test.js`: missing-config / URL shape / encoding / payload normalisation / `laptop`→`desktop` / unknown buckets / empty / non-2xx / invalid JSON / network error. - `rybbitAdapter.test.js` (9) — same shape adapted for Rybbit: bare-array + envelope payload, `sessions`/`visitors`/`dimension` key tolerance, encoding, failure modes. - `trackerFactory.test.js` (6) — resolves null for `none`/`custom`, correct adapter for `umami`/`rybbit`, back-compat path via legacy `analytics_umami_enabled`, garbage-provider defensive null. - `customScriptSanitiser.test.js` (12) — Plausible-style passthrough, Umami-style passthrough, inline body passthrough, `<noscript>` allowed, `<link rel="preconnect|dns-prefetch">` allowed, `<link rel="stylesheet">` stripped, disallowed tags stripped, `javascript:`/`data:` URLs stripped, `on*` event handlers stripped, defensive on malformed input. - `analyticsDateMerge.test.js` (5) — preserved from #662. **Frontend**: full 84-case vitest suite green; tsc + eslint clean on changed files. Adapter changes are narrow refactors of code covered by backend tests; no new analytics-page unit test added. ## End-to-end smoke (dockerised backend + my changes mounted) ``` test 1 (back-compat: no provider, umami_enabled=true) → factory returns umami adapter, /analytics returns devicesSource:access_logs (umami fetch to fake host fails gracefully). ✓ test 2 (invalid provider value) → 400 "analytics_tracker_provider must be one of: none, umami, rybbit, custom" ✓ test 3 (save custom HTML with XSS payload) → stored sanitised: `<script>alert(1)</script>evil<script async defer data-domain="x.com" src="https://plausible.io/js/script.js"></script>` (<div> stripped; script tags survive but CSP `script-src 'self'` still blocks inline + non-allowlisted external at runtime) ✓ test 4 (public-settings exposes the provider switch) → `analytics_tracker_provider: 'custom'`, `analytics_custom_head_html: '<sanitised>'` ✓ ``` ## Out of scope (next discussions) - **Plausible native** — covered via Custom mode for now; native is Phase 2 if someone explicitly asks. - **CSP "trusted domains" admin input** — Phase 1.5. For now operators add their tracker domain to nginx/proxy CSP manually; the new CSP-reminder banner in the Custom panel makes that clear. - **Refactor `(window as any).umami.track(...)` direct calls** in PhotoLightbox/PhotoGrid to go through `analyticsService.track()` so events fire on the right tracker. Currently a no-op when Umami isn't loaded; functional but not optimal. Closes #663 Phase 1.	2026-06-23 18:11:58 +02:00
Paul Nothaft	7534447b6c	fix(analytics): admin dashboard reads correct fields + Umami device API (#661) ... Reporter @alexvaltchev hit three independent bugs on the Analytics Dashboard. All three fixed in one PR; pluggable-tracker support (Rybbit, Plausible, etc.) left for a separate discussion. ## Bug A — Summary cards showed 0 Two layers, both fixed. **Frontend** (`AnalyticsPage.tsx:142-149`): the cards summed `chartData[].views/uniqueVisitors/downloads`. The backend now (and already) emits a dedicated `totals` object computed via separate COUNT queries, which is what the cards should read. Postgres returns counts as strings, so coerce via `Number()`. **Backend** (`adminDashboard.js:268-282`): the chartData merge used `dateObj.date === row.date`. On Postgres, pg's driver auto-converts `DATE(timestamp)` to a JS Date object — the string-equality match failed silently and `chartData` stayed all-zero on every Postgres install with traffic. Added a `normaliseDateKey()` helper that returns YYYY-MM-DD regardless of driver shape, plus `Number()` coercion on the counts. SQLite path unchanged. ## Bug B — "Umami Not Configured" banner despite valid config `AnalyticsPage.tsx:90` did `settings.reduce(...)` on the `/admin/settings` response. That endpoint returns a key/value **object** (verified at `adminSettings.js:108-149`), not an array, so `.reduce` threw `data.reduce is not a function` and the catch silently rendered the "Not Configured" banner even on perfectly-configured installs. Read the umami keys directly off the response object. ## Bug C — Device breakdown 0/0/0 Two-pronged fix. **Primary path — Umami device API** (`services/umamiClient.js`, wired into `adminDashboard.js`). When the admin provides an Umami v2 API key (new setting `analytics_umami_api_key`), the backend fetches the per-period device breakdown from Umami's `/api/websites/:id/metrics?type=device` endpoint. Umami tracks devices natively — far more accurate than our coarse user-agent heuristic. The new `devicesSource` field in the response lets the UI hint at where the numbers came from. **Fallback hardening — local heuristic** (`adminDashboard.js:296-320`). The existing access_logs `LIKE '%Mobile%' / '%Tablet%'` query stays in place as a fallback for installs without Umami. Hardened with: `whereNotNull('user_agent')` skips rows we never captured a UA on, `Number()` coercion on COUNT results (pg returns strings), and a guard against divide-by-zero when access_logs is empty. ## API key handling Mirrors the existing recaptcha-secret pattern: stored plaintext in `app_settings`, masked as `••••••••` on every GET via the existing `adminSettings.js` GET handlers, and the frontend save mutation silently drops the masked sentinel so re-saving without typing a new key preserves the stored value. ## End-to-end smoke (dockerised backend with my fixes applied) ``` chartData total views: 27 ← previously 0 (date merge broken on PG) totals: {'views': '27', 'downloads': '3', 'uniqueVisitors': '1'} devices: {'desktop': 100, 'mobile': 0, 'tablet': 0} ← was 0/0/0 devicesSource: access_logs ← falls back correctly analytics_umami_api_key (GET /settings/analytics): •••••••• ``` ## Tests **Backend** (15 new cases): - `umamiClient.test.js` (10): missing-config → null, URL shape + `x-umami-api-key` header, websiteId URL-encoding, `{x,y}` → percentages, `laptop` → `desktop` mapping, unknown buckets dropped, empty payload → null, non-2xx → null, invalid JSON → null, network error → null. - `analyticsDateMerge.test.js` (5): YYYY-MM-DD string pass-through, ISO timestamp slice, JS Date (pg shape) → YYYY-MM-DD, null/empty → null, coercion for unexpected types. **Frontend**: full 84-case vitest suite still green (no analytics unit tests existed before; not adding any here — the changes are narrow and the unit-level confidence comes from the type system + the backend smoke above). Closes #661 (bugs A + B + C). Rybbit / pluggable tracker support is the next conversation per the issue author's follow-up.	2026-06-23 17:37:41 +02:00
Luca	ff478619b5	feat(workflows): add workflows feature flag + Features-tab toggle ... New opt-in 'workflows' master flag (default off) across the backend KNOWN_FLAGS/DEFAULT_FLAGS and the frontend FeatureKey union, context defaults, and a new Automation section card in the Features tab. Gates the upcoming Workflows admin area and the engine runtime. en/de i18n added (DE native).	2026-06-23 01:53:03 +02:00
Paul Nothaft	80e8ec5bc7	Merge pull request #650 from the-luap/fix/whatsapp-template-params-647-followup ... feat(whatsapp): admin-selectable template parameters + reorder (#647 follow-up)	2026-06-21 21:35:09 +02:00
Paul Nothaft	cde028e919	Merge pull request #649 from the-luap/fix/branding-customcss-preset-drop-645 ... fix(branding+whatsapp): preserve customCss through preset switches (#645) + admin-pinned WhatsApp template language (#647)	2026-06-21 21:33:29 +02:00
Paul Nothaft	16055cdc41	feat(whatsapp): admin-selectable template parameters + reorder (#647 follow-up) ... Reporter @Rekoo-PS confirmed the language fix unblocked sending, then hit a second gap: their template uses only `{{1}} = event_name` + `{{2}} = gallery_link`, but the legacy `buildComponents` hardcoded all 5 positional values from the `gallery_ready` shape (customer_name, event_name, gallery_link, password_line, expiry_date). Meta rejected with a parameter-count mismatch even after the language matched. This adds a per-config slot list — which built-in values to send, and in what positional order — so admins can match templates of any shape without code changes. ## Schema (migration 138) Additive `template_params` TEXT column on `whatsapp_configs` (default empty string = legacy 5-slot behaviour for existing installs). Stored as a JSON-serialized array of slot keys: `customer_name`, `event_name`, `gallery_link`, `password_line`, `expiry_date`. Unknown / duplicate / non-string entries are sanitized out at read time. ## Processor - `parseTemplateParams(raw)` — defensive parser; falls back to the 5-slot default on empty / malformed / all-invalid input. - `buildComponents(data, metaLang, params)` — emits ONLY the listed slots in the listed order, computed via a small switch on slot key. The password line still receives the locale-specific 🔒 label and the empty-when-no-real-password sentinel handling. - Processor reads `config.template_params` once per cycle and passes the parsed array to `buildComponents` per message. ## Admin route - GET surfaces `template_params` as the parsed array (default 5-slot when null/empty). - PUT round-trips the incoming array through `parseTemplateParams` before persisting, so the stored value is always the canonical sanitized JSON. - Test send rebuilt to use the same `buildComponents` path so the admin's test message matches their configured slot shape — a reporter who configures 2 slots gets a 2-parameter test send, not the legacy 5-parameter payload. ## UI - `WhatsAppTab` gets a checkbox + up/down list under the Template language field. Each slot shows its current `{{N}}` position when checked, an em-dash when unchecked. Live preview below the list: "Your template will receive: {{1}} = event_name, {{2}} = gallery_link". - EN + DE i18n for the field labels, hint, preview, and per-slot human-readable names. ## Tests - 17 unit tests in `__tests__/utils/whatsappBuildComponents.test.js` covering: parseTemplateParams sanitization (unknown keys, duplicates, non-strings, malformed JSON, all-invalid fallback, pre-parsed array acceptance) and buildComponents shape (reporter's 2-slot case, reorder, empty list, locale-specific password label, password sentinel handling, expiry omission). - All 17 + the 34 existing networkValidation tests pass. ## Migration numbering Sits at 138 on top of PR #649's migration 137. If #646 (Live Slideshow) merges before this, #646's own 137 + 138 take precedence and this needs renumbering to 139. Coordinated via PR #646's review thread. ## Honest caveat Still no Meta Business API account on my side. Spec-built, sanitizer + shape unit-tested, lint + tsc clean. End-to-end against Meta needs the reporter (or a maintainer with an account) to verify. If a real round-trip surfaces a mismatch, drop it in #647 and I'll iterate.	2026-06-21 20:51:20 +02:00
Paul Nothaft	4fd7709596	fix(whatsapp): admin-pinned template language + Arabic locale support (#647) ... Reporter @Rekoo-PS hit three independent gaps trying to deliver an Arabic Meta template. Bundled here because they fan out from the same root cause (no first-class language config on the WhatsApp tab) and the review surfaces are tightly coupled. **1. Test send hardcoded `en_US` (`adminWhatsapp.js:141`).** Smoking gun for "I can't make it work" — Meta returned template_not_found_in_language (132001) on every test send for non-English templates, no matter what else the admin configured. Replaced with `config.template_language || 'en_US'`. **2. No `template_language` field on `whatsapp_configs`.** The only priors were per-message `data.language` (always null from our callers in `adminEvents.js:854,1188`) and `app_settings.general_default_language` (the *system UI* language, not the *template's* language registered with Meta). Migration 137 adds the column; GET + PUT surface it; the processor uses it as the highest-priority default when message_data doesn't override. Resolution order in `whatsappProcessor.processWhatsAppQueue` is now: 1. message_data.language (per-event override — caller path TBD) 2. config.template_language (admin-pinned template language) 3. app_settings.general_default_language (system fallback) 4. en_US (hardcoded last resort) **3. `LANGUAGE_MAP` + `PASSWORD_LABELS` didn't cover Arabic.** Added `ar` (Meta's single-code form per RFC; no region variant). For any language we don't enumerate (e.g. Turkish `tr_TR`, Chinese `zh_CN`, Hebrew `he_IL`), `resolveLanguageCode` now pass-throughs valid-shape codes (lowercase-language + optional underscore + uppercase-region) and forwards them to Meta as-is. If they don't match a registered template Meta returns 132001, which the test route already surfaces back to the admin via `error.message` — fail-loud, no silent fallback. Validation: - Unit smoke on `resolveLanguageCode` across 18 representative inputs (in-map, pass-through, canonicalization, rejection) — all behaviours correct. - Lint clean on all 7 changed files. - Frontend `tsc --noEmit` clean. - Migration `node -c` syntax-checked; additive + `hasColumn`-guarded so re-running is safe. Frontend: free-text input on the WhatsApp tab with EN + DE i18n. Pointing at Meta's supported-languages docs via the hint text — Meta's list grows; a hardcoded dropdown would rot. Closes #647.	2026-06-20 23:29:08 +02:00
Luca	69367b45be	feat(slideshow): gate behind a feature flag + move globals to a Settings tab ... - New `slideshow` feature flag (backend KNOWN_FLAGS/DEFAULT_FLAGS, frontend FeatureKey + context default, a toggle card under Settings -> Features -> Core). Default off; strictly opt-in. - Move the global watermark defaults off the Event Types page into a dedicated Settings -> Slideshow tab (new SlideshowSettingsPage), shown only when the flag is on. - Gate the per-event Live Slideshow card and the per-event-type preset section behind the flag too (and stop writing a type preset when it's off). - en/de strings for the feature card + settings tab.	2026-06-20 03:08:04 +02:00
Paul Nothaft	a8bb7b439f	fix(i18n): wrap WhatsApp token show/hide aria-label through t() ... i18n audit caught one straggler — the eye-icon toggle on the access-token input had a bare `aria-label={showToken ? 'Hide' : 'Show'}` that wouldn't translate for screen readers on non-English locales. Switched to `t('common.hide')` / `t('common.show')`; added the matching `common.show` key in EN + DE (common.hide already existed). The two remaining `placeholder=` literals in the WhatsApp tab are sample ID strings (`123456789012345`, `gallery_ready`, `+49123456789`) — those are identifier/value examples, not translatable English. Other PR-touched UI surfaces passed the audit clean: 30 new i18n keys across categories (5), settings.whatsapp (16), settings.features.whatsapp (2), feedback (3), and the activity-log + bell entries (4) all exist in both EN and DE.	2026-06-19 08:42:22 +02:00
Paul Nothaft	78c8e9d9f9	feat(whatsapp): WhatsApp Business API notification channel (#640 part D) ... Ports filpgame/picpeak's WhatsApp integration with substantial adaptation to fit our codebase patterns. Deliver the gallery-ready notification via Meta Graph API in addition to (or instead of) email — useful where the customer base expects WhatsApp by default. Strictly opt-in behind the new `whatsapp` feature flag. ### Backend - **Migration 136** (`whatsapp_configs` + `whatsapp_queue`). Loose-FK on `event_id` matching our `inbound_documents` / `expenses` pattern (NOT filpgame's hard FK — deleting an event shouldn't RESTRICT on stale queue rows). Composite index on `(status, retry_count, created_at)` covers the poll path. - **`whatsappService.js`**: thin Meta Graph client. Meta API version bumped v19 → v20 (filpgame's v19 deprecates Q3 2026); configurable via `WHATSAPP_META_API_VERSION` env var. Timeout dropped 10s → 8s for processor budget. Errors surface the Meta `error.code` so the processor can tell retryable from permanent. - **`whatsappProcessor.js`**: queue processor polling every 30s (configurable via `WHATSAPP_QUEUE_POLL_MS`), 10 messages per cycle, 3 retries before marking `failed`. Default language sourced from `app_settings.general_default_language` (matches our email-language resolution pattern); replaces filpgame's hardcoded `pt_BR` fallback. Falls back to `en_US` if nothing is configured. No-ops gracefully when the `whatsapp` flag is off, the config row is missing, or the access token isn't set. - **`adminWhatsapp.js`**: three routes (GET/PUT config, POST test). Gated by `requireFeatureFlag('whatsapp')` so operators who haven't enabled it can't see the surface. Access token masked as `'********'` on GET; masked values silently preserve the stored token on PUT. Enabling with no Phone Number ID, template name, or token (and none stored) fails at the validator. - **Two hook points** in `adminEvents.js`: - **Create-and-publish-in-one-step**: queues immediately after the `gallery_created` email when `!isDraft && customerPhone && waConfig.enabled`. Password from `req.body` is still in scope. - **Publish-from-draft** (`POST /:id/publish`): queues with the password the admin re-typed via PR #627's `PublishGalleryDialog`. When no password was typed (legacy API consumers without dialog), passes empty string so the password line renders blank rather than leaking the `(set at creation)` sentinel. - **`server.js`**: starts `whatsappQueueProcessor` at boot. Non-fatal if it fails to start (logged as warning). - **`feature_flags`**: new `whatsapp` flag in `KNOWN_FLAGS` and `DEFAULT_FLAGS` (default false). ### Frontend - **`featureFlags.service.ts`**: `'whatsapp'` added to `FeatureKey` union. - **`FeaturesTab.tsx`**: WhatsApp card in the Communication section (between Incoming mail and Messaging). Smartphone icon, "new" status, sidebar-hidden (no sidebar entry — config lives under Settings). - **`whatsapp.service.ts`** (new): typed client for the three admin routes. - **`WhatsAppTab.tsx`** (new): Settings tab. Form for Phone Number ID, WABA ID, access token (masked toggle), template name, and enabled flag. Separate card below for a static test send. Token masking matches the server's `'********'` sentinel — admin can edit other fields without re-entering the token. - **`SettingsPage.tsx`**: WhatsApp tab nav item gated on `flags.whatsapp` (so it shows only when the feature is enabled); render block wires `<WhatsAppTab />`. ### i18n 22 new EN + 22 new DE entries covering the Settings tab form, the Features-tab card, plus `admin.activities.whatsapp_config_updated` + `admin.notificationMessages.whatsappConfigUpdated` for the bell / dashboard surfaces from PR #637. ### Deliberately NOT included - filpgame's **password-encryption-at-rest** layer (`password_encrypted`/`password_iv`/`password_key_version` columns). Our publish-from-draft password recovery uses the admin re-type flow from #627 (PublishGalleryDialog) — no plaintext at rest. ### Setup notes for operators 1. Create a Meta Business Account + WhatsApp Business App. 2. Register a phone number and obtain `phone_number_id` + `waba_id`. 3. Create a system-user access token (long-lived recommended). 4. Submit a message template for approval. The default `gallery_ready` expects 5 body parameters: customer name, event name, gallery link, password line, expiry date. 5. Enable the `whatsapp` feature flag. 6. Enter credentials under Settings → WhatsApp, send a test, then enable delivery. ### Test plan - [x] Backend `node -c` on all new/changed files clean - [x] `tsc --noEmit` on frontend clean - [x] Backend dev container restart picks up new files, /health OK - [ ] Manual: enable `whatsapp` flag → Settings → WhatsApp tab appears - [ ] Manual: save config with masked-only token (existing token preserved) - [ ] Manual: enable=true without phone_number_id rejected at PUT - [ ] Manual: enable=true without stored or new token rejected at PUT - [ ] Manual: create-and-publish event with customer_phone → queue row inserts with message_type='gallery_created' - [ ] Manual: publish-from-draft via PublishGalleryDialog with password → queue row uses the admin-typed password in the {{4}} line - [ ] Manual: test send to a real phone with valid Meta config + approved template → Meta returns messages[0].id, toast shows the id - [ ] Manual: bell renders "WhatsApp configuration updated" in DE when the config_updated activity fires (via PR #637 smart default)	2026-06-18 22:57:22 +02:00
Paul Nothaft	eaed00fcca	Merge remote-tracking branch 'origin/beta' into fix/i18n-activity-types-comprehensive ... # Conflicts: # frontend/src/i18n/locales/de.json # frontend/src/i18n/locales/en.json	2026-06-18 21:28:18 +02:00
Paul Nothaft	997a41293e	fix(i18n): sweep Events / API Tokens / Webhooks settings tabs ... Continuing the activity-type i18n sweep from this PR: three settings tabs still had hardcoded English strings (or referenced i18n keys that didn't exist in either locale). EventsTab (Settings → Event Creation): - defaultFeedbackEnabled + defaultFeedbackEnabledHelp were referenced by the component but missing from both locales. The inline-default English text leaked through to German users. ApiTokensTab (Settings → API Tokens): - "Preview" table-header column was a bare string literal; now wraps through t('settings.apiTokens.preview'). - confirmRevoke called t() with a backtick template-literal default ("Revoke \"${token.name}\"…"). The interpolation happened at the default-string level, so the actual translated string never received the name and shipped without it. Switched to the i18next {{name}} parameter pattern with the matching value in en+de. WebhooksTab (Settings → Webhooks): - Half the tab was still hardcoded English. Wired everything through t(): toast messages (createError, updateError, deletedToast, deleteError, copied, copyFailed), Just-Created Secret card buttons (Copy, Dismiss), form placeholders (name, URL, template), advanced toggle label, filter and template help paragraphs, the filterError setter, all six table headers, the eventsSubscribed count (with proper {{count}} pluralisation), the status badge (Active/Disabled), the active/inactive title tooltips, the Deliveries link, the Delete button, and the delete-confirm dialog (proper {{name}} interpolation instead of the broken template-literal-in-default-string pattern). Added 34 new key/value pairs to each locale; counts now symmetric at events=28, apiTokens=23, webhooks=43 in both EN and DE. DE wording authored natively; tone matches the existing maintainer- voice style.	2026-06-18 21:16:30 +02:00
Luca	33d5408977	refactor(accounting): consolidate the Accounting tab into two cards + one Save ... - Box 1 "Default rates": mileage, daily allowance, hourly rate, require-proof. Hints now make the cost-vs-billing split explicit (daily allowance = expense, hourly = billing fallback). - Box 2 retitled "VAT": registration, reclaim, default invoice VAT code, and the VAT label (moved out of its own card). - Drop the third card (AccountingProfileFields deleted); the two Save buttons become one — it persists both the app_settings and the two business_profile fields (VAT label + hourly rate) together. - Rename "Per-diem" → "Daily allowance" (EN) for clarity; German keeps the established "Spesenpauschale".	2026-06-18 15:56:52 +02:00
Luca	267b121d66	feat(accounting): supplier-country tax default + configurable default output VAT code ... VAT supplier-country reclaim default: - Migration 134 adds inbound_documents.supplier_country. - categorizeInbound auto-derives tax_treatment via resolveTaxTreatment: explicit treatment wins; else country in the reclaim list → domestic, outside it → foreign_vat_non_reclaimable, unknown → domestic. Consumes the previously-stored-but-unused accounting_vat_reclaim_countries. - Triage modal gains a Supplier country dropdown (saved via updateInbound). +5 unit tests for resolveTaxTreatment. Configurable default output VAT code for new invoices: - New accounting_default_output_vat_code setting (PUT wired; getSettings/type). - Settings → Accounting dropdown to pick it. - Invoice + quote editors seed their VAT picker (rate + code) from it on a blank new document — skipping edits/conversions, never clobbering a touched value. New docs no longer silently start at 0%. i18n en + de.	2026-06-18 15:35:58 +02:00
Luca	51837c3a88	feat(accounting): invoices force-enable the Accounting master ... Invoice VAT config (codes + label) and the hourly rate now live under Settings → Accounting, so an install with Invoices must have Accounting available. - applyDependencyRules (backend adminFeatureFlags.js + frontend FeatureFlagsContext.tsx): bills on → accounting on, before the accounting→children rule so the sub-features keep their own state. - Migration 133 corrects existing installs: set the STORED accounting=true where bills is on. requireFeatureFlag('accounting') reads the raw row, so without this an upgraded install (invoices on, accounting off) would show the tab but 403 its endpoints. Idempotent; only flips on; no down. - Features tab: the Accounting card shows locked-on (disabled + hint) while Invoices is enabled. Also includes the i18n keys (en/de) for the VAT/financial settings move.	2026-06-18 15:11:11 +02:00
Luca	dc7b87bb87	feat(accounting): consolidate VAT/financial config into Settings → Accounting ... - Remove the orphaned "Default VAT rate %" from Business profile; the rates are the Accounting VAT codes. The invoice/quote VAT picker (VatRateSelect) is now code-only — options are exactly the Accounting output codes, no free-text custom rate. Off-list legacy values on existing invoices are preserved as a read-only "(not configured)" option so issued documents aren't silently changed. - Move VAT label + default hourly rate to the Accounting tab (new AccountingProfileFields card; storage stays on business_profile, own save). Wire vat_label onto the PDF VAT-line label via the issuer block (covers invoices + quotes), falling back to the locale default when blank. - Default currency stays on Business profile but becomes a normalizing dropdown (an old free-text "chf" auto-selects "CHF"; unknown values preserved). Add a moved-note callout. Strip the moved fields from the Business-profile save so it can't clobber an Accounting-tab edit.	2026-06-18 15:10:44 +02:00
Luca	97795f6d1e	feat(accounting): move Chart of accounts into Settings → Accounting ... Consolidate all accounting configuration in one place. The Chart of accounts (accounts table + category/default-account mappings) becomes a self-contained ChartOfAccountsManager rendered in Settings → Accounting, next to the VAT codes that already moved there. The /admin/accounting section is now purely operational (Incoming invoices · Expenses · Tax). The old /admin/accounting/ledger route redirects to the settings tab so bookmarks keep working; the Tax page "Configure" link points there too. ChartOfAccountsManager saves only the account keys (partial-merge safe, same as VatCodesManager), so the two never revert each other's edits.	2026-06-16 01:11:12 +02:00
Luca	4ff5b84cb6	feat(accounting): relocate VAT codes + rate maps into Settings → Accounting ... Move VAT-code CRUD and the rate→code / treatment→code maps off the Chart-of-accounts page into a self-contained VatCodesManager rendered in Settings → Accounting, so all VAT config lives in one place. CoA keeps the accounts table, default/system accounts, and expense-category maps. Both pages save disjoint key sets through the partial-merge updateSettings (CoA → account keys only; VatCodesManager → ledger_vat_map + ledger_output_vat_map only), so neither reverts the other's edits.	2026-06-16 00:45:50 +02:00
Luca	4d87684882	feat(accounting): VAT registration + reclaim-country settings in the Accounting tab ... Adds the 'VAT registration & reclaim' section to Settings → Accounting: a 'VAT-registered' toggle (charge output + reclaim input VAT) and a multi-select of countries whose input VAT is reclaimable (default domestic CH/LI). Wires accounting.service + the backend keys added earlier (accounting_vat_registered, accounting_vat_reclaim_countries). i18n en/de. The report VAT-payable math that consumes these is the next slice.	2026-06-16 00:27:17 +02:00
Luca	402dbde0a1	Merge origin/beta into feat/accounting-inbound-invoices ... Resolves the 7 feature-flag / i18n conflicts (accounting flags vs upstream's Project Overview 'projects' flag, both registered in the same files) as additive unions — accounting + incomingInvoices + expenses AND projects all coexist. Migrations slot cleanly: projects 117-121, accounting 122-129, no collisions. Frontend build + backend node --check pass.	2026-06-15 16:37:23 +02:00
Luca	31280e1f7a	feat(email): incoming mail UI - IMAP config block + Received emails tab ... Frontend for the incoming-mail feature. - Settings -> Email: an "Incoming mail (IMAP)" block under the outgoing SMTP settings (same field shape: host/port/security/user/pass/folder), shown only when the incomingMail flag is on (IncomingMailConfigCard, self-contained load/save). - A "Received emails" tab next to "Sent emails" (ReceivedEmailsPanel) listing the received_emails log with from/subject/received/status + attachment count and a link to the incoming-invoices inbox. - `incomingMail` flag in the frontend (type + context default, standalone) + a Communication-section Features card. - email.service: getIncomingConfig / updateIncomingConfig / listReceived. - i18n: settings.features.incomingMail, email.incoming, email.received (EN+DE). Verified: tsc --noEmit clean (0 errors); en/de JSON valid; npm run build green.	2026-06-11 16:19:55 +02:00
Luca	2b7495e4dc	feat(accounting): Accounting settings tab (km / per-diem rate, require-proof) ... New Settings -> Accounting tab (gated by the accounting flag) to edit the km rate, per-diem rate and the "require proof for expense" toggle (reads GET / writes PUT /admin/settings/accounting). Rates are CHF, stored as integer minor units; carries the "verify with your Treuhaender" disclaimer. Wired into SettingsPage (TabType, keys, flag-gated nav item, render) + the features barrel. i18n: settings.accounting.* (EN + DE, DE native). Verified: tsc --noEmit clean (0 errors); en/de JSON valid; npm run build green.	2026-06-11 12:59:36 +02:00
Luca	c59df52d40	feat(accounting): split Incoming invoices vs Expenses - flags, schema, settings (stage 1) ... Foundation for separating external supplier invoices from internal expenses, per design review. This stage is additive + buildable; the service/route/UI data rework follows in stage 2. - Migration 126: incoming invoices own their payable on inbound_documents (supplier_paid/at/method/ref + disposition + tax_treatment + booking event_id + category_id + re-bill markup/linkage); expenses gain kind (amount/mileage/ per_diem) + quantity + snapshotted rate_minor. Additive, hasColumn-guarded. - Migration 127: seed `expenses` feature flag (default off) + accounting app_settings (accounting_km_rate_minor=70, accounting_per_diem_rate_minor=0, accounting_require_proof=false). - Backend: `expenses` added to feature-flag known/defaults/dependency (forced off when the accounting master is off); new PUT /admin/settings/accounting (read via the generic GET /:type). - Frontend: `expenses` flag (type + context + dependency); Features tab gets an Expenses sub-card; the Expenses sub-nav + route now gate on `expenses` (not incomingInvoices); AccountingIndex prefers inbox -> expenses -> tax. - i18n: settings.features.expenses.* (EN + DE). Verified: node -c; migration 124->126->127 harness (new columns, flag, settings + idempotency); en/de JSON valid; npm run build green.	2026-06-11 12:24:53 +02:00
Luca	2c351bf0c9	refactor(accounting): make Accounting a master flag with sub-toggles ... Replaces the earlier peer-`accounting` flag (which only *conditionally* relocated Tax) with a cleaner top-level master + sub-toggle model, per design discussion: - `accounting` = explicit top-level MASTER (Settings -> Features). Off hides the whole Accounting section. - Sub-toggles, gated under the master: - `taxReport` ("Tax export") moves PERMANENTLY out of CRM. Removed from the Clients sub-nav and from the derived `clients` flag. Now INDEPENDENT of Bills (per decision). Old /admin/clients/tax-report -> redirect to /admin/accounting/tax-report. - `incomingInvoices` (new) gates the supplier-invoice capture / expenses / re-bill feature; the /api/admin/expenses router now checks it. - Dependency rules (backend + frontend): accounting off forces taxReport + incomingInvoices off; taxReport dropped from the clients derivation; the bills->taxReport rule removed. - Preserve visuals: migration 122 rewritten to auto-enable `accounting` on installs that already had Tax on (so the tab doesn't vanish), and to seed `incomingInvoices` off. Verified with a SQLite harness (taxReport on -> accounting on; off -> off). - Settings -> Features: new "Accounting" section with the master card + Tax export + Incoming invoices sub-cards (disabled until the master is on). - i18n: navigation.accounting, accounting.*, settings.features.{accounting, incomingInvoices,taxReport.requiresAccounting}, sections.accounting (EN + DE, DE authored natively); Tax report relabelled "Tax export"/"Steuerexport". Verified: node -c, migration-122 harness, en/de JSON valid, npm run build green.	2026-06-11 00:17:44 +02:00
Luca	30c0007f40	feat(accounting): Accounting nav section + relocate Tax report out of CRM ... Adds the `accounting` feature flag to the frontend (type, context default) and a Settings -> Features toggle card. When enabled: - A new top-level "Accounting" sidebar entry appears (gated by `accounting` + accounting.view), with an AccountingLayout sub-nav mirroring ClientsLayout. - The Tax report relocates: it is HIDDEN from the CRM (Clients) sub-nav and shown under Accounting instead, at /admin/accounting/tax-report. When accounting is OFF, Tax stays under CRM exactly as before. Tax visibility still depends on `taxReport` (which depends on `bills`), so the relocation only changes WHERE the menu item lives, not whether it exists. Files: featureFlags.service.ts (+'accounting'), FeatureFlagsContext default, AdminSidebar entry, new AccountingLayout, ClientsLayout filter, App.tsx route, FeaturesTab card, en/de i18n (navigation.accounting, accounting.*, settings.features.accounting; DE authored natively). Verified: `npm run build` green; en/de JSON valid.	2026-06-11 00:04:40 +02:00
Luca	1bf0b34ea5	feat(projects): gate Project Overview behind a projects feature flag + cockpit email actions ... - Migration 120 seeds the projects flag (default OFF), idempotent. - Backend feature-flags whitelist + DEFAULT_FLAGS + clients derivation. - adminProjects routes 403 PROJECTS_DISABLED when the flag is off. - projectService email actions (resend/cancel/retry/send-now) + routes. - Frontend flag type, DEFAULT_FLAGS, Features tab card (en+de).	2026-06-06 12:59:57 +02:00
Luca	b064aab8ef	feat(crm): unlock reminderEmails feature flag in Features tab ... The full reminder-email implementation (eventReminderService, eventReminderTemplates self-heal, ReminderTemplatesPage, EventReminderOverrideCard) shipped in the CRM bundle but the FeaturesTab card kept lockedReason=NOT_YET_AVAILABLE — so the working feature was invisible. Flip the card to the same shape as customerPortal: status="beta", real setFlag handler, no disabled/lockedReason. The sub-tab in Settings → Reminder templates already self-mounts when the flag is on, and the per-event override card already self-renders on the event detail page. Description copy + EN/DE i18n updated to describe what the feature actually does (per-category pre-event nudge) instead of the old "coming soon" placeholder.	2026-05-26 20:31:14 +02:00
Luca	a7e16e7bf6	feat(crm): frontend code — pages + services + components ... Brings in the full frontend CRM stack: admin authoring pages, customer-portal surfaces, public response flows, typed services, and the supporting component library. i18n locale JSON is the next commit (kept separate so reviewers can read it as data). Pages - Quotes: list / editor / detail / public accept-decline - Invoices: list / editor / detail / public payment-check - Contracts: list / editor / detail / block library / public sign - Calendar (FullCalendar — admin-only v1) - Tax report (period picker + CSV/PDF export) - Hours (logged time entries, per-customer) - Deals lineage (DocumentLineageCard surfaces) - CRM Development (admin dev tools, gated by crmDevelopment flag) - Customer-portal pages for quotes / invoices / contracts - Settings reorg: CRM-Settings group + dedicated tabs for Business Profile, CRM behaviour, Contracts block library, Reminder emails - BrandingPage typography (PDF font picker) - EventDetailsPage / CustomerDetailPage / CreateEventPage extensions (event-time fields, hours toggle, per-event reminder override) Services (typed) - quotes.service, bills.service, contracts.service - customerAdmin.service, deals.service, calendar.service, taxReport.service, contracts-blocks.service - businessProfile.service (timezone, font picker, bank accounts) - useInstallmentDefaults hook, useLocalizedDate dateInputLang extension Components (admin) - CustomerPicker (shared across quote/invoice/contract editors) - LineItemsTable (hierarchy + details_text, memoised pricing) - InstallmentsPanel (simple + advanced toggle, fixed-date vs trigger) - DocumentLineageCard (deal_uuid grouped view) - EditInstallmentPlanModal (atomic post-spawn plan reshape) - EventReminderOverrideCard, EmailTemplateEditor (tiptap), PdfFontPicker, IntegrityCheckCard - Feature-flag context + RequireFeature wrapper + AdminSidebar featureFlagsAny derivation + UI-hiding sweep Build infra - vite.config: fullcalendar chunk carved off (~200 KB lazy-loaded) - frontend/package.json: tiptap, fullcalendar, signature_pad, react-international-phone, et al. - tailwind + prose styles updated for editor surfaces 3-way merge note: 1 conflict (CustomerDetailPage.tsx) hand-resolved to keep upstream's SUPPORTED_LANGUAGES.map() data-driven pattern over feat/crm's hardcoded option list; feat/crm's DecimalInput import preserved alongside.	2026-05-26 18:19:32 +02:00
Paul Nothaft	3465b55abc	feat(events): default Guest Feedback ON via admin setting (#520) ... @Rekoo-PS asked for an admin-level switch so new events can have Guest Feedback enabled out of the box instead of toggling it on every time. Mirrors the existing event_default_require_password pattern (#317) — same shape end-to-end, same set of five files. - publicSettings.js: whitelist + expose event_default_feedback_enabled (defaults to false to match the prior hard-coded form default; no behaviour change for existing installs until an admin flips it). - adminEvents.js: rename `feedback_enabled = false` destructure to `feedback_enabled: feedbackEnabledInput` so we can distinguish "omitted" from "explicit false", then resolve the default from the setting only when the caller omitted it — identical to the require_password handling a few lines above. - Frontend EventSettings type + state + loader: new boolean, default false. - EventsTab: toggle UI right under "Require password by default". - CreateEventPage: one-shot useEffect that seeds feedback_settings.feedback_enabled from the public setting on first load (mirrors the require_password seed effect right above it). Sub-toggles (likes / ratings / comments) keep their hard-coded true defaults so flipping the master setting immediately gives sensible behaviour without a second admin setting to manage. Refs: #520	2026-05-18 21:26:45 +02:00
Paul Nothaft	482e91bbf8	Merge pull request #501 from filpgame/fix/settings-page-language-reset ... fix(i18n): settings page resets UI language to server default	2026-05-17 01:19:27 +02:00
Paul Nothaft	98f3c3df41	fix(upload): restore configurable batch-size for reverse proxies (#509) ... Regression of #208. PR #214 (commit 02a46e0, re-merged at 9b7495e) shipped the configurable `general_max_upload_batch_size_mb` setting so users behind Cloudflare Tunnel and other reverse proxies with per-request size caps could lower the chunked-upload size below their proxy's limit. Six days later the "Merge main into beta for release/beta-to-main" commit (28793bb) resolved its conflict by keeping main's older tree — which silently deleted the migration (072), the setting input on Settings → General, the i18n strings, the `useSettingsState` field, and the read in PhotoUpload.tsx, putting the hardcoded 500MB chunk back. Galleries fronted by Cloudflare have quietly been broken on batch uploads since then. Re-applying exactly the same change set: - `backend/migrations/core/072_add_max_upload_batch_size.js` recreated, with a comment pointing at the regression in case the same merge accident happens again. - `frontend/src/components/admin/PhotoUpload.tsx` line 168 now reads the setting from query cache and falls back to 95MB (Cloudflare-safe headroom under 100MB). - `useSettingsState.ts`, `GeneralTab.tsx`, `en.json`, `de.json` — added the field to the state type + defaults + load path + the Site-Configuration input. Existing installs are safe either way: - Ran original 072 then lost the file: migrations table still has the filename, so the runner skips re-applying. The setting row in `app_settings` is also untouched (the deletion was source-only, no down migration ran). Now the new code starts reading it again. - Installed after the regression: migrations runner picks up the new 072 normally and seeds the setting at 95.	2026-05-17 00:42:22 +02:00
filpgame	165ebce8d1	fix: settings page resets UI language to server default ... When navigating to the Settings page, useSettingsState called i18n.changeLanguage() with the server-stored general_default_language value on every settings query resolution. This caused the admin UI language to reset to the server default (e.g. "en") regardless of the language the user had selected via the LanguageSelector. The general_default_language setting is intended as the default for public galleries, not for controlling the admin UI language. The admin UI language is already persisted via localStorage through i18next-browser-languagedetector and should not be overridden by server settings. Remove the i18n.changeLanguage() call from the useEffect that initialises settings state from the API response.	2026-05-16 01:14:57 -03:00
Paul Nothaft	7eeef2ba98	feat(downloads): preserve original camera filenames on download (opt-in) (#493) ... New Settings → General toggle `Use original filenames on download` (off by default). When on, single-photo downloads, bulk/selection zips, and per-event archive zips surface `photos.original_filename` instead of the sanitized storage filename. Storage paths are unchanged. - Content-Disposition uses RFC 5987 (`filename=` ASCII + `filename*=UTF-8''…`) so unicode camera filenames survive while header-injection bytes are stripped. - Zip entries are deduplicated with a deterministic `_1` / `_2` suffix on collision (folder structure preserved in archive zips). - Pre-generated download-all zips and the in-memory setting cache are invalidated when the toggle flips so the next download rebuilds with the new names. - Falls back to the storage filename whenever `original_filename` is null (legacy uploads predating migration 062).	2026-05-14 23:11:00 +02:00
Paul Nothaft	61f1d13210	feat(lightbox): medium-resolution preview tier (#492) ... Adds an opt-in lightbox preview tier so guests open photos against an aspect-preserved ~1920px JPEG (~200–500 KB) instead of the full original (often 5–12 MB). Originals are still served on Download. Backend: - imageProcessor: generatePreviewImage / isPreviewValid / ensurePreviewImage using fit:'inside' + withoutEnlargement (longEdge 1920, q85, mozjpeg) - migration 104: photos.preview_path + lightbox_preview_enabled setting (off by default, JSON-stringified for SQLite/Postgres parity) - GET /api/gallery/:slug/preview/:photoId — gallery-auth, lazy generation, ETag based on mtime+photoId+watermarkHash - preview_url surfaced in the photo response only when the toggle is on - admin /thumbnails/regenerate-previews mirrors regenerate-thumbnails, skipping videos - backup walk + archive cleanup + photo-delete now include previews/ Frontend: - PhotoLightbox uses photo.preview_url ?? photo.url (null-safe fallback) - ThumbnailsTab gets a Lightbox Preview Tier card: opt-in toggle + Regenerate All Previews button (gated until the toggle is on) - en/de locale strings; nl/pt/ru/fr fall back to en Tested end-to-end: 11 MB / 4000×3000 source → 985 KB / 1920×1440 preview, 381 ms first call, 7 ms cached, ~91% byte reduction.	2026-05-14 22:30:39 +02:00
Paul Nothaft	dec2f5d3d2	fix(features): customer-portal card uses 'Clients' to match sidebar wording ... Settings → Features showed the customer-portal toggle as "Accounts" ("Konten" in DE, "Comptes" in FR, etc.) — the deeper sub-nav label inside ClientsLayout — while the prominent menu-bar entry the admin actually clicks first reads "Clients" / "Kunden". The mismatch was confusing on first encounter ("which one do I look for?"). Align the Features tab card title and the "Sidebar:" callout with the menu-bar wording (`navigation.clients`) across all six locales. The sub-nav inside ClientsLayout keeps its own "Accounts" label — that one matches the /admin/clients/accounts URL and is correct.	2026-05-11 21:52:42 +02:00
Luca	9091ed4012	feat(clients): scaffold top-level Clients section with sub-nav around Accounts	2026-05-11 16:17:14 +02:00
Luca	bf7ef14626	fix(settings): readable contrast on accent-tinted icon tiles + pills	2026-05-11 11:27:16 +02:00
Luca	15d01f3756	fix(features-tab): icon tiles + preview pills follow CI accent	2026-05-11 11:07:55 +02:00