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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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