هذا ما نحصل عليه عند محاولة إنشاء فئة فرعية للمسؤولين (نفس المشكلة للمشرفين) ضمن فئة الموظفين:
“يجب أن يُسمح لأي مجموعة يُسمح لها بالوصول إلى فئة فرعية بالوصول أيضًا إلى الفئة الأصلية. المجموعات التالية لديها وصول إلى إحدى الفئات الفرعية، ولكن ليس لديها وصول إلى الفئة الأصلية: المسؤولون.”
لكن:
المشرفون لديهم بالفعل وصول إلى فئة الموظفين، وكذلك المسؤولون. لذا يجب أن نكون قادرين على القيام بذلك.
أنا مسؤول عن منتدى آخر موجود منذ عدة سنوات، حيث لدينا فئات فرعية تحت فئة الموظفين مخصصة للمسؤولين فقط أو للمشرفين فقط.
آراؤكم؟
[تحرير: فقط للمتعة، قمت بتصوير التسمية الفعلية التي تظهر عند محاولة إنشاء فئة مخصصة للمسؤولين فقط:
إنها مضحكة نوعًا ما لأن (أ) المسؤولين لديهم بالفعل وصول إلى الفئة الفرعية للموظفين، ولكن أيضًا (ب) يمكن للمسؤولين الذهاب إلى أي مكان… لذا، افتراضيًا، لديهم وصول إلى أي فئة.
وبالطبع، لا يمكنك تعديل قسم الأمان في فئة الموظفين لإضافة المشرفين والمسؤولين بشكل محدد إلى الفئة العامة.]
يجب أن تتأكد من أن الفئات الفرعية التي تنشئها متاحة للموظفين فقط. لقد حاولت إنشاء فئة متاحة للجميع، لكنك لم تلاحظ الإعدادات المتعلقة بالصلاحيات عند إنشائها، لذا لا تعتقد أن هذا صحيح.
هذا ما ظننته، ومن هنا رسالتي المحذوفة، لكن اقرأ مرة أخرى رسالة الخطأ:
“يجب أن يُسمح لأي مجموعة يمكنها الوصول إلى فئة فرعية بالوصول أيضًا إلى الفئة الرئيسية. المجموعات التالية لديها وصول إلى إحدى الفئات الفرعية، لكن ليس لديها وصول إلى الفئة الرئيسية: المشرفون.”
لذلك حاولت وواجهت نفس المشكلة.
حاولت إنشاء فئة فرعية مع تعيين الأمان على “المشرفون: يمكنهم الرؤية/النشر/الإنشاء”، لكنني حصلت على نفس رسالة الخطأ رغم أنه يُفترض أن يكون المشرفون مدرجين ضمن “الموظفين”، وأن أمان الفئة الرئيسية مُعَيّن على “الموظفون: يمكنهم القراءة/النشر/الإنشاء”.
أعتقد أن ما يحدث هو أن الأمان يُحدد بناءً على المجموعات وليس بناءً على الصلاحيات.
المشرف ينتمي إلى كل من مجموعة الموظفين ومجموعة المشرفين.
ولكن إذا وُجدت فئة للموظفين وفئة فرعية للمشرفين، فماذا سيحدث لشخص ينتمي فقط إلى مجموعة المشرفين؟ سيكون بإمكانه الوصول إلى الفئة الفرعية ولكن ليس إلى الفئة الأصلية، وDiscourse لا يسمح بذلك.
نظريًا، إذا أردت جعل فئة فرعية متاحة للمشرفين، كنت ستضيف “المشرفون: يمكنهم العرض/النشر/الإنشاء” إلى أمان الفئة الأصلية، لكن هذا غير ممكن في الفئة الفرعية الافتراضية للموظفين.
وعلاوة على ذلك، سيكون ذلك بلا فائدة لأن مصطلح “الموظفين” يشمل المشرفين والمدراء، والمدراء لديهم صلاحية الوصول إلى جميع الفئات.
هذا غير صحيح. يمكن للمحررين الوصول إلى فئة الموظفين. لذا فإن وجود فئة فرعية للمحررين (أو للمشرفين) مسموح به (أو يجب أن يكون مسموحًا به) من قبل ديسكورد. القاعدة تنص على أن أي مجموعة يمكنها الوصول إلى فئة فرعية يجب أن تكون قادرة أيضًا على الوصول إلى الفئة الأصلية.
ولكن لن يكون بلا فائدة على الإطلاق إنشاء فئة فرعية مخصصة للمشرفين فقط، إذ لا يملك المحررون صلاحية رؤية كل ما يراه المشرفون.
اقرأ رسالتي بعناية: كما هو مُصمم النظام، يعمل بالطريقة الصحيحة، والخطأ الذي واجهته أمر طبيعي. يعتمد الوصول إلى المنتدى فقط على المجموعات.
فئة الموظفين الافتراضية، التي ينشئها Discourse تلقائيًا، متاحة فقط لمجموعة الموظفين.
إذا كنت ترغب في إنشاء فئة فرعية لمجموعة المُعدِّلين، فلن يعمل ذلك لأن الفئة الرئيسية متاحة فقط لمجموعة الموظفين، وليس لمجموعة المُعدِّلين.
السبب الوحيد الذي يمنح المُعدِّلين الوصول إلى الفئة الرئيسية هو أنهم ينتمون أيضًا إلى مجموعة الموظفين.
لا يزال بإمكانك إنشاء فئة فرعية باسم “المُراجعة” وتعيين الأمان على أن “الموظفين يمكنهم القراءة/النشر/الرد”، وسيعمل ذلك.
نعم، سيكون ذلك كذلك، ويمكنك جعل فئة أو فئة فرعية متاحة فقط لمجموعة المشرفين دون أي مشكلة.
للتوضيح: أعتقد أن هذا هو بالفعل سبب المشكلة. لقد كنت في البداية أفكر في ذكر ذلك كشرح، لكنني قررت النشر دون ذلك..
لكن، في هذه الحالة، هذا أحد تلك الأخطاء الخبيثة حيث لا تعكس القواعد التي تضعها الأسباب التي أدت إلى إنشائها. من الواضح تمامًا أن الموديريتور جزء من الطاقم، وكذلك المشرفون، وهذا السبب يجعل من المنطقي أن يكون لديهم القدرة على إنشاء فئات فرعية ضمن “الطاقم”.
وفي الواقع، قبل بضع سنوات، كان من الممكن إنشاء فئات فرعية داخل “الطاقم” للمشرفين فقط أو للموديريتور فقط: وكان ذلك صحيحًا بوضوح.
لماذا سيكون من غير المجدي إنشاء فئة فرعية للمشرفين فقط؟
نعم، أنت محق.
إذا كنت ترغب في إنشاء هذه الفئات الفرعية، فيجب عليك إنشاء فئة رئيسية لأخبار الموظفين مع تعيين الأمان بحيث يمكن للقراء/النشر/الإنشاء من قبل: المدراء، الموظفون، المشرفون، على ما أعتقد.
لماذا لا تقوم ببساطة بإنشاء فئة جديدة كما ذُكر؟ يُعد فريق العمل مجموعة متخصصة.
يمكنني إضافة مستخدمين إلى عدة مجموعات. مجرد أن بعض المستخدمين ينتمون إلى المجموعة B وقد يكونون جزءًا من المجموعة A أيضًا، لا يعني أن صلاحيات المجموعة A لفئة ما تمنح المجموعة A حق الوصول تلقائيًا. ومع ذلك، تعمل صلاحيات الفئات بناءً على مستوى الثقة على الحد الأدنى.
لا أدري، لكن أعتقد أنه يمكنك على الأرجح تعديل صلاحيات فريق العمل للسماح لمجموعة المشرفين بالوصول المباشر.
لا يوجد شيء يُسمى صلاحيات هرمية داخل Discourse. Staff هي مجموعة خاصة تضم المدراء والموديريتور. لا يمكن للفئات الفرعية تحديد مجموعات غير موجودة في الفئة الأصلية، ولدى مجموعة Staff صلاحيات وصول ثابتة (ACLs). كما هو موضح في فئة الطاقم:
تحذير: هذه فئة مُعدة مسبقًا ولا يمكن تعديل إعدادات الأمان الخاصة بها. إذا لم ترغب في استخدام هذه الفئة، احذفها بدلاً من إعادة توظيفها.
هذا ليس خطأً؛ بل إن لديك حالة استخدام لا تتناسب مع فئة الطاقم الافتراضية. لا بأس في رغبتك في فعل شيء مختلف، لكن سيكون من الخطأ الإصرار على أن عدم قدرتك على استخدام فئة مدمجة لغرض مختلف يجعل هذا الأمر خطأً ما.
من الواضح جدًا أنك لا ترغب في استخدامها كما هي. لا شيء يمنعك من إنشاء فئة أصلية جديدة يمكن للمدراء والموديريتور الوصول إليها، ثم إنشاء فئات فرعية منفصلة لكل منها تحتها.
هذا خطأ بسيط للغاية في نظام تحذير أذونات التصنيف، لأنه لا يدرك أن staff تساوي admins + moderators. لا يستحق 12 مشاركة من النقاش المتبادل.
يمكنك تجاوز ذلك بإضافة admins و moderators صراحةً إلى التصنيف الرئيسي كالمجموعات المسموح بها. ضع في اعتبارك أن المدراء سيظلون لديهم وصول إلى التصنيف الفرعي moderators.
نعم. لكن المشرفين لن يكون لديهم وصول إلى فئات المدراء.
نعم في الحالة العامة، لكن هذا غير ممكن في فئة “الموظفين” التي تُنشأ تلقائيًا ولا يمكن تغيير الصلاحيات فيها، وهو ما كان موضوع السؤال. وبما أن (أ) فئة “الموظفين” تُملأ تلقائيًا في كل تثبيت، و(ب) من المهم لأسباب تتعلق بقابلية الاستخدام الحدّ من عدد الفئات، و(ج) أن فئة “الموظفين” كانت تعمل بشكل صحيح سابقًا، فلا أعتبر هذا الطلب غير معقول.
اقتراحي هو حل بسيط. حاليًا، عند إنشاء فئة “الموظفين” تلقائيًا، تُضبط الصلاحيات التالية (ولا يمكن تعديلها):
الموظفون يمكنهم الإنشاء/الرد/المشاهدة
بدلاً من ذلك، عند إنشاء فئة “الموظفين” تلقائيًا، يجب أن تضبط منصة Discourse الصلاحيات التالية:
الموظفون يمكنهم الإنشاء/الرد/المشاهدة
المدراء يمكنهم الإنشاء/الرد/المشاهدة
المشرفون يمكنهم الإنشاء/الرد/المشاهدة
مع هذا الإصلاح البسيط، سيتم حل هذه المشكلة، ولن نحتاج إلى إنشاء فئات إضافية وعديمة الفائدة، وستعمل فئة “الموظفين” كما كانت تعمل في الماضي.
لكن هذا لا علاقة له بالتوافق مع الإصدارات السابقة. في هذا الموضوع، أنت الشخص الوحيد الذي يدفع نحو تغيير. ما تقترحه لا يزال يتطلب وقتًا للتطوير، ويحتاج إلى اختبار، ويستلزم صيانة مستمرة. وجود آلاف التثبيتات تعمل مع الإعداد الحالي يعني أيضًا وجود آلاف فرق الإدارة/المراقبة لا يمانعون في الوضع الحالي.
هذا الموضوع قديم منذ أشهر. كان بإمكانك تنفيذ الطريقة الصحيحة للقيام بذلك منذ أبريل، فلماذا تتوقع من CDCK تمويل تغيير في برمجياتها، شيء عمل بهذه الطريقة لسبع سنوات، لموقع واحد فقط؟ لماذا يجب أن يفعل أي شخص أي شيء إذا كنت غير راغب في إجراء أبسط تغيير على إعداداتك الخاصة؟ عدم رغبتك في اتباع التوجيهات لا يشجع أي شخص آخر على اتخاذ إجراء.
لا يوجد شيء خاص بفئة الموظفين، كما اقترح منذ أشهر، يمكنك إنشاء فئة مختلفة مع الأذونات المناسبة. تم حل المشكلة.
من الأسهل بكثير بالنسبة لك تنفيذ تغيير بسيط في مجتمعك، مقارنة بـ أي مما سبق.
إنها ليست الطريقة الصحيحة للقيام بذلك، لكنني قمت بتطبيقها في أبريل. نحن لا ننتظر عادةً حتى يتم إصلاح الأخطاء أو تنفيذ الميزات لكي ننظم أمورنا.
نعم، نعم، ولا. قضيتُ سنوات عديدة كمطور برمجيات ومدير، وأنا أدرك تمامًا ما يتطلبه إصلاح الخطأ. سيستغرق هذا الإصلاح بضع دقائق من وقت التطوير، وبضع ساعات من وقت الاختبار، ولن يتطلب أي صيانة أكثر مما تتطلبه النسخة الحالية.
حججك تعني أنه لا فائدة مطلقًا من تطوير أي شيء جديد. فهناك آلاف الفرق تستخدم ديسكورش كما هي—فلماذا ننفق ساعة إضافية واحدة في التطوير؟ دعنا نستخدم المنطق عند الجدال، من فضلك.
كان هذا افتراضًا غير مفيد ومهين، وهو بالطبع غير مبرر بالنظر إلى تعليقاتي أعلاه.
في الواقع، أنت مخطئ. لقد عمل الأمر بشكل مختلف، وبشكل أفضل، لفترة طويلة. إليك مثال على نظام ديسكورش مستضاف موجود، عمره 4-5 سنوات، يحتوي على فئة موظفين أصلية تسمح بوجود فئات فرعية للمشرفين:
النقطة لا علاقة لها بنظامي. أنا لا أحتاج إلى التغيير لجعله يعمل. النقطة هي أن كل نظام ديسكورش يأتي مع فئة موظفين تكون أدنى من حيث القدرات مما يمكن أن تكون عليه، ومما كانت عليه. إذا بذل ديسكورش عناء إنشاء فئة موظفين تلقائيًا، فلماذا لا يتم تصميمها بشكل جيد ونظيف؟ أنا أقدم اقتراحًا بسيطًا وسهل التنفيذ، وسيستعيد القدرات المفيدة لأولئك منا الذين يتعاملون مع فئات متعددة من الموظفين. الفريق حر في النظر في اقتراحي—أو عدم النظر فيه.
