Paddy
d960ac8e24
A fresh-context review before deploying found two things that would have broken production, both in the runbook rather than the code. The deploy order named only migration 003. Production has none of the three - 001 and 002 were only ever applied to the dev database - and the new API reads the columns they add on every request, so following it literally would have 500'd every calendar call including the anonymous feed the public website uses. Step 4 now carries a numbered checklist with a verification query. APP_ORIGINS replaces the code's default list rather than adding to it, so naming calendar.nachklang.art in DEFAULT_APP_ORIGINS is not enough if that variable is set on the vhost - and its failure mode is the quiet one the config already warns about, where everything works except sign-out. Added to the same checklist. Also from the review: The two operands of the read guard on /json/next and /ical were swapped so the password check short-circuits first. They are side-effect free, so the order was free - but the old one put an admin-database query in front of the public feed for any caller holding a .nachklang.art cookie, which is a dependency that feed has never had. Two tests now assert the admin database is not consulted at all. /:calendar/json/next had no route-level test, despite being the endpoint the public website actually calls and the property named as load-bearing. Covered now, along with the rest of its credential matrix. Migrations 001 and 002 gained IF NOT EXISTS. They are applied by hand with no tracking table, so a partial re-run should be a no-op rather than an error that aborts the rest of the paste. Verified by applying all three twice to a throwaway container and diffing against the dev schema. Swagger: two descriptions still claimed authentication was required where the public calendar needs none, the calendar enum omitted `birthdays`, and a `createdBy` request-body field was documented and read but never persisted - misleading in a way that suggests a client can set authorship. Removed. The CORS comment describing the calendar's query-parameter sessions is no longer true and was rewritten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
39 lines
2.1 KiB
SQL
39 lines
2.1 KiB
SQL
-- Nachklang e.V. Calendar module — step 1 of docs/calendar-auth-migration.md.
|
|
-- Adds the bridging columns that let an event record who created it as an
|
|
-- *admin* user id (VARCHAR(36)) alongside the legacy calendar users.user_id
|
|
-- (INT). Apply manually against the CALENDAR_DB database:
|
|
-- mysql -h <DB_HOST> -u <DB_USER> -p <CALENDAR_DB> < 001_add_admin_user_bridge.sql
|
|
--
|
|
-- Numbered 001 because this is the first migration this repo owns for the
|
|
-- calendar schema: the tables themselves predate it and were provided by the
|
|
-- repo owner (mirrored for dev in docker/init/01-calendar-schema-dev.sql).
|
|
--
|
|
-- Nothing reads these columns yet — step 3 introduces the dual-read. Adding
|
|
-- them first means the backfill in step 2 has somewhere to write, and this
|
|
-- migration can be applied to production on its own without any code change.
|
|
--
|
|
-- No foreign key, on purpose. The admin `user` table lives in a *different*
|
|
-- database (nachklang_admin) behind a different connection pool, and a
|
|
-- cross-schema FK would tie the two schemas' lifecycles together: you could no
|
|
-- longer dump, restore or move one without the other. The reference is
|
|
-- enforced in application code, which is also where the legacy/new fallback
|
|
-- lives.
|
|
--
|
|
-- The collation is pinned to the admin database's (utf8mb4_unicode_ci) rather
|
|
-- than inherited from the calendar tables' utf8mb4_general_ci. These columns
|
|
-- hold ids that only ever compare against nachklang_admin.user.id, and a
|
|
-- mismatched collation makes any such comparison fail at runtime with
|
|
-- "Illegal mix of collations" instead of at review time.
|
|
|
|
ALTER TABLE `events`
|
|
ADD COLUMN IF NOT EXISTS `created_by_user_id` VARCHAR(36)
|
|
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
|
|
NULL DEFAULT NULL AFTER `created_by_id`,
|
|
ADD KEY IF NOT EXISTS `events_created_by_user_idx` (`created_by_user_id`);
|
|
|
|
ALTER TABLE `event_versions`
|
|
ADD COLUMN IF NOT EXISTS `version_created_by_user_id` VARCHAR(36)
|
|
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
|
|
NULL DEFAULT NULL AFTER `version_created_by_id`,
|
|
ADD KEY IF NOT EXISTS `event_versions_created_by_user_idx` (`version_created_by_user_id`);
|