ניהול הצעות גישה בהמתנה

הצעת גישה היא הצעה של מבקש למי שמאשר להעניק לנמען גישה לפריט ב-Google Drive.

מי שמאשר יכול לבדוק את כל ההצעות לגישה שלא נפתרו בקבצים ב-Drive ולפעול בהתאם. כלומר, אפשר לזרז את תהליך האישור על ידי שליחת שאילתות באופן אוטומטי לגבי הצעות לגישה, ואז לטפל בהן. הוא גם מאפשר למאשרים לראות את ההצעות באופן מצטבר.

‫Google Drive API מספק את מקור המידע accessproposals כדי שתוכלו לראות ולפתור הצעות גישה בהמתנה. השיטות של accessproposals resource פועלות על קבצים, תיקיות וקבצים בתיקיית אחסון שיתופי, אבל לא על תיקיית האחסון השיתופי.

המונחים הבאים מתייחסים ספציפית להצעות גישה:

  • מבקש: המשתמש שיזם את הצעת הגישה לפריט ב-Drive.
  • מקבל: המשתמש שמקבל את ההרשאות הנוספות לקובץ אם ההצעה לגישה מאושרת. במקרים רבים הנמען זהה למגיש הבקשה, אבל לא תמיד.
  • גורם מאשר: המשתמש שאחראי לאשר (או לדחות) את הצעת הגישה. בדרך כלל זה קורה כי הם הבעלים של המסמך או שיש להם אפשרות לשתף אותו.

שימוש בפרמטר fields

אם רוצים לציין את השדות שיוחזרו בתגובה, אפשר להגדיר את fields פרמטר המערכת בכל שיטה של משאב accessproposals. אם משמיטים את הפרמטר fields, השרת מחזיר קבוצת ברירת מחדל של שדות שספציפיים לשיטה. כדי להחזיר שדות שונים, אפשר לעיין במאמר החזרת שדות ספציפיים.

קבלת הצעה לגישה בהמתנה

כדי לקבל הצעה לגישה, משתמשים בשיטה get במשאב accessproposals עם פרמטרי הנתיב fileId ו-proposalId. אם אתם לא יודעים את מזהה ההצעה, אתם יכולים לרשום את הצעות הגישה שממתינות לאישור באמצעות השיטה list.

רשימת הצעות לגישה בהמתנה

כדי לראות את כל הצעות הגישה שממתינות לאישור לפריט ב-Drive, צריך לבצע קריאה ל-method‏ list במשאב accessproposals ולכלול את פרמטר הנתיב fileId.

רק מאשרים של קובץ יכולים לראות את ההצעות שממתינות לאישור בקובץ. המאשר הוא משתמש עם היכולת can_approve_access_proposals בקובץ. אם השולח לא מוגדר כמאשר, מוחזרת רשימה ריקה. מידע נוסף על capabilities זמין במאמר הסבר על היכולות של קבצים.

גוף התשובה מורכב מאובייקט accessproposals שמייצג רשימה של הצעות גישה שלא נפתרו בקובץ.

אובייקט accessproposals כולל מידע על כל הצעה, כמו השולח, הנמען וההודעה שהשולח הוסיף. הוא כולל גם אובייקט RoleAndView שמקבץ את role המוצע של השולח עם view. מכיוון ש-role הוא שדה חוזר, יכולים להיות כמה ערכים לכל הצעה. לדוגמה, יכול להיות שלבקשת הצעה יש אובייקט RoleAndView עם הערכים role=reader ו-view=published, ועוד אובייקט RoleAndView עם הערך role=writer בלבד. מידע נוסף זמין במאמר בנושא תצוגות.

כדי להתאים אישית את המספור של ההצעות לגישה או לסנן אותן, צריך להעביר את פרמטרי השאילתה הבאים:

  • ‫pageToken: טוקן של דף שהתקבל מקריאה קודמת של list. צריך להזין את הטוקן הזה כדי לאחזר את הדף הבא.

  • ‫pageSize: המספר המקסימלי של הצעות הגישה שיוחזרו בכל דף.

אישור או דחייה של הצעות לגישה בהמתנה

כדי לפתור את כל הצעות הגישה שממתינות לאישור לפריט ב-Drive, צריך לבצע קריאה ל-method‏ resolve במשאב accessproposals ולכלול את פרמטרי הנתיב fileId ו-proposalId.

השיטה resolve כוללת פרמטר שאילתה action שמציין את הפעולה שיש לבצע בהצעה. אובייקט Action עוקב אחרי שינוי המצב של ההצעה, כדי שנדע אם היא מתקבלת או נדחית.

ה-method‏ resolve כולל גם את הפרמטרים האופציונליים של השאילתה role ו-view. התפקידים הנתמכים היחידים הם writer,‏ commenter ו-reader. אם לא מציינים את התפקיד, ברירת המחדל היא reader. מידע נוסף זמין במאמר בנושא תפקידים והרשאות. פרמטר נוסף של שאילתה אופציונלית sendNotification מאפשר לשלוח התראה באימייל למגיש הבקשה כשההצעה מתקבלת או נדחית.

בדומה לשיטה list, למשתמשים שמאשרים את ההצעה צריכה להיות היכולת can_approve_access_proposals בקובץ. מידע נוסף על capabilities זמין במאמר הסבר על היכולות של קבצים.

הצעות נפתרות באמצעות אותם דפוסים שמפורטים בקטע תרחישים לשיתוף משאבים ב-Drive. אם יש כמה הצעות לאותו משתמש, אבל עם תפקידים שונים, המערכת תפעל לפי הכללים הבאים:

  • אם הצעה אחת מתקבלת והשנייה נדחית, התפקיד שאושר חל על הפריט ב-Drive.
  • אם שתי ההצעות מתקבלות בו-זמנית, ההצעה עם ההרשאה הגבוהה יותר (לדוגמה, role=writer לעומת role=reader) מוחלת. הצעת הגישה השנייה מוסרת מהפריט.

אחרי שליחת הצעה לשיטת resolve, פעולת השיתוף מסתיימת. הצעת הגישה שנפתרה כבר לא מוחזרת דרך השיטה list. אחרי שההצעה תאושר, המשתמש יצטרך להשתמש במשאב permissions כדי לעדכן את ההרשאות בקובץ או בתיקייה. מידע נוסף זמין במאמר בנושא עדכון הרשאות.