fix(cal): show the calendar name the user sees, not the owner's title - #94
Merged
Merged
Conversation
Google's calendarList entries carry both `summary` (the owner's title) and `summaryOverride` (the name *this* user gave the calendar, and what Google's own UI displays). desk read `summary` alone and dropped the override, so a renamed calendar showed the owner's title — for a calendar shared from a personal account and never renamed at the source, that is a bare email address where a name belongs. `list_calendars` now returns the display name as `summary` (`summaryOverride or summary`) plus `summary_original` for the owner's title, always both, so the shape stays predictable. `_resolve_calendars` matches a `-c` value against either, so a user can type the name they see while scripts written against the owner's title keep working. Ambiguity across the two fields routes through ADR-023's existing INVALID_INPUT error. The `cal list` output prints the display name, showing the owner's title only when it differs rather than repeating the line above it. Investigation note, recorded in ADR-035: a first read of the reporting account showed no `summaryOverride` on any of its ten calendars, which suggested the name lived outside the `calendar` scope entirely — it is on neither `calendars.get` nor any event's organizer/creator/attendee displayName. A second read minutes later returned it, with a changed etag, after nothing but the settings page being opened. So the field can appear without a deliberate rename, and "absent" is not a stable property. The remaining gap — a calendar with no override at all — would need Contacts and a new OAuth scope, captured as idea 081. Fixes #92 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Fixes #92.
Google's
calendarListentries carry bothsummary(the owner's title) andsummaryOverride(the name this user gave the calendar, and what Google's own UI displays). desk readsummaryalone and dropped the override, so a renamed calendar showed the owner's title — for one shared from a personal account, a bare email address where a name belongs.Live, before and after, on the calendar from the issue:
{ "id": "gvc.wdc@gmail.com", "summary": "gvc.wdc@gmail.com" } // before { "id": "gvc.wdc@gmail.com", "summary": "Grace Cannon", "summary_original": "gvc.wdc@gmail.com" } // afterShape
summaryis now the display name (summaryOverride or summary), andsummary_originalalways carries the owner's title. Both keys are always present — a conditional field would be smaller output but a less predictable contract, and ADR-023 set the precedent by addingcalendar_idunconditionally._resolve_calendarsmatches a-cvalue against either name, so a user can type the name they see while scripts written against the owner's title keep working. Verified live:-c "Grace Cannon",-c "grace cannon"and-c gvc.wdc@gmail.comall resolve to the same calendar. Ambiguity across the two fields routes through ADR-023's existingINVALID_INPUTerror.cal listprints the display name, showing the owner's title only when it differs rather than repeating the line above it.Investigation note
Worth recording, and written up in ADR-035. A first read of the reporting account showed no
summaryOverrideon that calendar — or on any of its ten — which suggested the display name lived outside thecalendarscope entirely. It is on neither thecalendars.getresource nor any event'sorganizer,creatororattendeesdisplayName.A second read minutes later returned
summaryOverride: "Grace Cannon"with a changed etag, after nothing but the calendar's settings page being opened — the account owner reports not editing the Name field and not having touched the calendar in over a decade. The likeliest reading is that Google had been rendering the name without persisting it and materialized it on view. That is inference; what is certain is the field was absent, then present, with no deliberate rename.The practical consequence is that "no override" is not a stable property of a calendar and should not be read as "this user wants no name here." The remaining gap — a calendar with no override at all — would need Contacts and a new OAuth scope, so it is captured as idea 081 rather than decided here.
Verification
888 tests pass (9 new), ruff clean. Verified against a live account: the JSON shape, both resolution paths, case-insensitivity, and the human-readable listing.
🤖 Generated with Claude Code