تم تحديث المكون الإضافي واختباره للعمل مع Discourse v3.2.1 وهو حاليًا أحدث إصدار مستقر (غير تجريبي). نهدف إلى دعم الإصدارات المستقرة المستقبلية فقط، مما يعني أنه إذا كنت تستخدم إصدارًا تجريبيًا، فمن المحتمل أن هذا المكون الإضافي لن يعمل.
على رابط GitHub للمكون الإضافي، يوضح ملف README كيفية التأكد من أنك تستخدم v3.2.1.
لقد قمنا للتو بالرجوع من أحدث إصدار تجريبي إلى v3.2.1 والمشكلة الوحيدة التي واجهناها هي أن الشريط الجانبي يصبح مجنونًا بعض الشيء. لإصلاح ذلك، ببساطة قم بتسجيل الخروج وتسجيل الدخول.
مع هذا التحديث، قمنا أيضًا بتضمين “تغيير الملكية” للإجراءات المتاحة لمشرفي الفئات، كما تم طلبه منذ بعض الوقت.
طلب ميزة لدمج هذه الوظائف مفتوح هنا. لا تتردد في دعمه، إذا كنت تعتقد أنه سيكون من المفيد تضمين هذه التغييرات في وظائف Discourse الأساسية.
الميزات
منذ أن بدأنا في استخدام discourse، وجدنا أن الإجراءات المتاحة لمشرفي الفئات كانت ضعيفة. معظم إجراءات المحتوى الأساسية محدودة (تعيين وضع بطيء، إضافة لون/إشعار للموظفين، إلخ) عندما لا يكون هناك سبب حقيقي في رأينا.
لذلك قررنا أن نجرب وننشئ مكونًا إضافيًا يمنح معظم صلاحيات الإشراف المتعلقة بالمحتوى لمشرفي الفئات، عندما يكونون في الفئة التي تم تعيينهم لها.
هذه هي الاستثناءات الوحيدة:
لا يمكن لمشرفي الفئات التصرف على المستخدمين - التعليق، إسكات، تغيير مستوى المستخدم، الوصول إلى عرض المسؤول على المستخدمين لا يزال محجوزًا للمشرفين العاديين
منح الشارات - يتطلب بعض أذونات المسؤول التي فضلنا عدم العبث بها.
عرض سجل الإشراف - يتطلب بعض أذونات المسؤول التي فضلنا عدم العبث بها.
تحويل المواضيع إلى رسائل خاصة والعكس صحيح - اعتبرنا هذا الإجراء حالة متخصصة وفضلنا تركه لمشرفي المنتدى العاديين
التكوين
ببساطة قم بتثبيت المكون الإضافي كما تفعل مع أي مكون إضافي آخر وانقر على مربع الاختيار في الإعدادات لتشغيله.
سجل التغييرات
الإصدار التجريبي الأولي
تم تحديث الإصدار للعمل مع Discourse v3.2.1
ما يجب فعله
عرض إعدادات مفصل يسمح باختيار الإجراءات التي سيتم تمكينها لمشرفي الفئات
أنت لا ترى السبب على الإطلاق، أم أنك لا تراه في حالتك؟
نحن نستخدمه أحيانًا في الميتا. على سبيل المثال، إذا تم نقل إضافة أو سمة/مكون تم تطويره في الأصل بواسطة شخص لم يعد يعمل عليه، فسنغير المؤلف إلى القائم بالصيانة الجديد، أو إلى @system، اعتمادًا على السياق.
من الواضح أنني صغت الأمر بشكل سيء. تم الإصلاح الآن. في قائمة المهام (TODO) في الواقع، توجد إمكانية لتمكين هذه الميزة كخيار.
في مجتمعنا، سيصبح هذا ببساطة منشورًا ويكيًا حتى يتمكن الجميع من المساهمة فيه. هذا منطقي في المثال الذي حددته، ولكن بالنسبة لمنتدانا، فإن الحالة الوحيدة القريبة ستكون دليلًا لشيء ما (استضافة ذاتية لشيء ما باستخدام Raspberry Pi، دليل للعبة، قائمة أحداث لفرقة، إلخ، إلخ).
إليك حالة استخدام مثال: مع إضافة ووردبريس، يحتاج المستخدمون إلى تكوينهم بشكل فردي باسم مستخدم Discourse — حتى لو ضمن تسجيل الدخول الأحادي (SSO) أنهم 1:1. إذا نسي شخص ما جانب ووردبريس أو قام بتكوينه بشكل خاطئ، فإن المنشور ينتهي به الأمر مملوكًا لـ “system”.
وجود مشرفي ووردبريس كمشرفي فئات لفئة تعليقات المدونة سيسمح لهم بالتعامل مع هذا (وبالطبع، الإشراف على التعليقات).
TL4 على مستوى المنتدى بأكمله. في رأينا، يجب أن يتمتع مشرف الفئة بجميع الأدوات التي يمتلكها المشرف، ولكن يقتصر ذلك على الفئة نفسها فقط.
إنه رأي شخصي ولكنه لا يبدو منطقيًا لنا أن المستخدمين ذوي المستوى العالي (TL) لديهم سلطة أكبر من مشرفي الفئات فيما يتعلق بالإشراف على فئة ما.
TL4 في رأيي جيد كما هو لأنه يمكنه بالفعل الإشراف على مستوى المنتدى بأكمله ولكن لا يمكنه اتخاذ إجراءات ضد المستخدمين.
إنهم ببساطة مستخدمون موثوق بهم، معترف بهم من قبل المجتمع لحمايته وتعزيزه، دون المخاطرة بأن يصبحوا مجانين في يوم من الأيام ضد حسابات المستخدمين الآخرين.
يجب أن يكون مشرفو الفئات، مرة أخرى، من وجهة نظرنا، قادرين على فعل ما يفعله المشرف، ولكن في فئتهم الخاصة. وهذا يشمل حتى حظر الأشخاص، ولكن هذا مستوى آخر تمامًا من التعقيد.
ما كنت أفكر فيه هو إنشاء مجموعة من المستخدمين مثل “محظور_من_slug_الفئة”، والتي يتم تعيينها للفئة للقراءة فقط للفئة والمستخدمين المضافين إليها.
بدلاً من ذلك، قم فقط بتوسيع المستخدمين باستخدام الجدول المخصص في قاعدة البيانات الذي تضيف إليه user_id و category_id وتاريخ ووقت. في كل مرة يصل فيها مستخدم إلى موضوع، يتم إجراء فحص لمعرفة ما إذا كان يمكنه التفاعل معه بالفعل أم لا.
تتمثل ميزة اتباع المسار المستند إلى المجموعة في وجود شكل من أشكال واجهة المستخدم تم تنفيذه بالفعل للمسؤولين ومشرفي المنتدى لرفع الحظر في نهاية المطاف. النهج الآخر سيتطلب أيضًا تطوير عرض مخصص ولكنه سيسمح بمزيد من المرونة (انظر انتهاء صلاحية الحظر، إلخ).
لست متأكدًا من أن هذا هو الاتجاه الذي تريده Discourse، ولكن إذا كان لدى مشرفي الفئات هذا النوع من القوة، فسوف يفتح ذلك إمكانية استخدام الفئات كمنتديات داخل منتدى. سيكون ذلك رائعًا من وجهة نظري.
أعتقد أن مالكي المجموعة يمكنهم إزالة الأشخاص من المجموعة، مما يؤدي بعد ذلك إلى إزالة وصولهم إلى الفئة (إذا كانت مقيدة بالمجموعة). فربما يعمل مزيج من مالك المجموعة + مشرف الفئة لهذا الغرض؟
بالنظر إلى البيان “هذه هي الاستثناءات الوحيدة”، فإن كل شيء على Trust Level Permissions Reference حيث تقول عمود مشرف الفئة “TL” أو فارغ سيتحول إلى ، باستثناء منح الشارات، وتغيير الملكية، وإجراءات حساب المستخدم.
أود حقًا أن أرى هذا يتمتع بتحكم أكثر تفصيلاً - أو الأفضل من ذلك، أن يكون هذا التحكم التفصيلي ليس إضافة ولكن مدمجًا. بالنسبة لي، فإن الافتقار إلى القدرة على تغيير الملكية (بشكل مثير للسخرية أحد الاستثناءات، أنا أعرف) هو الأمر الكبير - ولكن من الواضح أنه ليس للجميع.
يمكن أن ينجح هذا بالفعل. لقد أنشأت إعدادًا باستخدام هذا النموذج وكنت جزءًا من موضوع html/markdown حول عرض الرسالة إذا لم تتمكن من النشر. لإنشاء الرسالة برابط لمراسلة مالكي المجموعة.
بينما يعمل هذا، سيكون الخيار الأفضل هو إضافة خيار قائمة حظر/صمت مع خيارات زمنية لمالك المجموعة. يمكن بعد ذلك حظر مستخدم مشكل من فئة الوصول إلى المجموعة. مع وجود خيار للحفاظ على المجموعة غير مقيدة للانضمام والمغادرة. حتى في مجموعة مقيدة، يمكن ربما توسيع هذه القائمة لإعلام المستخدم بأنه محظور من المجموعة مع ملاحظة الحظر.
ملاحظة يمكننا على الأرجح بدء طلب #ميزة لتوسيع وظائف المجموعة لتمكين نظام منتديات فرعية شبيه بريديت باستخدام مشرفي الفئات.. حيث يبدو أن @simon لديه اهتمام أيضًا.
صدقني، أود ذلك أيضًا من Discourse نفسه. لقد كان من المزعج للغاية أن يعمل شخص ما على نمط المنتدى ولكن كان عليّ اختبار التغييرات بنفسي لأنني لم أتمكن من منح صلاحيات المسؤول الكاملة لشخص كان من المفترض أن يعمل فقط على CSS والمرئيات.
يمكننا النظر في هذا. اعترف بأننا أهملنا شيئًا لمجرد أننا لم نفكر في تطبيق (يمكن لمشرفي المنتدى العاديين القيام بذلك في النهاية)
بشكل عام، سأكون سعيدًا بالتخلي عن هذا المكون الإضافي إذا قامت Discourse بتطبيق تحكم أكثر تفصيلاً وأود أن يتمكن مشرف الفئة من حظر الأشخاص من فئتهم فقط، ولكن للأسف، لا يبدو أن هذا أولوية أو شيئًا يهتمون به في هذا الوقت.
خيار مراجعة جديد للمشاركات المعلقة
يمكن للمشرفين الآن تحديد “مراجعة…” كخيار عند مراجعة المشاركات المعلقة للموافقة عليها. سيتم إرسال رسالة خاصة للمستخدم مع سبب طلب المراجعة وتعليقات اختيارية حتى تتاح له الفرصة لتحسين مشاركته عند إعادة تقديمها.
هل حدث شيء أكثر من مجرد إضافة خيار جديد لأن المكون الإضافي توقف عن العمل. إنه لا يعطل الخطاب على حد علمنا، ولكن الخيارات الإضافية لم تعد متاحة. من الممتع دائمًا عندما يقرر شخص ما إعادة هيكلة الكثير من الأشياء بالإضافة إلى إضافة ميزة واحدة جديدة
نحن نحاول إلقاء نظرة أخرى على الكود لمعرفة ما تم تغييره.
كان فهمي أن أحد المطورين أو المقربين منهم قال إنها ليست أولوية / اتجاهًا كانوا يعتزمون الذهاب إليه ولكن ربما أكون مخطئًا. أنا فقط أمر حاليًا، إذا أراد أي شخص فتح طلب الميزة، فلا تتردد في ربط هذا الموضوع حتى يظهر في الروابط في الأعلى أو قم بالإشارة إلي وسأقوم بتحديث المنشور الأول.
| ملخص | السماح بمعظم إجراءات مستوى المشرف لمشرفي الفئات
| رابط المستودع | Github
| دليل التثبيت | كيفية تثبيت الإضافات في Discourse
، باستثناء منح الشارات، وتغيير الملكية، وإجراءات حساب المستخدم.
