[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.

Identity: people are matched by Canvas user ID. Email is only used to claim a record that has never logged in (added by staff or imported from a spreadsheet). If a logged-in person's email changes to one held by an unclaimed record, the two are merged. A new login whose email belongs to a different Canvas account gets a 403 rather than taking that record over; fixing that rare case (someone with a new bCourses account) is a manual database edit, by decision.

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

[pancakereport]

found by email can be problematic. individuals are able to change their email, so while emails are always unique, a single user may have two associated emails.

[pancakereport]

Agreed, and it was worse than a missed match: the email lookup could return a user who already had a different Canvas ID and overwrite it, which would let someone who set their email to another person's take over that record. Fixed in 9957c04:

• Login matches by Canvas ID, which doesn't change. Email is only used to claim someone who has never logged in (added by staff or imported from a spreadsheet, so no Canvas ID yet). A new login whose email belongs to a different Canvas user is refused with a 403 instead of taking it over.
• Email changes: a logged-in person's new email is saved. If the new email belongs to an unclaimed imported record, that's the same person, so it's merged in (sections, attendance, sections they teach, roles). If it belongs to another Canvas user, the existing email is kept.
• Add Students (the Canvas lookup) now records the student's Canvas ID, so they're matched by ID from the start.

Tests cover each case: no takeover, email change, merge (including attendance and section staff), and an email owned by another account.

Two limits remain, because spreadsheets and the monorepo data only have emails:

• A person imported under one email who logs in with a different one gets a separate record until their Canvas email matches the import.
• The migration merges by email, so someone who appeared under two different emails in different courses stays two people. There's nothing else in that data to match them on. If that comes up, an admin merge command (using the same absorb helper) would be a small follow-up.