Three fixes from the earlier review, plus cleanup:
- submissions.service.ts: a newsletter opt-in present but failing
validation (e.g. malformed email) was silently dropped with no signal
to the client - the rest of the submission saved, but the visitor had
no way to know their newsletter signup didn't go through. Added
newsletterDropped to the submit response so the frontend can tell them.
- reports.admin.service.ts: the newsletter summary tracked
total/sent/pending/failed but silently omitted SKIPPED (stub-mode)
signups from any bucket - every current signup showed total>0 with
every bucket reading 0, indistinguishable from "we don't know what
happened". Added a skipped count.
- Consolidated two things duplicated across the module: sendServerError
(reimplemented ~11 times, three of those as identical local copies of
the same function) into feedback.errors.ts, and formatDatetime/
toMysqlDatetime (the same local-time formatting logic under two names,
in csv.service.ts and events.admin.service.ts respectively) into
feedback.dates.ts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Unlike guest book and free-text, newsletter signups had no LIMIT at all and the frontend rendered every row in one plain table. Newsletter opt-in is a single checkbox rather than typed text, so it's plausibly the largest per-event list - fix it the same way as guest book: paginated (page/pageSize, capped at 200/page) plus an optional ?search= over first name, last name, and email.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
At scale (many submissions after a concert), paging through the guest book 20 entries at a time with no way to find a specific person is impractical. Add an optional ?search= query param that filters entries whose name or message contains the term (case-insensitive), with LIKE wildcards escaped so a literal % or _ in a search term can't be misinterpreted as a pattern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The dev-only CORS bypass in app.ts only ever matched
http://localhost:<port>, never the LAN IP a phone actually connects
through over WiFi - so testing the feedback form from a real device
against a local dev API had its submissions silently rejected by CORS.
Extended the bypass to also allow private LAN ranges (192.168.x.x,
10.x.x.x, 172.16-31.x.x), dev-only as before.
Also adds DELETE /feedback/admin/submissions/:submissionId (cascades
to the submission's answers, guest book entry, and newsletter signup
in explicit dependency order, single-path by submission_id) so an
admin can remove an individual abusive/inappropriate entry - decided
in IMPLEMENTATION_PLAN.md §7 item 8. getGuestBookEntries now also
returns submissionId so the admin UI can target the delete call.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New /feedback API domain backed by its own FEEDBACK_DB, mirroring the
Calendar domain's router -> service -> DB pool layering:
- Public endpoints (no auth): eligible-events listing, event config,
submission with honeypot + rate limiting (in-memory + DB backstop).
- Admin endpoints (session-header auth, reusing Calendar's users/sessions
via a swappable feedback.auth.ts boundary): events/songs/questions CRUD,
bulk reorder/assignment, aggregated reporting, CSV export.
- Schema in sql/feedback/001_init.sql (8 tables), applied and verified
against the real FEEDBACK_DB.
- 64 Jest tests covering validation, auth, rate limiting, CSV escaping,
and report aggregation (pure functions, no DB needed).
Includes fixes from a security review: path traversal defense doesn't
apply here (that's the frontend proxy, separate repo), but the
rate-limiter cluster does - recordSubmission now counts every processed
request (not just successful ones), the in-memory Map evicts empty
entries instead of growing unbounded, FEEDBACK_IP_SALT is required at
boot instead of silently degrading to unsalted hashing, and submission
answer/rating arrays are capped and de-duplicated to bound insert
amplification.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Paddy
Patrick Müller