קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
יש שתי דרכים שונות לשתף עם אנשים אחרים את הנתונים של היומן והאירועים.
קודם כל, אתם יכולים לשתף יומן שלם עם רמת גישה מוגדרת.
לדוגמה, אתם יכולים ליצור יומן צוות ואז לבצע פעולות כמו:
לתת לכל חברי הצוות את הזכות להוסיף ולשנות אירועים ביומן
איך נותנים לבוס הרשאה לראות את האירועים ביומן
לתת ללקוחות את הזכות לראות רק מתי אתם פנויים או עסוקים, אבל לא את פרטי האירועים
אפשר גם לשנות את הגישה לאירועים ספציפיים ביומן המשותף.
אפשר גם להזמין אנשים לאירועים ספציפיים ביומן.
כשמזמינים מישהו לאירוע, עותק של האירוע מתווסף ליומן שלו. העותק ביומן של המשתתף גלוי לאחרים בהתאם להגדרות השיתוף של המשתתף.
המוזמנים יכולים לאשר או לדחות את ההזמנה, ובמידה מסוימת גם לשנות את העותק של האירוע – למשל, לשנות את הצבע שלו ביומן ולהוסיף תזכורת. מידע נוסף על הזמנת משתמשים לאירוע
שיתוף יומנים
הבעלים של היומן יכולים לשתף אותו עם משתמשים אחרים. הגדרות השיתוף של יומן מסוים מיוצגות על ידי אוסף ה-ACL (רשימת בקרת גישה) של היומן הזה. כל משאב באוסף ACL מעניק מקבל הרשאה מסוים תפקיד גישה מסוים, שהוא אחד מהתפקידים שמפורטים בטבלה הבאה:
תפקיד
הרשאת הגישה שניתנת על ידי התפקיד
none
לא מספק גישה.
freeBusyReader
ההרשאה מאפשרת למי שקיבל אותה לראות אם היומן פנוי או עסוק בזמן מסוים, אבל לא מאפשרת גישה לפרטי האירועים. אפשר לאחזר מידע על מצב פנוי/תפוס באמצעות הפעולה freeBusy.query.
reader
מאפשרת למקבל ההרשאה לקרוא אירועים ביומן.
writer
מאפשר למקבל ההרשאה לקרוא ולכתוב אירועים ביומן. התפקיד הזה מאפשר גם לראות את רשימות ה-ACL.
owner
ההרשאה הזו מאפשרת להיות הבעלים של היומן. לתפקיד הזה יש את כל ההרשאות של התפקיד 'כותב', עם היכולת הנוספת לשנות רשימות ACL.
הגורמים שאפשר להעניק להם הרשאות הם:
משתמש פרטי אחר
קבוצת משתמשים
דומיין
ציבורי (מאפשר גישה לכולם).
כברירת מחדל, לכל משתמש יש גישת בעלים ליומן הראשי שלו, ואי אפשר לבטל את הגישה הזו. אפשר להוסיף עד 6,000 רשימות ACL לכל יומן.
למשתמשי Google Workspace יש גם הגדרות דומיין שיכולות להגביל את הגישה המקסימלית המותרת. לדוגמה, נניח שהדומיין שלכם כולל הגדרה שמאפשרת רק שיתוף של יומנים עם מידע על זמן פנוי/לא פנוי. במקרה כזה, גם אם תעניקו גישת כתיבה לציבור, משתמשים מחוץ לדומיין יוכלו לראות רק את פרטי הזמינות.
חשיפה של האירוע
אחרי שמשתפים את היומן, אפשר לשנות את מאפיין החשיפה של אירועים ספציפיים כדי לשנות את הרשאות הגישה אליהם.
למאפיין הזה אין משמעות ביומנים שלא שיתפתם. בטבלה הבאה מפורטים הערכים האפשריים של מאפיין ההרשאות:
חשיפה
משמעות
default
הרשאות הגישה לאירוע נקבעות לפי הרשאות הגישה ליומן. למשתתפים שונים באותו אירוע יכולות להיות רשימות ACL שונות והגדרות שיתוף שונות. אם משתמש עם יומן private שולח הזמנה לאירוע עם הרשאת גישה default למשתמש אחר עם יומן שגלוי לכולם, האירוע גלוי באופן מלא ביומן של המשתתף.
public
פרטי האירוע הזה גלויים לכל מי שיש לו גישה ליומן ברמה של freeBusyReader לפחות.
private
רק משתמשים עם גישה ברמה של לפחות writer ליומן יכולים לראות את פרטי האירוע הזה.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-08-29 (שעון UTC)."],[],[],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. |"]]
