عند إضافة المجموعات إلى فئة، يمكن تحديد الخيارات anonymous_users وlogged_in_users، لكنها لا تعمل.
إعجابَين (2)
ألا يتطلب هذا تفعيل ميزة بيتا “إذن المجموعات المخصصة للمستخدمين المجهولين والمسجلين”؟
إعجاب واحد (1)
@martin أي أفكار حول هذا؟
إعجاب واحد (1)
شكراً لك على البلاغ، سأقوم بمراجعته 
من ردك في الموضوع الآخر
كلما فكرت في هذا الأمر أكثر، زادت قلقي بشأنه.
ماذا يحدث إذا أضفت فقط «المستخدمون المجهولون» (anonymous_users) إلى فئة ولم أضف «المستخدمون المسجلون» (logged_in_users)؟
ماذا يحدث إذا أضفت «المستخدمون المجهولون» (anonymous_users) بينما منتداتي يتطلب تسجيل الدخول (login_required)؟
أيضاً، التنفيذ التقني الحالي هو أنه عندما تكون صلاحيات الفئة مضبوطة على «الجميع» (everyone)، لا يوجد ببساطة أي إدخال في category_groups وتكون read_restricted مضبوطة على false.
هذا بسيط ومباشر جداً: إذا لم تكن هناك صلاحيات مضبوطة، فإن الصلاحيات تتحدد بناءً على صلاحيات المنتدى العامة (إعداد login_required) ولا تنطبق قيود إضافية.
لذا، فإن إجراء هذا التغيير سيضيف قدرًا هائلاً من التعقيد، وسيكون من الممكن حدوث تركيبات غريبة (يمكنك تعيين «المستخدمون المجهولون» (anonymous users) و«الإدارة» (staff) 
)
اقتراحي هو:
- إزالة «المستخدمون المجهولون» (
anonymous_users) كخيار لصلاحيات الفئة تماماً - الإبقاء على «الجميع» (
everyone) و«المستخدمون المسجلون» (logged_in_users) - إزالة «مستوى الثقة 0» (
trust_level_0) كخيار لأنه يعادل «المستخدمون المسجلون» (logged_in_users)
أو بديلاً، ولكن ربما يكون أقل وضوحاً للمشرفين الأقل خبرة:
- إزالة «المستخدمون المجهولون» (
anonymous_users) و«المستخدمون المسجلون» (logged_in_users) كخيار لصلاحيات الفئة - الإبقاء على «الجميع» (
everyone) (ومستوى الثقة 0)
في جميع الحالات، الإبقاء على «الجميع» (everyone). ولن تحتاج إلى عملية ترحيل أيضاً 
4 إعجابات
شكراً لآرائك، ولهذا السبب لم أكن أرغب في الخوض كثيراً في صلاحيات الفئات في البداية مع تغيير “الجميع” 
أعتقد أن الكثير مما تقوله هنا يمكن ببساطة جعله مستحيلاً، لقد كنت أعمل بالفعل على بعض الأنظمة الأولية هنا باستخدام قوائم التحكم في الوصول (ACLs) وواجهة مستخدم أكثر أناقة للصلاحيات في إضافة كانبان التي نطورها، إليك مثال، نعتزم تغيير صلاحيات الفئات لاستخدام هذا في النهاية:
هناك عدة قواعد متضمنة هنا، مثل استحالة منح المستخدمين المجهولين صلاحيات المدير للوحة كانبان وما إلى ذلك، كما يدعم الصلاحيات الإلزامية، حيث يمكن للمديرين دائماً إدارة اللوحة.
سنجعل الأمر بحيث لا يمكنك إضافة مستخدمين مجهولين عندما يكون تسجيل الدخول مطلوباً في المنتدى.
مرة أخرى، هذا قيد/تحقق آخر يمكننا إضافته.
يمكننا إضافة تحققات/تحذيرات لهذا النوع من الأمور أيضاً.
هذا ما أريد تجنبه، هذه الأنواع من الصلاحيات الضمنية المنتشرة في كل مكان في Discourse، بدلاً من ذلك أريد دائماً ضبط المستخدمين المسجلين + المستخدمين المجهولين صراحةً لفئة ما إذا كانت عامة/غير مقيدة بالقراءة.
على أي حال، في الوقت الراهن لا أريد الخوض بعمق كبير في هذا الأمر، هناك بعض الطريق المقطوع قبل أن أتعامل مع الفئات. لكنني أوافق على أن المنشور الأصلي هو خطأ برمجي يحتاج إلى الإصلاح في الأثناء، لذا سأقوم بذلك على أي حال.
إعجاب واحد (1)
مع أخذ تلك المشكلة الأخرى في الاعتبار، أوصي شخصيًا ضد هذا النوع من المنطق. ماذا يحدث عندما أغير المنتدى إلى تسجيل الدخول الإلزامي عندما يكون المستخدمون المجهولون بالفعل في قائمة الأذونات؟ والعكس صحيح؟ هذا سيكون كابوسًا، ولن يكون شفافًا للمشرفين.
أنا حذر جدًا من التعقيد مثل هذا.
إعجابَين (2)
مرة أخرى، نقاط جيدة أكثر، هناك الكثير للتفكير فيه وهذه الأمور معقدة. سأحرص بالتأكيد على تجربة المسؤول في الاعتبار عند إجراء تغييرات حول الفئات، هناك الكثير من التاريخ هنا ولا أريد أن يكون هناك أي مفاجآت. لن يتم أي من هذا بسرعة، سيستغرق الأمر وقتًا طويلاً للعمل بعناية عبر السيناريوهات المختلفة عندما أصل إلى هذا المشروع.
إعجاب واحد (1)
أتساءل لماذا يُعدّ حقيقة إمكانية تهيئة الإعدادات للمستخدمين المجهولين دون المستخدمين المسجلين مشكلة في سياق أذونات الفئة، بينما لا تُعدّ كذلك في سياق الأذونات المُهيأة عبر إعدادات الموقع/الإضافة/القالب. مثال بسيط: أصبح من الممكن الآن جعل دليل الأنماط متاحاً للمستخدمين المجهولين دون إضافة المستخدمين المسجلين. هل هذا أكثر منطقية من إظهار فئة للمستخدمين المجهولين، لكن ليس للمستخدمين المسجلين؟
إعجاب واحد (1)
لا، هذا لا معنى له، إنه مجرد حالة حدودية أخرى يجب تغطيتها حقًا… سأضيف anonymous_users إلى disallowed_groups لذلك الإضافة. كما أشك بشدة في وجود العديد من المواقع في البرية مع تفعيل هذه الإضافة، لذا لا أقلق كثيرًا بشأن سوء التكوين في الوقت الحالي.
أعتقد أن هذا هو النهج الذي أتبعه عادةً للتعامل مع هذا النوع من الإعدادات. يمكننا أيضًا الاستفادة من mandatory_values للتأكد من تحديد مجموعات معينة دائمًا بحيث لا ينتهي بك الأمر بـ anonymous_users فقط في بعض الأماكن. أو يمكننا استخدام التحقق من صحة الإعدادات لإخبار المستخدم “لا يمكنك اختيار anonymous_users دون مجموعة مستخدمين مصادق عليها على الأقل”، وما إلى ذلك.
لا أفهم لماذا هذا ضروري. ما الخطأ في جعله خياراً؟
هل يعمل هذا فقط للإعدادات الخاصة بالموقع، أم أيضاً لمكونات السمة؟
لا يعمل حتى الآن لمكونات السمة، لكنه يمكن أن يعمل. مرة أخرى، نحن نتسرع كثيرًا هنا.