ومع ذلك، هناك حالات استخدام للمجتمعات الكبيرة مثلي حيث لدينا حرفياً منتديات أصغر موجودة داخل المنتدى الرئيسي. فكر في العشائر في ثقافة الألعاب.
تتبنى هذه المجتمعات الفرعية القواعد الرئيسية للمجلس ولكن لديها أيضًا بعض القواعد الإضافية المحددة وفريق مخصص يهدف إلى الإشراف على القسم وكذلك قيادته، ولكن هذا خارج الموضوع.
لا يمكن لمشرفي الفئات التصرف على المستخدمين أنفسهم، فقط على الفئة، ومع ذلك، في حالة الاستخدام الخاصة بي، يجب أن يكونوا قادرين على منع بعض المستخدمين من المشاركة إذا خرقوا بعض قواعد المنتدى الفرعي الخاصة بهم.
كل ما أحتاجه حقًا هو معرفة ما إذا كان يمكن أن يكون هناك تفصيل كافٍ في الوظائف الأساسية للسماح لمشرفي الفئات بحظر مستخدمين محددين من الوصول إلى فئتهم.
الطريقة التي يمكنني تخيلها هي أنه يتم إنشاء جدول مخصص يضيف كلاً من category_id و user_id وعندما يحاول المستخدم الوصول إلى موضوع أو فئة معينة، يتم التحقق ببساطة من هذا الجدول أيضًا.
هل أنا بعيد عن الهدف؟ هل سيكون ذلك ممكناً؟ لدي خبرة كبيرة في تطوير البرمجيات ولكن لا شيء تقريباً في Ruby لذلك لا أعرف حقًا من أين أبدأ في البحث في الكود المصدري لـ Discourse لفهم أين يجب أن أنظر
لقد فعلت الشيء نفسه. ولأنني لا أسمح لأي شخص بالحصول على مستوى أعلى من TL2 تلقائيًا، كان هذا حلاً سهلاً وغير معقد من الناحية الذهنية والإدارية. كان هناك لمسة من الأناقة أيضًا
لقد فعلت هذا لأحد العملاء منذ فترة. لم تكن مستويات الثقة ستنجح معنا، لذلك أنشأنا بدلاً من ذلك مجموعات خاصة لكل فئة تم توفيرها تلقائيًا لكل مستخدم، وكان مشرفو الفئات هم أصحابها.
كانت “الحظر” بسيطة مثل إزالة هذه العضويات، مما يعني عدم وجود عمل من قبل الإدارة.
يتطلب الأمر جهدًا أكبر للبدء، ولكنه لا يتطلب أي جهد تقريبًا بعد ذلك.
مثال: أحد عملائي لديه منتدى بفئة “للبيع”، يمكن الوصول إليها من المستوى 2 وما فوق.
يريدون حظر أعضاء معينين من إنشاء مواضيع هناك، ولكنهم سيحتاجون إلى نسخ وصيانة مجموعة تحتوي على نفس الأشخاص الموجودين في المستوى 2 مطروحًا منها 5 مستخدمين محددين.
يفترض بنفس الطريقة، توفير المستخدمين في مجموعات بناءً على معيار (اكتشاف الترقية إلى TL2؟) ثم إزالتهم إذا لزم الأمر؟ مجرد أن TL2 هو معيار الدخول لا يعني أنك بحاجة إلى الاعتماد على حالة TL2 لتحديد العضوية، أليس كذلك؟ يعتمد الأمر أيضًا على ما إذا كان لديك الوقت والموارد لهندسة شيء ما على/حول مثيلك.
لم أقترح أنه حل شامل للجميع. قد لا يعمل لحالة استخدامهم إذا كانوا لا يريدون القيام بالعمل الإضافي، ولكن بالنسبة للمثال مع عميلي والسيناريو الذي يتم فيه تقسيم مثيل إلى نقابات/عشائر/أياً كان، فقد يكون مناسبًا.
ولكن إذا كنا نقوم بإنشاء شيء ما في المثيل على أي حال، فأفضل أن يكون لدي وظيفة حظر الفئة
كما أنه يجعل الأمور أكثر قابلية للصيانة. إذا كان لدي 50,000 مستخدم وأحتاج إلى أن يتمكن جميعهم من الوصول إلى الفئة باستثناء قليلين، فسيكون من الصعب الحصول على قائمة بهؤلاء القليلين.
أعني، الحظر هو مجرد كلمة أخرى للإقصاء، و Discourse لا يمتلك فعليًا إذن استبعاد على الإطلاق. هل يحتاج إلى الوجود عندما يكون “عدم التضمين” هو نفس الشيء فعليًا؟ أحب نموذج التصريح الصريح، فهو يجعل استكشاف الأخطاء وإصلاحها أمرًا سهلاً.
لا أزال أعاني من كوابيس غريبة حول محاولة حل نموذج التصريح/الرفض من vBulletin قبل كل تلك السنوات. الشيء الوحيد الذي اختبرته بألم وديون مرتبطة به أكثر هو RSOP.
@crius سيكون ذلك ممكنًا باستخدام إضافة، أعتقد أنه يمكنك الوصول إلى حد بعيد من جانب العميل عن طريق تجاوز permissions في serialiser الفئة، ومن جانب الخادم إضافة فحص إضافي باستخدام NewPostManager.add_handler.
هل فكرت في استخدام المجموعات؟ قم بإنشاء فئة بمجموعتين للوصول. المجموعة الأولى هي مشرفو الفئة الخاصة بك. الأخرى هي المشاركون في المنتدى الفرعي. تتطلب مجموعة المشاركين طلب الوصول إلى منطقة المنتدى الفرعي. بعض أو كل مشرفي الفئة هم أصحاب هذه المجموعة. إذا خالف عضو القواعد التي تتطلب طرده من المنتدى الفرعي. قم بطرده من مجموعة المشاركين وتواصل مع مشرفي الفئة الآخرين بشأن المدة.
حسنًا، للأسف قد تحتاج إلى النظر في رعاية إضافة (plugin). هذا هو المكان الذي يمكن أن تكون فيه الإضافات الممولة جماعيًا مفهومًا رائعًا. قد يضيف الفريق الأساسي شيئًا مثل ما تطلبه في النهاية، ولكن قد يستغرق الأمر بعض الوقت بسبب أولويات قائمة التطوير.
من ناحية أخرى، مع اقتراح المجموعة، قد يكون من الممكن باستخدام مكون سمة (theme component) إضافة خيار طرد من المجموعة.
لقد قمت بتقييم إمكانية إدارة هذا باستخدام مجموعات TL أو مجموعات المستخدمين ولكن هذا سيزيد من عبء العمل على المشرفين وهو أمر غير ممكن ببساطة في المجتمعات الكبيرة.
مجموعات المستخدمين على وجه الخصوص تضر بتجربة مستخدم سلسة.
لا أحتاج إلى طلب رعاية حيث لدي خبرة واسعة كمهندس برمجيات وأشخاص آخرون لديهم خبرة واسعة أيضًا. نحن ببساطة لا نستخدم Ruby لذا سيكون هذا هو التباطؤ الوحيد.
شكرًا على المدخلات على أي حال. أقدر أن هذا المنتدى يميل إلى أن يكون له آراء قوية جدًا ولكن عندما يتعلق الأمر بالبرنامج نفسه، سيكون من الأفضل ببساطة اتباع نهج “إعطاء الخيار” مع تعقيد إضافي من حيث الكود كونه على الجانب الآخر من المقياس.
الكثير من الحب لـ @RGJ لإضافة بعض الأفكار
