日曆共用
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
與他人共用日曆和活動資料的方式有兩種。
首先,您可以共用整個日曆,並指定存取權層級。
舉例來說,您可以建立團隊日曆,然後執行下列操作:
- 授予團隊所有成員在日曆中新增及修改活動的權限
- 授權老闆查看日曆中的活動
- 授予顧客權限,讓他們只能查看你是否有空,但無法查看活動詳細資料
您也可以調整共用日曆中個別活動的存取權。
你也可以邀請他人參加日曆中的個別活動。
邀請他人參加活動時,對方的日曆會顯示該活動的副本。其他使用者能否查看與會者日曆上的副本,取決於與會者的共用設定。受邀者可以接受或拒絕邀請,並在一定程度上修改活動副本,例如變更活動在日曆中的顏色,以及新增提醒。進一步瞭解如何邀請使用者參加活動。
共用日曆
日曆擁有者可以授予其他使用者存取權,藉此共用日曆。特定日曆的共用設定會以該日曆的 ACL 集合 (存取控制清單) 表示。ACL 集合中的每個資源都會授予特定受讓人某種存取角色,也就是下表列出的其中一種角色:
角色 |
角色授予的存取權 |
none |
無法存取。 |
freeBusyReader |
受讓人可以查看日曆在特定時間是否有空,但無法存取活動詳細資料。您可以使用 freeBusy.query 作業擷取有空/忙碌資訊。 |
reader |
允許受讓人讀取日曆上的活動。 |
writer |
讓受讓人讀取及寫入日曆中的活動。這個角色也可以查看 ACL。 |
owner |
提供日曆擁有權。這個角色具備撰寫者角色的所有權限,還能操作存取控制清單。 |
可能的受讓人包括:
- 其他個人使用者
- 使用者群組
- 網域
- 公開 (授予所有人存取權)。
根據預設,每位使用者都擁有主要日曆的擁有者存取權,且無法放棄這項存取權。每個日曆最多可新增 6,000 個 ACL。
Google Workspace 使用者也可能受到網域設定限制,無法取得最高存取權。舉例來說,假設網域設定只允許共用忙碌/有空日曆,在這種情況下,即使您授予公眾寫入權限,網域外的使用者也只會看到有空/忙碌詳細資料。
活動顯示設定
共用日曆後,您可以變更活動的瀏覽權限,調整日曆中個別活動的存取權。如果日曆未共用,這項屬性就沒有意義。下表列出瀏覽權限屬性的可能值:
顯示設定 |
意義 |
default |
活動的瀏覽權限取決於日曆的存取控制清單。同一活動的不同參與者可以有不同的 ACL 和共用設定。如果使用者透過 default 可見度設定,使用 private 日曆傳送活動邀請給日曆公開可見的其他使用者,該活動就會完整顯示在受邀者的日曆中。 |
public |
只要擁有日曆的存取權 (至少為 freeBusyReader ),就能查看這場活動的詳細資料。 |
private |
只有具備至少 writer 日曆存取權的使用者,才能查看這項活動的詳細資料。 |
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-29 (世界標準時間)。
[null,null,["上次更新時間:2025-08-29 (世界標準時間)。"],[],[],null,["# Calendar sharing\n\nThere are two different ways to share calendar and event data with others.\n\nFirstly, you can *share* an entire calendar, with a specified level of access.\nFor example, you can create a team calendar, and then do things like:\n\n- Grant all members of your team the right to add and modify events in the calendar\n- Grant your boss the right to see the events on your calendar\n- Grant your customers the right to only see when you are free or busy, but not the details of the events\n\nYou can also adjust the access to individual events on the shared calendar.\n\nAlternatively, you can invite others to individual events on your calendar.\nInviting someone to an event puts a copy of that event on their calendar. The\ncopy on the attendee's calendar is visible to others according to the\nattendee's sharing configuration.\nThe invitee can then accept or reject the invitation, and to some extent also\nmodify their copy of the event --- for example, change the color it has in\ntheir calendar, and add a reminder. [Learn more about inviting users to an\nevent](/workspace/calendar/api/concepts/inviting-attendees-to-events).\n\nSharing calendars\n-----------------\n\nThe owners of a calendar can share the calendar by giving access to other\nusers. The sharing settings of a given calendar are represented by the [ACL\ncollection](/workspace/calendar/v3/reference/acl)\n(access control list) of that calendar. Each resource in the ACL\ncollection grants a specified *grantee* a certain access *role*, which is\none of those listed in the following table:\n\n| Role | Access privilege granted by the role |\n|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `none` | Provides no access. |\n| `freeBusyReader` | Lets the grantee see whether the calendar is free or busy at a given time, but does not allow access to event details. Free/busy information can be retrieved using the [freeBusy.query](/workspace/calendar/v3/reference/freebusy/query) operation. |\n| `reader` | Lets the grantee read events on the calendar. |\n| `writer` | Lets the grantee read and write events on the calendar. This role can also see ACLs. |\n| `owner` | Provides ownership of the calendar. This role has all of the permissions of the writer role with the additional ability to manipulate ACLs. |\n\nThe possible grantees are:\n\n- another individual user\n- a user group\n- a domain\n- public (grants access to everyone).\n\nBy default, each user has owner access to their primary calendar, and this\naccess cannot be relinquished. Up to 6,000 ACLs can be added per calendar.\n\nFor Google Workspace users, there are also domain\nsettings that might restrict the\nmaximum allowed access. For example, suppose your domain has a setting that\nonly allows free-busy calendar sharing. In this case, even if you grant writer\naccess to the public, users outside the domain will only see the free-busy\ndetails.\n| **Note:** Sharing a calendar with a user no longer automatically inserts the calendar into their `CalendarList`. If you want the user to see and interact with the shared calendar, you need to call the [`CalendarList: insert()`](/workspace/calendar/v3/reference/calendarList/insert) method.\n\nEvent visibility\n----------------\n\nOnce the calendar is shared, you can adjust the access to individual\nevents on a calendar by changing the [visibility\nproperty](/workspace/calendar/v3/reference/events#visibility) of the event.\nThis property has no meaning for non-shared calendars. The following table\nlists the possible values of the visibility property:\n\n| Visibility | Meaning |\n|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `default` | The visibility of the event is determined by the ACLs of the calendar. Different attendees of the same event can have different ACLs and sharing. If a user with a `private` calendar sends an invite to an event using `default` visibility to another user with a publicly visible calendar, the event is fully visible on that attendee's calendar. |\n| `public` | The details of this event are visible to everyone with at least `freeBusyReader` access to the calendar. |\n| `private` | The details of this event are only visible to users with at least `writer` access to the calendar. |"]]