مدیریت پیشنهادات دسترسی معلق، مدیریت پیشنهادات دسترسی معلق

پیشنهاد دسترسی ، پیشنهادی است از سوی درخواست‌کننده به تأییدکننده برای اعطای دسترسی به یک مورد Google Drive به گیرنده.

یک تأییدکننده می‌تواند همه پیشنهادات دسترسی حل‌نشده در فایل‌های Drive را بررسی کرده و روی آنها عمل کند. این بدان معناست که شما می توانید با پرس و جوی برنامه نویسی برای پیشنهادهای دسترسی و سپس حل آنها، روند تأیید را سرعت بخشید. همچنین اجازه می دهد تا پیشنهادات را به صورت مجموع توسط یک تایید کننده مشاهده کند.

Google Drive API منبع accessproposals فراهم می کند تا بتوانید پیشنهادات دسترسی در انتظار را مشاهده و حل کنید. روش‌های منبع accessproposals روی فایل‌ها، پوشه‌ها، فایل‌های موجود در درایو مشترک کار می‌کنند اما روی درایو مشترک کار نمی‌کنند .

شرایط زیر برای دسترسی به پیشنهادات خاص است:

  • درخواست کننده : کاربری که پیشنهاد دسترسی به یک مورد Drive را آغاز می کند.
  • گیرنده : کاربری که در صورت اعطای پیشنهاد دسترسی، مجوزهای اضافی روی یک فایل دریافت می کند. اغلب اوقات گیرنده همان درخواست کننده است اما نه همیشه.
  • تایید کننده : کاربری که مسئول تایید (یا رد) پیشنهاد دسترسی است. این معمولاً به این دلیل است که آنها مالک سند هستند یا توانایی اشتراک گذاری سند را دارند.

فهرست پیشنهادهای دسترسی در انتظار

برای فهرست کردن همه پیشنهادات دسترسی معلق روی یک آیتم Drive، متد 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، متد 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 برای به روز رسانی مجوزها در یک فایل یا پوشه استفاده کند. برای اطلاعات بیشتر، مجوزهای به‌روزرسانی را ببینید.

،

پیشنهاد دسترسی ، پیشنهادی است از سوی درخواست‌کننده به تأییدکننده برای اعطای دسترسی به یک مورد Google Drive به گیرنده.

یک تأییدکننده می‌تواند همه پیشنهادات دسترسی حل‌نشده در فایل‌های Drive را بررسی کرده و روی آنها عمل کند. این بدان معناست که شما می توانید با پرس و جوی برنامه نویسی برای پیشنهادهای دسترسی و سپس حل آنها، روند تأیید را سرعت بخشید. همچنین اجازه می دهد تا پیشنهادات را به صورت مجموع توسط یک تایید کننده مشاهده کند.

Google Drive API منبع accessproposals فراهم می کند تا بتوانید پیشنهادات دسترسی در انتظار را مشاهده و حل کنید. روش‌های منبع accessproposals روی فایل‌ها، پوشه‌ها، فایل‌های موجود در درایو مشترک کار می‌کنند اما روی درایو مشترک کار نمی‌کنند .

شرایط زیر برای دسترسی به پیشنهادات خاص است:

  • درخواست کننده : کاربری که پیشنهاد دسترسی به یک مورد Drive را آغاز می کند.
  • گیرنده : کاربری که در صورت اعطای پیشنهاد دسترسی، مجوزهای اضافی روی یک فایل دریافت می کند. اغلب اوقات گیرنده همان درخواست کننده است اما نه همیشه.
  • تایید کننده : کاربری که مسئول تایید (یا رد) پیشنهاد دسترسی است. این معمولاً به این دلیل است که آنها مالک سند هستند یا توانایی اشتراک گذاری سند را دارند.

فهرست پیشنهادهای دسترسی در انتظار

برای فهرست کردن همه پیشنهادات دسترسی معلق روی یک آیتم Drive، متد 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، متد 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 برای به روز رسانی مجوزها در یک فایل یا پوشه استفاده کند. برای اطلاعات بیشتر، مجوزهای به‌روزرسانی را ببینید.