Uh oh!
There was an error while loading. Please reload this page.
fix(google): don't default-enable colleagues' shared calendars - #377
Merged
Conversation
The Google Calendar connector previously used accessRole === "owner" to decide which calendars to sync by default. That field is an ACL permission tier, not an ownership signal: a domain's internal calendar sharing defaults (or a teammate sharing their own calendar for scheduling coverage) can grant "owner"-level access on a calendar that isn't actually the user's own. In a workspace with generous internal sharing, every colleague's personal calendar would read accessRole: "owner" and get swept into the default-enabled set alongside the user's own calendar. Now the default-enable decision uses the calendarList `primary` flag instead, which Google guarantees is true for exactly one calendar per user: their own. Colleagues' and shared team calendars are still listed and can be enabled manually — they're just no longer pre-selected. Also updates the `Channel.enabledByDefault` doc comment, which cited the old accessRole check as the reference example for other connectors to follow.
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 freeto 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
The Google Calendar connector picked which calendars to sync by default using
accessRole === "owner"from the Calendar API. That field is an ACL permission tier, not an ownership signal — a workspace's internal calendar-sharing defaults (or a teammate sharing their own calendar for scheduling coverage) can grant "owner"-level access on a calendar that isn't actually yours. In a workspace with generous internal sharing, every colleague's personal calendar readsaccessRole: "owner"too, so they all got swept into the default-enabled set alongside the user's own calendar — flooding the connection with other people's events.Change
primaryflag, which Google guarantees istruefor exactly one calendar per user: their own. Other calendars (colleagues', shared team calendars, subscriptions) are still listed and can be enabled manually — just no longer pre-selected.Channel.enabledByDefaultdoc comment in the Twister SDK, which had cited the oldaccessRolecheck as the reference example for other connectors to follow.CALENDAR_LIST_SCOPEfallback.Test plan
pnpm exec tsc --noEmitinconnectors/google— cleanpnpm exec vitest runinconnectors/google— 363/363 passing (including 4 new tests)pnpm lintinconnectors/googleandtwister— cleanpnpm validate-changesets— valid🤖 Generated with Claude Code
https://claude.ai/code/session_017vzBsQy8oMtks73MLJ49Jz