لا مشكلة! يسعدني أن disallowed_groups ستكون مفيدة. لقد دمجْتُ طلب الدمج (PR) الآن.
أحتاج إلى المرور على جميع السمات والمكونات الرسمية لدينا الآن بعد أن أصبح disallowed_groups وresolve_group_memberships متاحين، وأقترح عليك وأنت @moin القيام بذلك أيضاً عندما تتمكن لسماتك ومكوناتك الخاصة، لأنه بعد أن أجريت تغييرات على مستودعاتنا الرسمية، أرغب حقاً في المضي قدماً في جعل التغيير القادم من المنشور الأصلي stable.
هناك الكثير من العمل الأساسي الآخر الآن يعتمد على/يستخدم anonymous_users وlogged_in_users، وأود حقاً حذف مجموعة everyone.
لقد قمت للتو بتحديث كامل لنسختي، وأنا الآن أضيف إعداد كائن disallowed_groups إلى مكوني الخاص بـ everyone وanonymous_users بناءً على معرفات المجموعات التلقائية هنا:
ما الذي أفعله بشكل خاطئ في إعداد الكائن؟ لاحظت أنه حتى بدون disallowed_groups في الكائنات، لا يزال لا يعرض مجموعة anonymous_users (لذلك في الوقت الحالي، لا يوجد فرق بين القائمة في مكوني سواء قمت بتعيين disallowed_groups أم لا). لقد اختبرت مع معرفات مجموعات أخرى، ويجب أن أكون أرتكب خطأً في طريقة استخدام disallowed_groups (أو الصيغة) لأنه لا يبدو أن له أي تأثير بغض النظر عن تلك التي أستخدمها.
كانت هناك بعض المشكلات على GitHub في وقت سابق من اليوم، لذلك لم يبدأ تغيير disallowed_groups في التأثير إلا للتو في أحدث نسخة من Commits · discourse/discourse · GitHub
لست متأكدًا تمامًا من أن هذه هي المشكلة، لكن هل يمكنك محاولة التحديث مرة أخرى وملاحظة ما إذا كانت المشكلة لا تزال موجودة؟ إذا لم تكن كذلك، أخبرني وأرسلني إلى مكون القالب الخاص بك (أو هل هو فقط عنصر شريط الجانب الخاص بالمجموعة؟) حتى أتمكن من تصحيح الخطأ
قمت بفتح طلب سحب (PR) سريع لإضافة هاتين الفئتين (anonymous_users و logged_in_users).
لم أجربه حقاً (هههه) لكن أعتقد أنه مباشر جداً. الكود يتحقق فقط مما إذا كان المستخدم الحالي موجوداً، وإذا كان كذلك، فهو عضو في logged_in_users، وإذا لم يكن كذلك، فهو anonymous_users.
ملاحظة: أنا متأكد تقريباً من أن Discourse يضيف .anon تلقائياً على أي حال، لذا يمكن تحقيق CSS للمستخدمين المجهولين مقابل المسجلين دون الحاجة إلى المكون، لكن هذا ببساطة يستخدم اصطلاحات المجموعات الجديدة.
أعمل حالياً على خطة للخطوات التالية لهذا التغيير القادم، أعتقد أن هناك بعض الأماكن في أكواد النواة/الإضافات لا تزال تنظر إلى everyone مباشرة أو لا تستخدم user.in_any_groups? على جانب الخادم.
السبب في فتح هذا الموضوع هو أنني قمت أخيرًا بتحديث مكوني
[quote=“martin, post:14, topic:402273”]
سأقوم بتغيير القيمة الافتراضية لـ default_favorite_filters_groups إلى 4|5 في مكون السمات الخاص بك، وهو المستخدمين المسجلين والمجهولين، بدلاً من 0 (الجميع) الذي سيختفي قريبًا.
[/quote]\nلقد قمت بذلك. لكنني ما زلت لدي انطباع بأنه يساعد فقط المنتديات التي تضيف المكون بعد تغيير هذا. على تلك التي تستخدمه بالفعل، لا يتم تطبيق الافتراضي الجديد (وهو أمر جيد عادةً!). لذلك ما زلت أرى المشكلة التي تتمثل في وجود تغيير غير متوقع في السلوك لأولئك الذين يستخدمون المكون بالفعل.
هل تعرف أيضًا ماذا يحدث إذا قام مسؤول بإعداد إعداد بمجموعة أضفتها كمجموعة غير مسموح بها في تحديثي؟
بما أنني لا أعتقد أن المكون مستخدم في العديد من المنتديات، لم أكن قلقًا للغاية وقمت بالدمج على أي حال، لكن كلًا من الهجرة وتعيين المجموعات غير المسموح بها قد يكونان أيضًا مهمين لمطوري السمات الآخرين
سألت في مشاركتى أعلاه متى يجب أن يحدث هذا. قد يسبب الترحيل دون التأكد من عمل المجموعات الجديدة على جميع المنتديات أيضًا أضرارًا، ويمكن للمسؤولين تفعيل التغيير أو إيقافه. لذلك يبدو من المستحيل الترحيل في الوقت المناسب.
أدركت أنه إذا تم تضمين resolve_group_membership في الإعدادات، فلا يمكنني الوصول إلى القيمة المنطقية (boolean) إلا عبر بادئة user_in_، ولكن لم يعد بإمكانني الوصول إلى القيمة الخام لحقل الإعداد.
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // غير معرف (undefined)
console.log(settings.user_in_aabbccdd_allowed_groups); // صحيح أو خطأ (true or false)
أعتقد ذلك. وإلا، كان من الممكن أن يكون حل هذا الخلل مختلفاً.
وهذا يبدو منطقيًا بالنسبة لي أيضًا. فـ user_in_x يتحقق أيضًا من المجموعات التي لا يعرفها الواجهة الأمامية، لأن المجموعة مرئية للمسؤولين فقط أو لأن وضوحها محدود بشكل افتراضي، كما هو الحال مع مجموعة everyone. لذلك، تحصل على نتائج مختلفة اعتمادًا على ما تستخدمه، لذا فإن دمج الاثنين قد يؤدي إلى عواقب غير متوقعة.
شكراً لك يا موين، هذا صحيح تماماً. @gormus المكان الوحيد الذي تظهر فيه معرفات المجموعات الفعلية لا يزال هو واجهة المستخدم الإدارية لإعدادات القالب.
لا أتأكد مما إذا كان هذا واضحاً بناءً على ما نشرته سابقاً، لكن anonymous_users وlogged_in_users يمكن استخدامها في أي وقت دون الحاجة إلى تفعيل التغيير القادم، فقد أضفتها بشكل مستقل منذ أشهر. هذا هو الشيء الرئيسي الذي يفعله التغيير القادم:
لذلك، في كلتا الحالتين، ستكون آمناً إذا تخلصت من everyone في كل مكان تُستخدم فيه واستخدمت فقط anonymous_users وlogged_in_users من الآن فصاعداً.
أخطط اليوم لتحديد خطة للعمل المتبقي الذي أحتاج إلى القيام به للتخلص فعلياً من everyone في إعدادات الموقع (مع ترك إعدادات الفئات جانباً في الوقت الحالي)، وسأقوم بنشرها هنا، لذا آمل أن يساعد ذلك في البقاء على نفس الصفحة في المستقبل، ويمكنني الاستمرار في تحديث هذه الخطة أثناء تقدمي.
لكن المجموعات لا تظهر في الواجهة إذا كان التغيير معطلاً. ولا يمكن للمشرفين تغيير إعدادات تلك المجموعات. لذا، عندما أضفت «الجميع» كمجموعة غير مسموحة، لم يعد بإمكانهم رؤية أي مجموعات تتيح لهم ضبط مكون ليكون مرئياً للزوار. بالنسبة لي، يعني «قابل للاستخدام» ليس فقط العمل بشكل صحيح، بل أيضاً الظهور. وبما أنه لا يزال من الممكن تعطيل التغيير، فلن أصف الاعتماد فقط على المجموعات الجديدة بأنه «آمن».
همم، أنت على حق. هناك بضعة أمور أخرى تحتاج إلى إصلاح عند تعطيل التغيير القادم حتى تختفي مشكلة disallowed_group:
anonymous_users و logged_in_users غير موجودين في منتقي المجموعات على الإطلاق. أعتقد أنه من الآمن السماح بهما هنا الآن، عندها لن يهم ما إذا كنت قد أضفت everyone إلى disallowed_groups إذا تم تعطيل التغيير القادم.
إصلاح Guardian::AnonymousUser#in_any_groups? ليحترم anonymous_users عند تعطيل التغيير القادم.
إضافة نفس التسميات المستعارة لوقت القراءة 0 (everyone) → 5 (logged_in_users) لإعدادات السمات، وهو ما نفعله لإعدادات الموقع.
أعتقد أنني قد أضع علامة (legacy) على everyone في منتقي المجموعات بينما لا يزال التغيير القادم اختيارياً ومعطلاً.
سأعطي أولوية لهاتين المسائل وأضيفهما إلى خطتي الشاملة التي أعمل عليها.
إذن، هل كان بعض الأشخاص محيَين بأن كلمة “الجميع” تعني فقط المستخدمين المسجّلين؟
من؟!
“الجميع” تعني “الجميع” بالتأكيد — الأمر واضح جدًا.
“الجميع” تعني كل شخص يزور الموقع، سواء كان مسجّلًا أم لا، أليس هذا أمرًا بسيطًا؟
إذن، الآن يجب أن يكون لدى أي فئة عامة بالكامل حد أدنى من مجموعتين بدلًا من واحدة — المستخدمين المسجّلين والمجهولين؟ هذا أمر سخيف وليس ترقية.
وإن لم يكن الأمر كذلك، وإذا كان عليك فقط كتابة “مجهول” لأن هذه كلمة مرادفة لـ “الجميع” — فهذا لم يعد صحيحًا، لأن المستخدمين المسجّلين ليسوا مجهولين.
كان هناك بعض “التعلّم” حول كيفية استخدام Discourse، حيث كانت TL0 تعني في بعض الحالات “جميع من لديهم حساب ومسجّلون”، لكنها يمكن أن تعني أيضًا “أولئك الذين لم يصلوا بعد إلى مستوى الثقة 1 (TL1) لكن لديهم حساب وهم مسجّلون”.
النقطة الجوهرية هنا هي أنه لم يكن يمثل مجموعة واحدة من الأشخاص، بل كان يمثل حدًّا أدنى (Threshold)، وهذا كان هو المفتاح.
من خلال تغيير TL0 فقط إلى “المستخدمين المسجّلين”، فإنك الآن تكسر اتساق كون كل مستوى أمان يمثل حدًّا أدنى. فـ TL1 هو أيضًا حد أدنى وليس بالضرورة “مجموعة واحدة”. إذن، هل هذا يعني أننا بحاجة إلى مجموعة تُسمى “المستخدمون المسجّلون الذين يبلغون مستوى الثقة 1 على الأقل”؟!
لست مقتنعًا على الإطلاق بأي من هذا التغيير — تغيير من أجل التغيير؟
شكراً موي! لقد نسيت في الواقع أن الإعداد الجديد للمجموعات التفصيلية كان ضمن التغييرات القادمة على أي حال.
سأقوم بدمجه بعد تشغيل اختبارات التكامل المستمر.