كان هناك ما يُعرف بمجموعة وهمية مربكة تاريخيًا تسمى @everyone داخل قاعدة الكود لدينا، ويمكن استخدامها في:
إعدادات الموقع من نوع group_list
أذونات التصنيفات
مجموعات الوسوم
في بعض الحالات، يُفسّر البعض @everyone على أنها تعني “جميع المستخدمين المجهولين وجميع المستخدمين المسجلين دخولهم”، بينما يفسرها آخرون على أنها تعني فقط “جميع المستخدمين المسجلين دخولهم”. والحقيقة في حالة إعدادات الموقع هي أنها تعني في معظم الحالات فقط “جميع المستخدمين المسجلين دخولهم”.
يزيد من هذا الارتباك حقيقة أن مجموعة @everyone هذه يمكن استخدامها في إعدادات الموقع حيث لا معنى لمنح “جميع المستخدمين المجهولين والمسجلين دخولهم” حق الوصول إلى الميزة، مثل pm_tags_allowed_for_groups.
هذا الأمر مربك أيضًا من منظور تمكين الميزات وتجربة المطورين، حيث قد نرغب فعليًا في تمكين بعض التغييرات القادمة أو إعدادات أخرى لـ “جميع المستخدمين المجهولين والمسجلين دخولهم”.
الحل
نحن نُدخل مجموعتين وهميتين تلقائيتين منفصلتين:
anonymous_users (ID 4) - تمثل المستخدمين المجهولين الذين يزورون موقعك دون حساب
logged_in_users (ID 5) - تمثل جميع المستخدمين المسجلين دخولهم إلى موقعك، وهي مشابهة في تأثيرها للمجموعة التلقائية trust_level_0، لكنها أكثر تحديدًا
تم إدخال هاتين المجموعتين بالفعل، لكنهما ستأخذان مفعولهما فقط عند تمكين التغيير القادم granular_anonymous_and_logged_in_groups_permissions في موقعك.
عند تمكين التغيير القادم، سيتم تحويل أي إعداد يحتوي على everyone كمجموعة مختارة تلقائيًا إلى معرف مجموعة logged_in_users، لذا لن يتغير أي بيانات في جدول إعدادات الموقع عند تبديل التغيير القادم. وعندما يصبح التغيير القادم دائمًا، سنقوم بهجرة البيانات لجميع إعدادات المجموعات لإجراء هذا التغيير.
بالإضافة إلى ذلك، قمنا بوضع علامة disallowed_group على مجموعة anonymous_users في عدة إعدادات لموقع حيث لا معنى لها، مثل personal_message_enabled_groups.
هل يمكن لأي شخص مساعدتي في فهم كيفية تعديل مكونات السمة الخاصة بي؟
لقد حاولت استخدام مكون copy-post كمثال، لأنني أتذكر أنه يستخدم أيضًا إعداد مجموعة يمنح الوصول إلى الميزة. وكان هناك مشكلة لأن المجموعة الوهمية «الجميع» تتطلب فحصًا منفصلًا، تمامًا كما في مكوني، لأن مقارنة معرفات المجموعات التي ينتمي إليها المستخدم لا تساعد — بل يجب فحص هذه المعرفات بشكل منفصل. لهذا السبب توقعت حدوث تغيير حديث هناك، لأنني أفهم أن المجموعات الجديدة هي أيضًا مجموعات وهمية، ويجب فحص المعرف بشكل منفصل. هل هناك شيء أغفله يفسر لماذا لا يكون هذا ضروريًا هنا؟
يحتوي مكون تصفية المفضلة المفضلة لدي على إعدادين للمجموعات: أحدهما يسمح للمجموعات بحفظ تصفحاتها الخاصة، والآخر يقدم تصفحات قياسية.
بشكل افتراضي، يمكن فقط لأعضاء مجموعة trust_level_0 استخدام التصفحات المخصصة، لأن فقط المستخدمين المسجلين يمكنهم تخزين البيانات في حقل مستخدم مخصص. لذا، هنا سيكون من المنطقي إذا لم أسمح بـ anonymous_users كخيار. كيف أفعل ذلك في مكون سمة؟ هل هناك مثال جاهز لهذا؟
الإعداد الافتراضي للتصفحات الافتراضية هو «الجميع»، لأنني أجد أنه مفيد حتى للمستخدمين غير المسجلين أن يتمكنوا من رؤية واستخدام التصفحات الافتراضية. المشكلة هي أن everyone يتحول إلى logged_in_users حتى مع أنني اخترته تحديدًا. هل يجب علي إنشاء هجرة مخصصة لهذا الغرض بحيث يستمر المشرفون الذين يستخدمون حاليًا everyone في الحصول على تصفحات للمستخدمين غير المسجلين في المستقبل؟ متى يجب أن تتم هذه الهجرة؟ أم أن كل مشرف يجب أن يغير ذلك بشكل فردي بعد تشغيل الهجرة؟
هل كل ما أقلق بشأنه غير ضروري حقًا؟ إذا كانت هناك حاجة إلى تعديلات، فإن أقل من أربعة أسابيع تبدو إطارًا زمنيًا قصيرًا جدًا بالنظر إلى عدد المكونات التي يديرها المجتمع والتي قد تتأثر محتملًا.
بالإضافة إلى «copy-post»، نظرت أيضًا في مكون تصفية غير المجاب، لكنني لم أجد أي تغييرات هناك أيضًا. أشعر أنني أغفلت شيئًا مهمًا. بعد كل شيء، تم تمكين التغيير افتراضيًا منذ أسبوع تقريبًا. لهذا أفترض أنه لو كانت هناك حاجة إلى تعديلات، لكانت المكونات الرسمية قد تم تحديثها بالفعل.
بالنظر إلى هذه المكونات، فإن currentUser?.groups غير موثوقة على أي حال، لأنها تتضمن فقط المجموعات المرئية للمستخدم، وقد لا تُسلسل المجموعات التي ينتمي إليها المستخدم وتؤثر على الصلاحيات هنا:
نتجاوز هذه المشكلة في النواة/الإضافات من خلال القيام بأشياء مثل هذا في مُسلسل المستخدم الحالي:
لكن من الواضح أن هذا غير متاح لمكونات السمات/السمات وإعداداتها.
هـ، لست متأكدًا، سأحتاج إلى التفكير في هذا. إذا كنت تقصد حقًا everyone، فسيكون من الضروري تغييرها إلى كل من logged_in_users و anonymous_users. كانت هذه هي المشكلة الرئيسية مع everyone كما ورد في المنشور الأصلي — بعض الناس فسروها على أنها تعني فقط المستخدمين المسجلين، بينما فسر آخرون أنها تعني المسجلين + المجهولين، وكان الأمر يعتمد كثيرًا على الموقف.
اخترت تفسير «فقط المستخدمين المسجلين» لأنه كان أكثر أمانًا من وجهة نظر أمنية.
كلا، لم أفكر ببساطة في مكونات السمات/السمات وإعداداتها وكيف ستتأثر بهذا التغيير، كنت أركز في الغالب على إعدادات الموقع. ستكون أشياء مثل هذه صعبة للغاية في العثور عليها، لأنها لا تستخدم حتى ثابت AUTO_GROUPS:
على أي حال، سأفكر في بعض الحلول لهذه المشكلات، ولن أنتقل بهذا التغيير إلى الإصدار المستقر حتى أتمكن من حلها.
هل يعني ذلك أن جميع الفئات التي هي الآن عامة (للجميع) ستتحول إلى فئات مغلقة تتطلب تسجيل الدخول عند تمكين ذلك؟
