با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
دو روش مختلف برای اشتراک گذاری داده های تقویم و رویداد با دیگران وجود دارد.
در مرحله اول، می توانید یک تقویم کامل را با سطح دسترسی مشخص به اشتراک بگذارید . به عنوان مثال، می توانید یک تقویم تیمی ایجاد کنید، و سپس کارهایی مانند:
به همه اعضای تیم خود حق اضافه کردن و اصلاح رویدادها را در تقویم بدهید
به رئیس خود این حق را بدهید که رویدادهای تقویم شما را ببیند
به مشتریان خود این حق را بدهید که فقط در مواقعی که شما آزاد یا مشغول هستید، جزئیات رویدادها را ببینند
همچنین می توانید دسترسی به رویدادهای فردی را در تقویم مشترک تنظیم کنید.
از طرف دیگر، می توانید دیگران را به رویدادهای فردی در تقویم خود دعوت کنید. دعوت از شخصی به یک رویداد، یک کپی از آن رویداد را در تقویم او قرار می دهد. کپی موجود در تقویم شرکتکننده با توجه به پیکربندی اشتراکگذاری شرکتکننده برای دیگران قابل مشاهده است. سپس دعوتکننده میتواند دعوت را بپذیرد یا رد کند، و تا حدی نیز کپی رویداد خود را تغییر دهد - برای مثال، رنگ آن را در تقویم خود تغییر دهد و یک یادآور اضافه کند. درباره دعوت از کاربران به یک رویداد بیشتر بیاموزید .
به اشتراک گذاری تقویم
صاحبان یک تقویم می توانند با دادن دسترسی به سایر کاربران، تقویم را به اشتراک بگذارند. تنظیمات اشتراک گذاری یک تقویم معین توسط مجموعه ACL (لیست کنترل دسترسی) آن تقویم نشان داده می شود. هر منبع در مجموعه ACL به یک گیرنده اعطا شده نقش دسترسی خاصی را اعطا می کند که یکی از موارد ذکر شده در جدول زیر است:
نقش
امتیاز دسترسی که توسط نقش اعطا شده است
none
دسترسی ندارد.
freeBusyReader
به گیرنده اعطا اجازه میدهد ببیند که تقویم در یک زمان معین آزاد است یا مشغول است، اما اجازه دسترسی به جزئیات رویداد را نمیدهد. اطلاعات آزاد/مشغول را می توان با استفاده از عملیات freeBusy.query بازیابی کرد.
reader
به گیرنده امتیاز اجازه میدهد رویدادهای تقویم را بخواند.
writer
به گیرنده اجازه میدهد رویدادها را در تقویم بخواند و بنویسد. این نقش همچنین می تواند ACL ها را ببیند.
owner
مالکیت تقویم را فراهم می کند. این نقش دارای تمام مجوزهای نقش نویسنده با توانایی اضافی برای دستکاری ACLها است.
اعطا کنندگان احتمالی عبارتند از:
کاربر فردی دیگر
یک گروه کاربری
یک دامنه
عمومی (به همه اجازه دسترسی می دهد).
به طور پیش فرض، هر کاربر به تقویم اصلی خود دسترسی مالک دارد و نمی توان از این دسترسی چشم پوشی کرد. حداکثر 6000 ACL را می توان در هر تقویم اضافه کرد.
برای کاربران Google Workspace، تنظیمات دامنه نیز وجود دارد که ممکن است حداکثر دسترسی مجاز را محدود کند. به عنوان مثال، فرض کنید دامنه شما دارای تنظیماتی است که فقط به اشتراک گذاری تقویم بدون اشغال اجازه می دهد. در این مورد، حتی اگر اجازه دسترسی نویسنده به عموم را بدهید، کاربران خارج از دامنه فقط جزئیات بدون اشغال را مشاهده خواهند کرد.
قابلیت مشاهده رویداد
هنگامی که تقویم به اشتراک گذاشته می شود، می توانید با تغییر ویژگی مشاهده رویداد، دسترسی به رویدادهای فردی را در تقویم تنظیم کنید. این ویژگی برای تقویم های غیر مشترک معنی ندارد. جدول زیر مقادیر احتمالی ویژگی visibility را فهرست می کند:
دید
معنی
default
قابل مشاهده بودن رویداد توسط ACL های تقویم تعیین می شود. شرکتکنندگان مختلف در یک رویداد میتوانند ACL و اشتراکگذاری متفاوتی داشته باشند. اگر کاربری با یک تقویم private با استفاده از قابلیت مشاهده default برای کاربر دیگری با تقویم قابل مشاهده برای عموم دعوت به رویدادی ارسال کند، رویداد به طور کامل در تقویم آن شرکتکننده قابل مشاهده است.
public
جزئیات این رویداد برای همه افراد با حداقل دسترسی freeBusyReader به تقویم قابل مشاهده است.
private
جزئیات این رویداد فقط برای کاربرانی قابل مشاهده است که حداقل دسترسی writer به تقویم دارند.
تاریخ آخرین بهروزرسانی 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. |"]]