One User per person across all offerings, like seating

[pancakereport]

Summary

Removes Account and makes User one person across all offerings, like seating's User.

	Before	After
A person	account row (if they logged in) + one user row per offering	one users row
Role in an offering	is_staff / is_admin on that offering's user row	staff_offerings, admin_offerings, student_offerings sets on the user
current_user inside an offering	that offering's user row	the person; is_staff / is_admin answer for the current offering

The role sets hold offering keys (the course column value), not Canvas IDs as in seating, because offerings moved from the monorepo aren't all linked to Canvas. Login still records the user's Canvas courses, and each offering's role is synced from them on the first request inside that offering, as before.

Limited to the current offering: a person's sections and attendance now span offerings, so everything that reads or changes them is limited to the offering being viewed. That covers refresh, join/switch section, leave all, remove students (all or tutoring), reset, attendance export, the drop list and attendance history. Without this, switching labs in one course would remove a lab in another, and "leave all" would clear every course. Tests cover each case.

Reset Sections Tool no longer deletes people. It deletes the offering's sections, their sessions and attendance, and every student and staff assignment to them; everyone stays in the offering with their roles. The confirmation text says so.

Migrations

Adds Flask-Migrate.

• 0001_baseline: the schema as of Serve every bCourses course from one deployment, with seating's routes #14. A no-op on databases that already have it, which includes staging.

• 0002_single_user:

  • creates users and merges the per-offering rows by email; the newest row's name wins, or the Canvas name for anyone who has logged in
  • re-points enrollments, attendance and section staff
  • drops account, the old user, and the unused course, slot, survey, user_section_junction and session.slot_id

  It's one transaction on Postgres, and can't be downgraded.

The container runs flask db upgrade on start only with RUN_MIGRATIONS=true (staging and production; never PR previews, which share the staging database). A Postgres advisory lock makes concurrent instances wait instead of racing.

Rehearsed on Postgres 18 using staging's exact schema (from pg_dump --schema-only, no data) with generated data at staging's scale: 8,529 rows → 6,954 people, 1,400 in several courses. Every person's roles and name, and every enrollment (10,955), attendance record (19,543) and section staff link, matched independently computed expectations. It took about 2 seconds. The rehearsal found and fixed two problems before they reached staging:

• session.slot_id (a foreign key to slot) would have blocked dropping slot.
• Re-pointing user_section could briefly collide with its primary key, because new person ids overlap old row ids. Re-pointing now goes through negative ids.

flask db check against the result shows users matches the models. Other differences (pgloader index names, ON DELETE RESTRICT, a few missing indexes, flask_sessions) predate this PR and are left for a separate cleanup.

Rollout

1. Back up the staging database: gcloud sql backups create --instance staging-cdss-web-apps-2 --project staging-cdss-web-apps.
2. Set RUN_MIGRATIONS=true on sections-staging (the current image ignores it).
3. Merge. The staging deploy runs the migration on start.

This PR's preview won't work until staging is migrated, because the preview expects the users table. Use the Postgres rehearsal above, or check the preview after merging.

Test plan

• 22 tests: the existing ones plus cross-offering cases (separate state, join, leave all, remove, history), reset keeping people and their roles, claiming an imported person on first login, old account- cookies ignored, and SQLite migration tests (merge plus fresh database)
• Postgres 18 rehearsal on staging's schema at staging's scale, plus concurrent flask db upgrade on an empty database
• After merge: staging migrates on deploy; log in and check an offering you're in

🤖 Generated with Claude Code

[github-actions]

🚀 Staging Preview Deployed!

URL: https://preview-sections-pr-16-137456085712.us-west1.run.app