How permissions combine

Effective access is an intersection

An action must fit the provider’s permissions, the account and calendar state, workspace policy, the user’s grant, and the client’s scopes and restrictions. A more permissive setting in one layer cannot bypass a narrower setting elsewhere.

For example, calendar:write does not make a read-only shared calendar writable. A writable calendar does not let an assistant see descriptions if its content policy is busy-only. A workspace administrator cannot turn an unrelated user’s account into their own.

Content and action rights are different

Content policy controls which event fields can be disclosed: busy-only, title and time, or permitted details. Action rights control what the caller may do. Read access is not write access; calendar access is not task, contact or mail access.

Availability is a minimal-content operation. It can tell a client which time windows are free without revealing titles or attendees. An unavailable provider must not be interpreted as an empty, free calendar.

Check the full path

When troubleshooting, inspect the active workspace, account ownership and status, selected calendars, provider consent, client permissions and requested action. Compare a permitted test calendar with an explicitly excluded one. The excluded calendar must remain inaccessible even if the client knows its ID.

Narrowing and revocation

Permission changes must be enforced on the server, not just hidden in the interface. Reconnecting a client should not be treated as permission to widen access automatically. A previously sent request may already be in progress at a provider; revocation cannot retroactively cancel a completed provider action.