Expose calendar source on calendars and events - #6
Open
fmasi wants to merge 1 commit into
Open
Conversation
EKCalendar.source() carries the account identity ("iCloud", "Google",
account email, "Other") and a sourceType enum. Surfacing this lets
callers disambiguate same-named calendars across accounts (e.g. two
"Holidays in United Kingdom" calendars, one Google, one iCloud) and
route by account ("everything from my iCloud").
Changes:
- _calendar_to_dict gains source: {title, type} on every calendar
- _event_to_dict gains calendar_source: str alongside the existing
calendar title (backward-compatible; existing callers see no change)
Both fields are None-safe; if EventKit returns no source they stay
null rather than raising.
Co-Authored-By: Claude Opus 4.7 (1M context) <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.
Summary
Surfaces
EKCalendar.source()data in two places:_calendar_to_dict— addssource: {title, type}on every calendar dict returned bycalendar_list_calendars._event_to_dict— addscalendar_source: stralongside the existingcalendar: stron every event dict returned bycalendar_list_events,calendar_get_event,calendar_search_events.Why
EventKit calendars are not uniquely identified by title alone — same-named calendars can exist across accounts. Smoke-testing the patch on a real machine I hit two calendars with identical titles served by different source accounts; without source, they were indistinguishable. With it, callers can disambiguate, filter by account ("only iCloud"), and route events sensibly.
Example shapes of
sourcereturned by EventKit:iCloudGoogle<account-email>(per-account CalDAV)OtherOn My MacDesign notes
calendar: "Title"field on events is unchanged — only a new siblingcalendar_sourceis added. Existing keys on calendar dicts (id,title,type,allows_modifications) are also unchanged;sourceis purely additive.calendar.source()(andevent.calendar()) is non-null before dereferencing.source.typematches the existingtype: str(calendar.type())pattern. Pretty-printing can come downstream.Test plan
sourcepresent on every calendar dict, with non-null title/type when EventKit provides a sourcecalendar_sourcepresent on every event dictSmoke-tested locally against a real macOS calendar tree with mixed iCloud, Google, subscribed, and Birthdays sources. All output sane.
Independent of #5
This is a separate PR; not stacked on #5 (exclude_calendars). Either can land first.
🤖 Generated with Claude Code