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>
43 lines
2.2 KiB
SQL
43 lines
2.2 KiB
SQL
-- Nachklang e.V. Calendar module — step 5 preparation, brought forward.
|
|
-- Apply manually against the CALENDAR_DB database, after 001:
|
|
-- mysql -h <DB_HOST> -u <DB_USER> -p <CALENDAR_DB> < 002_snapshot_legacy_creator_names.sql
|
|
--
|
|
-- Snapshots the creator's and last editor's *name* onto the event itself.
|
|
--
|
|
-- Why: the creator is only ever rendered as a name (nothing authorises on it),
|
|
-- and today that name comes from joining the calendar's own `users` table.
|
|
-- Step 5 drops that table, which would silently erase the authorship of every
|
|
-- event created before the cutover. There is no account backfill to save them
|
|
-- either - that was dropped deliberately, see docs/calendar-auth-migration.md.
|
|
-- One text column per reference keeps the history at no ongoing cost.
|
|
--
|
|
-- These columns are an archive, not a source of truth. Nothing writes them
|
|
-- after this backfill: events created from the cutover onwards carry an admin
|
|
-- user id, whose name is resolved live so that renaming an account updates
|
|
-- everywhere. The read path prefers the live admin name, falls back to this
|
|
-- snapshot, and falls back again to the join until step 5 removes it.
|
|
--
|
|
-- The whole file is re-runnable: IF NOT EXISTS on the columns, and the backfill
|
|
-- only touches rows with no snapshot yet. Step 4's migration re-runs the
|
|
-- backfill, to catch anything created between this migration and the cutover.
|
|
--
|
|
-- No charset clause: unlike 001's id columns these hold display text that is
|
|
-- only ever compared against other calendar data, so they inherit the tables'
|
|
-- utf8mb4_general_ci like the columns they are copied from.
|
|
|
|
ALTER TABLE `events`
|
|
ADD COLUMN IF NOT EXISTS `created_by_name` VARCHAR(255) NULL DEFAULT NULL AFTER `created_by_user_id`;
|
|
|
|
ALTER TABLE `event_versions`
|
|
ADD COLUMN IF NOT EXISTS `version_created_by_name` VARCHAR(255) NULL DEFAULT NULL AFTER `version_created_by_user_id`;
|
|
|
|
UPDATE `events` e
|
|
JOIN `users` u ON u.user_id = e.created_by_id
|
|
SET e.created_by_name = u.full_name
|
|
WHERE e.created_by_name IS NULL;
|
|
|
|
UPDATE `event_versions` v
|
|
JOIN `users` u ON u.user_id = v.version_created_by_id
|
|
SET v.version_created_by_name = u.full_name
|
|
WHERE v.version_created_by_name IS NULL;
|