لذا، هذا بالتأكيد يلبي الكثير من متطلباتي فيما يتعلق بتفويض أنشطة الإشراف حيث سيكون للفئات نطاق محدد (على سبيل المثال، قد تواجه دور مشرف عالمي مشكلات).
العنصر الوحيد المتبقي لدينا في قائمة الأمنيات هو أن يكون لدى المشرف المفوض القدرة على إنشاء فئة فرعية ضمن فئته المحددة النطاق. نحن نبحث في عدة طرق لأتمتة حوكمة الفئات أو على الأقل جعلها خدمة ذاتية، لكنني أفضل الاحتفاظ بالأشياء في نفس السياق إذا استطعت.
إضافة ذلك تبدو معقدة في ذهني.
تحتاج إلى التحقق من إعداد الموقع “يمكن للمشرفين إنشاء فئات”
التحقق من حالة مشرف الفئة للمستخدم وعرض الفئة/المفتاح الجديد
يتطلب وجود فئة رئيسية في واجهة المستخدم للفئة الجديدة
ويمكن أن تكون الفئة الرئيسية فقط قائمة بالفئات التي يكونون فيها مشرف فئة.
اعتقدت أنني سأتحقق لمعرفة ما إذا كان هذا على الرادار أو ربما يمكن أن يعمل اليوم إذا استخدمت المزيج الصحيح من الإعدادات. إذا لم يكن الأمر كذلك، فإن الإنشاء اليدوي للفئات بواسطة المشرفين العالميين/الموظفين أو عملية خارجية سيكون جيدًا لأن المشرفين المفوضين لا ينبغي لهم إنشاء فئات طوال الوقت.
هل يمكنك تقديم أي تفاصيل حول حالة الاستخدام الخاصة بك؟ قد يساعد مثال واقعي لكيفية استخدام هذا في القضية.
هذا غير ممكن حاليًا. المنطق الذي يقيد إنشاء الفئات للمسؤولين (والمشرفين إذا تم تمكين إعداد “يدير المشرفون الفئات والمجموعات”) موجود هنا:
إذا لم يكن من الممكن إضافة الميزة إلى كود Discourse الأساسي، أعتقد أنه يمكن تحقيق ذلك باستخدام إضافة Discourse. ستحتاج إلى إضافة فحص إضافي إلى طريقة can_create_category؟ للتأكد من تعيين parent وأن المستخدم لديه إذن مشرف الفئة في الفئة parent.
إذا لم تكن الإضافة خيارًا، فيمكن تنفيذها عبر واجهة برمجة التطبيقات (API). في الأساس، سيقوم مستخدم النظام بتقديم طلب لإنشاء الفئة الفرعية نيابة عن مشرف الفئة. سيكون هذا معقدًا إلى حد ما للتطوير - ربما يكون الأسهل للحالات التي لديك فيها موقع خارجي يعمل كمزود لـ DiscourseConnect لمنتدى Discourse.
بالنسبة لنا، إنها نفس حالة الاستخدام مثل التعديلات ذات النطاق الفئوي. بشكل أساسي، توفير الاستقلالية للمشرفين الفئويين حسب المجموعة للحفاظ على جزء صغير من مجتمعهم كما يرونه مناسبًا.
أتفق على أن هذا يمكن إضافته إلى قاعدة التعليمات البرمجية الرئيسية لتعزيز نمط المشرفين الفئويين وأن هذه الوظيفة بداية قوية. سأحتاج إلى العثور على مكان تخزين بيانات المشرف الفئوي وإضافة حالة OR أخرى لهذا التحقق.
التغيير الأكثر تعقيدًا (أعتقد) سيكون في واجهة المستخدم نفسها حيث يكون الأصل مطلوبًا وهم مشرف فئوي. أحتاج إلى إلقاء نظرة فاحصة على التعليمات البرمجية لمعرفة ما إذا كان من الأسهل تصفية نتائج الأصل لتلك الفئات فقط حيث يكونون مشرفين فئويين أو مجرد حالة تحقق يتم تشغيلها عندما يكون المستخدم مشرفًا فئويًا، فسيؤدي ذلك إلى خطأ إذا لم يتم تحديد الأصل أو الفئة. سيكون التصفية تجربة مستخدم أفضل، ولكن نمط التحقق أبسط في التنفيذ على الأرجح.
وشكرًا لك على نقل هذا إلى موضوعه الخاص. بعد أن نشرت على الإعلان، شعرت أنه يجب أن يكون شيئًا خاصًا به.
يبدو هذا وكأنه #تجربة_الموظفين وتحسين محتمل. هل لدينا قاعدة الثلاثة؟
أتذكر أن @Julienlavigne أثار هذه النقطة في سياق الفرق، حيث تحتاج الفرق الفردية إلى الاستقلالية ولا ينبغي دائمًا السماح لها بالوصول إلى فئات بعضها البعض والاطلاع عليها. هل هذا شيء لا تزال ترغب في رؤيته في Discourse؟
قد يكون الأمر معقدًا لأنه سيتعين تنفيذه بعناية وسيتطلب إعدادًا جديدًا للمسؤول لأن معظم المواقع لن ترغب/تحتاج إلى تفويض هذا إلى مشرفي الفئات. أيضًا، من حيث المبدأ، لا نشجع على إنشاء الكثير من الفئات.
نعم بالنسبة لنا، يتعلق الأمر بخصوصية أقل للفئات حيث نريد إغلاق بعض حقوق القراءة لمجموعات معينة، ولكن قد يأتي ذلك. نتفق على أن هذا قد ينشئ نوعًا من دور مسؤول الفئة الضمني. إذا قمت بإنشاء فئة فرعية، فمن المنطقي أن يرغب الطرف في تعديل الإعدادات مثل القراءة وما إلى ذلك.
كنت أفكر فقط في نشاط الإنشاء، ولكن نعم، من المنطقي أن تكون إعدادات الفئة جزءًا من نفس النطاق.
كم عدد الفئات التي لديك مع مشرفي فئات؟ كم مرة تتوقع أن يتم إنشاء الفئات أو تعديلها بواسطة مشرفي الفئات؟ إذا لم تكن الخصوصية مصدر قلق، فلست متأكدًا من سبب عدم قدرة مشرفي الفئات لديك على مطالبة مشرف أو مسؤول بإجراء التغييرات نيابة عنهم.
من المحتمل أن يكون هناك 20-30 فئة رئيسية لجميع المجموعات المختلفة في المكتب. سيكون لكل مجموعة هيكلها الخاص للفئات الفرعية.
وبالتأكيد بنسبة 100٪ يمكن القيام بذلك عن طريق طلب يدوي لفئة ميتا أو مدخل آخر. أفكر في أن كل فئة من الفئات الرئيسية سيكون لديها مشرف أو مشرفان رئيسيان لديهم صلاحيات مسؤول الفئة الحالية مفعلة. سيديرون أيضًا مجموعة المشرفين الخاصة بهم لمساعدتهم في إدارة الفوضى والتصعيد حسب الحاجة.
يشعر بعض الأشخاص بالحساسية تجاه الأشخاص الذين لديهم صلاحيات التعديل على “ممتلكاتهم”، لذلك إذا كان بإمكاني إنشاء نظام مغلق سهل، لكان ذلك أفضل. لن يكون هناك الكثير من الموظفين الرئيسيين، لذا لا أريد أن يتعطل العمل. بمجرد أن نبدأ العمل فعليًا، أحتاج إلى النظر في التقارير المتعلقة بالمشاركة المحددة للتأكد من أن الأشخاص يشعرون بأن أصواتهم مسموعة، وكذلك تقارير مستوى المسؤول للتأكد من أن الجميع يلتزمون بالبرنامج.
نعم. أود أن يكون مشرفو الفئات مسؤولين عن فئاتهم. وهذا يشمل، على سبيل المثال، تكوين إعدادات الفئة أو الأذونات أو إنشاء الفئات بالفعل. لقد قمنا بحل هذا الأخير عن طريق أتمتة إنشاء الفئات من خلال واجهة برمجة تطبيقات Discourse.
أتساءل عما إذا كان المزيد من الأشخاص قد يرغبون في هذه الميزة الآن بعد أن أصبح بإمكان Discourse العمل بشكل جيد مع عدد أكبر بكثير من الفئات:
بالنسبة لي، أتخيل استضافة منتدى يحتوي على فروع في ربما أكثر من 100 دولة وربما أنواع أخرى من الفئات أيضًا. بينما يمكن القيام بذلك باستخدام العلامات، فإنني أحب فكرة أن كل بلد يمكنه إدارة فئاته الفرعية الخاصة به دون الحاجة إلى سؤال المسؤولين/الموظفين يدويًا في كل مرة لأنني أعتقد أن إدارة الفئات تمنح مزيدًا من التحكم في من يمكنه العرض/الرد/الإنشاء مقارنة بإدارة العلامات.