محتوى هذه الصفحة مترجم آليًا. لا تضمن Zoom دقة المحتوى المترجم آليًا.
Page cover
For the complete documentation index, see llms.txt. This page is also available as Markdown.

سياق النموذج القديم

تعرّف على كيفية تعامل النموذج القديم مع وراثة الإعدادات، وتجاوزات المستخدم، والمجموعات الأساسية، والأقفال، وحل التعارضات.

كيف كانت إدارة مجموعة تعمل قبل التجربة الجديدة

يعمل التسلسل الهرمي لـ الإعدادات في Zoom عبر ثلاثة مستويات: الحساب، مجموعة، ومستخدم

يتم تنظيم الإعدادات الإدارية في Zoom في تسلسل هرمي ثلاثي المستويات:

  1. تُعد الإعدادات على مستوى الحساب الأوسع نطاقًا، إذ تُطبق كقيم افتراضية عبر الحساب بأكمله.

  2. تتيح الإعدادات على مستوى مجموعة للمسؤولين تخصيص الإعدادات لمجموعات من المستخدمين.

  3. تُعد الإعدادات على مستوى مستخدم الأكثر تحديدًا، إذ تُطبق على المستخدمين الفرديين.

تتدرج الإعدادات نزولًا عبر هذا التسلسل الهرمي: تنتقل القيم الافتراضية على مستوى الحساب إلى جميع المجموعات والمستخدمين الموجودين أسفلها.

عند تكوين أحد الإعدادات على مستوى الحساب، ترث المجموعات والمستخدمون هذه القيمة تلقائيًا ما لم يتم تجاوزها على مستوى مجموعة أو مستخدم.

لمزيد من المعلومات حول كيفية عمل الإعدادات المتدرجة عبر Zoom، راجع مقالة دعم Zoom استخدام الإعدادات المتدرجة. للحصول على مثال لكيفية تطبيق هذا التسلسل الهرمي على منتج محدد، راجع مقالة دعم Zoom إدارة مجموعة Zoom Phone.

يحتفظ مستخدم قام بتعديل إعداد غير مقفل بهذه القيمة ما لم يتم تجاوزها بواسطة قفل

عندما يغيّر مستخدم يدويًا إعدادًا غير مقفل، تكون القيمة التي اختارها المستخدم لها الأسبقية على القيم على مستوى المجموعة وعلى مستوى الحساب لهذا الإعداد. ويُشار إلى ذلك بحالة "معدَّل". ويستمر الإعداد المعدَّل على مستوى المستخدم في التمتع بالأسبقية على القيم على مستوى المجموعة وعلى مستوى الحساب ما لم يقم مسؤول بقفل الإعداد على مستوى الحساب أو مستوى المجموعة. عند تلك النقطة، تتجاوز القيمة المقفلة تعديل المستخدم.

ينطبق هذا السلوك في كل من نموذج إدارة المجموعة القديم وتجربة إدارة المجموعات والإعدادات الجديدة. وهو غير مرتبط بنموذج واحد دون الآخر.

في النموذج القديم، كانت المجموعة الأساسية وحالة القفل تحددان الإعدادات التي تصبح سارية للمستخدمين في عدة مجموعات

عندما كان المستخدم ينتمي إلى أكثر من مجموعة واحدة في النموذج القديم، كان النظام يعيّن مجموعة واحدة باعتبارها المجموعة الأساسية وجميع المجموعات الأخرى كمجموعات ثانوية. وكانت إعدادات المجموعة الأساسية لها عمومًا الأسبقية على إعدادات المجموعات الثانوية. وعندما كانت توجد تعارضات في القفل بين المجموعات — على سبيل المثال، تقوم مجموعة بقفل إعداد على الوضع تشغيل وأخرى تقفله على الوضع إيقاف — كان النظام يستخدم مزيجًا من تعيين المجموعة الأساسية وترتيب إضافة المستخدم إلى المجموعات لتحديد القيمة التي تنطبق.

بالنسبة إلى بعض المنتجات، كان النموذج القديم يطبق الإعداد الأكثر تقييدًا عبر جميع المجموعات التي ينتمي إليها المستخدم. إذا كان المستخدم في مجموعة واحدة حيث كانت دردشة Zoom مُمكَّنة وفي مجموعة أخرى كانت معطلة فيها، فستكون دردشة Zoom معطلة لهذا المستخدم لأن النظام كان يعتمد القيمة الأكثر تقييدًا.

فرض أقفال الميزات على مستوى الحساب الإعدادات من الأعلى إلى الأسفل دون أي استثناءات على مستوى المجموعة

عندما قام مسؤول بقفل إعداد على مستوى الحساب في النموذج القديم، كانت تلك القيمة المقفلة تنطبق على كل مجموعة وكل مستخدم في الحساب، دون أي طريقة لإنشاء استثناءات. وإذا أراد مسؤول تمكين ميزة لمجموعة محددة من المستخدمين مع إبقائها معطلة للجميع الآخرين، فعليه إلغاء قفل الإعداد على مستوى الحساب ثم قفل القيمة المطلوبة يدويًا في كل مجموعة على حدة. أدى هذا الإجراء إلى إزالة ذلك الحماية فورًا عن جميع المستخدمين.

كان هذا النهج يتطلب من المسؤولين إنشاء مجموعات متزاوجة لكل تنويع من تنويعات الميزة: مجموعة تكون فيها الميزة مقفلة على، وأخرى تكون فيها الميزة مقفلة off.

مع احتياج المؤسسات إلى تحكم أدق في المزيد من الميزات، ازداد عدد المجموعات المطلوبة، مما زاد من تعقيد الإدارة. وكل استثناء جديد لميزة كان يتطلب مجموعات إضافية، وكانت كل مجموعة تتضمن جميع علامات تبويب الإعدادات الخاصة بالمنتج بغض النظر عن غرض المجموعة.

آخر تحديث

هل كان هذا مفيدا؟