fix: point weekly update notifications at the right week, and honour Senate type preferences (#91, #92, #93) - #97
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The weekly PATCH picked the session to describe with "the first occurrence carrying any override". That is a different question from "which week did this edit move", and usually a different week: an override set on week 1 months ago is still an override today, so every later edit to a series was reported against week 1 -- with an empty "What changed" table, because week 1 had not in fact moved. Occurrences are deleted and reinserted on every save, so the answer has to come from a comparison against the rows that were there before. lib/weekly-occurrences.ts does that, normalising the shapes Postgres and the editor disagree about (18:30:00 vs 18:30, null vs '') so a value that only changed form is not read as a change. is_event is compared as a plain boolean rather than an override, since an absent value there means "not an event" and not "inherit". The user_alerts rows now point at the earliest week that moved, and the email describes every week that moved rather than one of them -- the weekly editor saves all weeks at once, so a single save can move several, and naming only the first meant the rest changed silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…93) The preference existed only on the client, inside the My Rooms list filter, so deselecting Office Hours hid those sessions from the page and did nothing else. Update emails and dashboard alerts still went to every member of the Senate, including the people who had said they did not want them. The rule -- and the list of session types, which was declared twice -- now live in lib/senate-types.ts, and resolveBookingRecipients applies it to the audience it returns, so the page, the emails and the alerts cannot drift apart. The weekly PATCH tells it which sessions the notification is about: the weeks that moved, or all of them when the series itself moved. One wanted session in a batch is enough to keep a member in the audience. Someone who follows Full Body but not Office Hours still needs the email about a save that moved both -- suppressing it would lose a session they asked to know about, which is the worse failure of the two. The filter applies to Leadership as well. The preference is about what someone reads, not what they are responsible for, and Leadership can still see every session on the booking itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pataniaeli
force-pushed
the
fix/issue-91-93-weekly-notifications
branch
from
September 9, 2026 22:39
e61542f to
58667eb
Compare
This was
linked to
issues
Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #91. Closes #92. Closes #93.
Three bugs in the same path — what Chambers sends when a weekly booking is edited, and who it sends it to.
#91 — update emails and alerts pointed at the wrong week
The weekly PATCH picked the session to describe with "the first occurrence carrying any override". That is a different question from "which week did this edit move", and usually a different week: an override set on week 1 months ago is still an override today, so every later edit to a series was reported against week 1 — with an empty "What changed" table, because week 1 had not in fact moved. That is exactly the email in #91: an edit to 9/29 reported as week 1 of 13, Sept 15, with no change list.
Occurrences are deleted and reinserted on every save, so the answer has to come from a comparison against the rows that were there before.
lib/weekly-occurrences.tsdoes that, normalising the shapes Postgres and the editor disagree about (18:30:00vs18:30,nullvs'') so a value that only changed form is not read as a change.The weekly editor saves every week at once, so one save can move several. Naming only the first meant the rest changed silently, so the email now describes every week that moved. One week reads exactly as it does today; several get a block each.
#92, #93 — Senate type preferences were client-only
The preference existed only inside the My Rooms list filter, so deselecting Office Hours hid those sessions from the page and did nothing else. The rule and the type list (declared twice) now live in
lib/senate-types.ts, andresolveBookingRecipientsapplies it to the audience it returns — so the page, the emails and the alerts cannot drift apart.One wanted session in a batch is enough to keep someone in the audience: a save that moved both a Full Body week and an Office Hours week still emails someone who follows only Full Body. The filter applies to Leadership too — the preference is about what someone reads, not what they are responsible for.
The Settings label, which promised this only affected My Rooms, now says what it actually does.
Verification
tscandeslintare clean (the 20 pre-existing lint problems elsewhere inapp/are unchanged). The occurrence diff and the preference rule were exercised directly — 15 and 13 cases respectively, including the #91 scenario and the #92 one. The three email shapes were rendered and read.I could not verify the Settings panel or My Rooms in a browser: the dev server is behind a login wall.
🤖 Generated with Claude Code