مرحباً!
هل يمكنني الحصول على مراجعة لطلب السحب هذا؟
نحن نحاول إنشاء نقاش خاص بمنطقة معينة، حيث سيحدّ انتساب المستخدم من وصوله إلى مجموعات معينة، ولكن حاليًا يتعارض هذا مع دعم المستخدمين المجهولين لأن المستخدمين المجهولين ليس لديهم أي انتسابات للمجموعات.
يضيف طلب السحب هذا انتسابات للمجموعات للمستخدمين المجهولين.
هل فكرت في زيادة خطر هجمات إلغاء إخفاء الهوية التي قد يسمح بها هذا؟
شكراً لطرح هذا الموضوع!
لقد أخذت في الاعتبار هجمات إزالة إخفاء الهوية، وأنت على حق - وراثة مجموعات المستخدمين ليست أداة للجميع وهي عرضة للخطر بشكل خاص للمثيلات ذات الانتماءات العالية لمجموعات الكاردينالية. كما هو مفصل في طلب السحب (PR)، فإن المفهوم الأصلي لدعم النشر المجهول في المجموعات الإقليمية، والتي ستكون ضمنياً ذات كاردينالية منخفضة في مثيلنا.
تعديل: لقد أضفت سمة مجموعة تسمى anonymous_user_inheritance، والتي تسمح للمسؤولين باختيار ما إذا كانت المجموعة سيتم وراثتها بواسطة المستخدمين المجهولين أم لا. لقد أضفت أيضاً تحذيراً بجوار إعداد المسؤول لتمكين الميزة، وأنا منفتح على أي اقتراحات أخرى.
هل هذه الفئة الصحيحة لطلب مراجعات طلبات الدمج أم يجب علي النشر في فئة مختلفة؟
شكرا لك!
لا توجد فئة فعليًا لطلب مراجعات التعليمات البرمجية، على هذا النحو، لذا من المحتمل أن يكون هذا هو أفضل خيار لها.
غالبًا ما تكون طلبات السحب (PRs) مرحب بها، على الرغم من أنه من الجيد التأكد من أن هذا هو الاتجاه/الميزة التي ترغب Discourse في متابعتها قبل التعمق.
بدلاً من ذلك، يمكنك التفكير في تقديم هذه الميزة في مكون إضافي (plugin) بحيث تكون متاحة للاستخدام دون دمجها في التعليمات البرمجية الرئيسية.
شكرًا على النصيحة! ستكون الإضافة مناسبة تمامًا لاحتياجاتنا، باستثناء أن هذا التغيير يتطلب ترحيل قاعدة البيانات. هل سيكون ترحيل قاعدة البيانات ممكنًا في إضافة؟
نعم، يمكنك تشغيل عمليات ترحيل قاعدة البيانات في إضافة.
نعم، ولكن في رأيي، من الممارسات السيئة تعديل الجداول الأساسية في مكون إضافي.
إذا قمت بنقل هذا إلى مكون إضافي، فمن الأفضل استخدام group_custom_fields أو جدولك الخاص المخصص.
في هذه الحالة المحددة، يمكنك أيضًا (بدلاً من ذلك) إضافة إعداد موقع مثل “المجموعات الموروثة المسموح بها” والسماح للمسؤول بتحديد جميع المجموعات التي يمكن وراثتها في هذا الإعداد الفردي. سيؤدي ذلك إلى تبسيط الأمور بشكل كبير ويجمع كل الوظائف التي يوفرها المكون الإضافي في مكان واحد.
شكرًا على ملاحظاتك يا ريتشارد! هل يمكنك مساعدتي في فهم اقتراحك الثاني؟
جعل المسؤول يختار جميع المجموعات التي يمكن وراثتها في هذا الإعداد الفردي
للتحقق من فهمي، هل اقتراحك هو أن يكون هناك إعداد عام للموقع للسماح بتوارث المجموعات، ثم في صفحة إعدادات كل مجموعة على حدة، سيكون هناك مربع اختيار لتحديد ما إذا كانت هذه المجموعة قابلة للتوريث أم لا، بحيث يكون مشابهًا لما لدي الآن، باستثناء إزالة الإعداد المكرر.
جعل المسؤول يختار جميع المجموعات التي يمكن وراثتها في هذا الإعداد الفردي
هل كنت تقترح ما سبق، أم كان لديك شيء آخر في ذهنك؟ كانت فكرتي الأصلية هي بناء نوع من أداة الاختيار حيث توجد قائمة مربعات اختيار أو شيء من هذا القبيل، ولكن هذا يصبح معقدًا من الناحية التنفيذية بسرعة.
شكرًا على النصيحة بشأن المكونات الإضافية أيضًا! سأضع في اعتباري خيار المكونات الإضافية في المساهمات المستقبلية. 
لا، أنا أقترح ألا تجعل هذا إعدادًا في صفحة المجموعة، بل إعدادًا واحدًا على مستوى الموقع يحتوي على جميع المجموعات القابلة للتوريث بدلاً من ذلك.
إعداد مشابه هو المسؤول - الإعدادات - المستخدمون - مجموعات النشر المجهول المسموح بها. إنه ليس مربع اختيار في صفحة إعدادات كل مجموعة “السماح بالنشر المجهول لهذه المجموعة”، بل هو إعداد واحد مع جميع المجموعات التي تسمح بالنشر المجهول،
أو المسؤول - الإعدادات - النشر - مجموعات الإشارة المسموح بها هنا بدلاً من مربع اختيار في صفحة إعدادات كل مجموعة “السماح بالإشارات هنا لهذه المجموعة”.
إنه أسهل في التنفيذ، ويقلل من فوضى قاعدة البيانات، ويوفر رؤية أفضل لمسؤول المنتدى.