إدارة اقتراحات الوصول المعلّقة

اقتراح الوصول هو اقتراح يقدّمه مقدّم الطلب إلى جهة الموافقة لمنح ملف مستلِم إذن الوصول إلى عنصر في 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 لتعديل الأذونات في ملف أو مجلد. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة تعديل الأذونات.