لذا، فيما يتعلق بفئة ‘ملاحظات الموقع’ المضمنة مسبقًا، عند التحرير، يوجد تحذير تحت علامة التبويب ‘الأمان’.
تحذير: هذه فئة مضمنة مسبقًا ولا يمكن تعديل إعدادات الأمان الخاصة بها. إذا لم ترغب في استخدام هذه الفئة، فاحذفها بدلاً من إعادة توظيفها.
أفهم أنه قد يكون هناك سبب وجيه وراء قفل قواعد أمان فئة ‘الموظفين’. ومع ذلك، لا يوجد قفل لقواعد أمان فئة ‘الصالة’ المضمنة مسبقًا. أعتقد أنه ينبغي التعامل مع فئة ‘ملاحظات الموقع’ بنفس طريقة التعامل مع فئة ‘الصالة’، مع إمكانية تعديل قواعد الأمان.
لست متأكدًا مما إذا كنت قد أغفلت بعض الآثار الضارة الناتجة عن إمكانية تعديل إعدادات الأمان لفئة ‘ملاحظات الموقع’. فجميع خيارات الفئة الأخرى الخاصة بها لا تبدو مقفلة.
تم ضبط الصالة بحيث يجب على المستخدم تحقيق مستوى ثقة 3 (TL3) للحصول على الوصول. تُعد الصالة امتيازًا أو مكافأة بطريقة ما للمستخدمين النشطين في المشاركة في المجتمع. إذا كنت تفضل تغيير مؤهلات الوصول إلى هذا النوع من الفئات، فلماذا لا تنشئ فئة جديدة مع أي مسموحات أمان تريدها؟
أما بالنسبة لملاحظات الموقع، فهل تعتقد أنه لأن المستخدم جديد ولم يحقق مستوى ثقة أعلى، فلن تكون لديه اقتراحات تفيد المجتمع؟ هذا يشبه قول “إذا كنت جديدًا، فلا نريد سماع ما لديك لتقوله”.
لم أجرب ذلك من قبل، ولكن قد يكون من الممكن إنشاء فئة جديدة مع إعدادات الأمان المفضلة لديك، ثم نقل جميع المنشورات إلى الفئة الجديدة، وحذف الفئة الأصلية. فقط تأكد من إعادة تسميتها بشكل مختلف عن site-feedback.
تم مناقشة هذا من قبل (محاولة تغيير إعدادات الأمان للفئات المُحمَّلة مسبقًا). فلماذا لا تنشئ ببساطة فئة جديدة وفقًا لمتطلباتك وتحذف الفئة المُحمَّلة مسبقًا؟
نعم، نقاط صحيحة يا @JimPas، وأنت محق تمامًا؛ حذفه وإعادة إنشائه هو حل مقبول. لا أعتقد أن هذه مشكلة كبيرة، لكنني أرى أن الافتراضي الأنسب هو السماح بتعديل إعدادات الأمان لتلك الفئة.
السماح للمستخدمين الجدد بنشر التعليقات، في كثير من الحالات، قد يكون مثاليًا. لكنني أعتقد أن جعل إعدادات الأمان لتلك الفئة مقفلة افتراضيًا لجميع المجتمعات قد يكون متحيزًا قليلاً أكثر من اللازم. لا أرى فائدة كبيرة في تقليل المرونة عبر قفلها.
إليك بعض الأسباب المحددة:
أحد أسباب قفل الأمان، وفقًا للرسالة المعروضة، هو منع إعادة استخدام الفئة. ومع ذلك، يمكن للمسؤولين إعادة تسمية الفئة وتعديل الرابط (slug)، ربما بسذاجة، لإعادة استخدامها كما يشاؤون (باستثناء عدم القدرة على تعديل خيارات إعدادات الأمان).
قد يرغب بعض المسؤولين في إخفاء فئة تعليقات الموقع عن المستخدمين غير المسجلين وعن عناكب الويب، مع السماح لجميع المستخدمين المسجلين (بما فيهم الجدد) برؤية المنشورات ونشر تعليقاتهم.
في بعض الحالات، قد يرغب المسؤول في إنشاء فئات فرعية لتعليقات الموقع أكثر تحديدًا، ومنع النشر في الفئة الأصلية، مما يجبر المستخدمين على اختيار فئة فرعية مناسبة لتعليقاتهم لتحسين تنظيم المواضيع. ولا أعتقد أن ذلك ممكن دون تعديل إعدادات الأمان.
يمكن للمسؤول حذف الفئة وإنشاء فئة جديدة كحل بديل. لكن قد لا يكون ذلك مثاليًا لمنتدى يعمل منذ فترة. ستكون للفئة الجديدة معرف (ID) ورابط مختلفان، مما يكسر أي روابط ثابتة موجودة مسبقًا أو روابط خارجية指向 تلك الفئة. مع ذلك، يمكنهم استخدام خيارات الروابط الدائمة كحل بديل لإعادة توجيه الفئة القديمة.
هذا بالضبط ما نريده نحن. كان تطوير منصة Discourse الخاصة بنا نشطًا للغاية خلال الأشهر القليلة الماضية، لكن الناس يحاولون الآن استخدامها كما هو مقصود (بديل للبريد الإلكتروني). لدينا عدد كبير من المنشورات المحلولة المتعلقة بإعداد وصيانة المنتدى، والتي لا يهتم بها المستخدم العادي على الإطلاق.
لدينا الفئة الرئيسية، وهي غير مصنفة، ونشجع جميع المستخدمين ببساطة على استخدام @staff عندما يرغبون في تقديم ملاحظات. بل إننا ندرج هذا في الوصف الذي يظهر عندما يكون الشخص على وشك صياغة موضوع جديد. كما أن لدينا مواضيع مخصصة لـ “أبلغ عن أي مشاكل في المنتدى هنا” حيث نبلغ عما إذا قمنا بتحديث وإضافة الميزات المطلوبة في الموضوع، بالإضافة إلى تشجيع مدخلات المستخدمين.
بالتأكيد. الأمر لا يتعلق بتقييد الوصول إلى هذه البيانات. إذا دخلت إلى منزلي، فلا أترك جميع مخططاتي المعمارية وفواتيري مبعثرة على الأرض والطاولات. إذا أراد الناس ذلك، فهم سعداء بإيجاد مثل هذه المعلومات بطريقة مختلفة… ربما من خلال مجموعة الموظفين أو ما شابه، حيث يمكن للمستخدمين الاشتراك تلقائيًا بقدر ما يمكنهم إلغاء الاشتراك.
إنه توازن بين الاستخدام اليومي وتلك التي يفضلها المستخدمون صراحةً لتجربة الميزات التجريبية.
ليست هذه هي الحالة في منتدى نحن، بل أكثر من ذلك: في أي نقطة نخفي السقالات / نحد من رؤية البناء الثقيل للمستخدمين في المجتمع الذين يحاولون حقًا إنجاز الأمور.
في منتدانا، لدينا فئة ملاحظات الموقع وأخرى تسمى META. وفي فئة META، يمكن لمستخدمي إنشاء مواضيع جديدة حول مشكلات محددة يواجهونها. وبمجرد حل هذه المشكلات، يتم وضع علامة “تم الحل” عليها. أما فئة ملاحظات الموقع، فهي كما كانت عند إنشائها لأول مرة. ولكن تجدر الإشارة إلى أن لدينا منتدى صغيرًا يضم أشخاصًا “يعرفون” بعضهم البعض منذ أكثر من 7 سنوات من منتدى آخر توقف عن العمل الآن.
فئة حول التي كانت تُسمى سابقًا “مايتا”. لدينا مجموعة تسمي نفسها “مايتا”، لذا قررنا منحهم اسم هذه الفئة لتقليل الارتباك. الأمر ليس كبيرًا، لكننا نود إخفاء فئة حول هذه للأشخاص غير المسجلين الذين لا سببًا لديهم لرؤيتها. وقد يكون من المنطقي أيضًا تقييدها بمجموعة عامة بسيطة فقط.
فئة طاقم العمل - منشورات تقنية وعشوائية حول التكامل لا نريد أن تزدحم بها المنتدى. لم نختبر بعد ميزة ملاحظات الطاقم، لذا فإن هذه الفئة تؤدي هذا الدور حاليًا.
لاحظت أن معظم النقاشات تجري في فئة “غير مصنفة”، وهي مكان النقاش الافتراضي لدينا. يستمتع الناس بالوسوم كثيرًا، لكن ربما سمحنا لأي شخص بإنشائها بشكل مفرط في المرونة.
هذا هو السبب الرئيسي لدي. الأشخاص الذين ليسوا مسجلين على الأرجح لا يهتمون بإعدادات المنتدى. هم فقط يريدون رؤية النقاشات العامة وما إلى ذلك.
إذا كان المستخدمون الذين لا يرغبون في تلقي منشورات من فئة “ملاحظات الموقع”، فيمكنهم دائمًا كتم هذه الفئة في تفضيلاتهم. يجب أن يمنع ذلك ظهور المنشورات غير المرغوب فيها من تلك الفئة أو الفئة بأكملها في قسم “الأحدث”. وإذا قرروا الاطلاع عليها بين الحين والآخر، فيمكنهم دائمًا التمرير لأسفل قائمة الفئات والدخول إليها من هناك.
لكنني أعتقد أن هذا بدأ ينحرف قليلاً عن السؤال الأصلي من @markersocial - وهو السماح بتعديل قواعد الأمان لفئة “ملاحظات الموقع”.
(سيظل من الجيد مواصلة هذه المناقشة حول الاستخدامات المختلفة لفئاتك.)
لماذا لا يمكن للمستخدمين ببساطة إنشاء موضوع جديد في فئة “ملاحظات الموقع” يكون محددًا لملاحظاتهم الخاصة؟ لدينا عدة مواضيع في فئة “ملاحظات الموقع” لدينا تم إنشاؤها بواسطة المستخدمين. إنه أشبه بصندوق الاقتراحات وطرح الأسئلة. وعندما يواجه المستخدمون أي مشاكل، ينشرون في فئة استكشاف الأخطاء وتصحيحها المسماة بشكل مناسب “ما وراء النصوص”.
الحل السريع للسبب الذي اقترحته سيكون ببساطة:
إنشاء فئة بعنوان “ملاحظات”،
إنشاء أي فئات فرعية تريدها ليتمكن المستخدمون من إنشاء مواضيع فيها،
ثم ضبط الفئة الرئيسية بحيث لا يمكن لأي شخص النشر فيها.
لكن… هل ستمنع هذه الإعدادات المستخدمين من النشر في الفئات الفرعية؟
لم أجرب هذا من قبل. يبدو وكأنه تجربة مثيرة للاهتمام، لكنني ذاهب إلى الفراش بعد وقت قصير. ربما غداً سأجرب ذلك - ما لم يتدخل أحد أعضاء الفريق هنا لشرح ما إذا كان هذا سيعمل أم لا.
إذن، السؤال الرئيسي الذي أراه هو: ما هي فوائد قفل إعدادات الأمان لفئة ملاحظات الموقع المبدئية المثبتة مسبقًا لجميع التثبيتات؟
لا أستطيع التفكير حقًا في أي فوائد لذلك، بل يبدو وكأنه عائق غير ضروري دون أي عواقب سلبية عند إزالته. يمكن للتثبيتات الجديدة الحصول على إعدادات الأمان الموصى بها افتراضيًا، مع السماح بالمرونة لأي حالات استخدام خارج ذلك. ببساطة مثل فئة Lounge المبدئية المثبتة مسبقًا.
إنها ليست مشكلة كبيرة، نظرًا وجود حلول بديلة عن طريق حذفها وإعادة إنشائها كما اقترحت . ومع ذلك، فإن الأمر يصبح أقل أناقة قليلاً إذا كان المنتدى قديمًا ويريد تعديل هذه الإعدادات لاحقًا مع نمو المنتدى، لأن ذلك يغير عنوان URL للفئة (يمكن استخدام admin > customize > permalinks للمساعدة في ذلك).
نعم، صحيح، يمكنهم إنشاء موضوع في فئة ملاحظات الموقع المحددة الخاصة بملاحظاتهم. قد يكون من المفيد إجبار استخدام الفئات الفرعية لكل موضوع في بعض حالات الاستخدام، خاصة في الحالات التي تكون فيها المنتديات جزءًا من علامة تجارية متنوعة قد يكون لديها عدة مواقع/تطبيقات ومنتجات موجهة للمستخدم.
قد تكون بعض الملاحظات متعلقة بالمنتجات الرئيسية للشركة والجوانب المصنفة المحددة لها، أو قد تكون متعلقة بالمنتدى نفسه. يحتوي هذا المنتدى نفسه على فئة فرعية لملاحظات الموقع للمدونة، والتي تم تعيين مجموعة وسوم مختلفة لها أيضًا.
بخصوص ذلك، لقد استخدمت هذا سابقًا لبعض الفئات (منع النشر في الفئة الأصلية، لكن السماح بالنشر في فئاتها الفرعية). قواعد أمان الفئات الفرعية لا تتأثر بقواعد أمان الفئة الأصلية. لذا نعم، هذا بالفعل حل.
شكرًا لك. هذا يوفر عليّ عناء التحقق من ذلك. لقد أضعت ما يقرب من 5 ساعات اليوم بسبب زيارة غير متوقعة من حفيدة عمرها 3 سنوات كانت تريد فقط من جدها أن يلعب معها.
الآن سأقوم أخيرًا بفحص منتداي الخاص.
إنه موجود كحل بديل لقيود تقنية - فإذا أردنا نحن (Discourse) يومًا ما تحديث الإعدادات الافتراضية أو تغيير الاسم المُترجم للفئة، فسيؤدي ذلك إلى ارتباك هائل إذا أعاد الأشخاص استخدام الفئة المُعدة مسبقًا كفئة “عادية” ثم تغيرت فجأة يومًا ما بسبب تحديثنا للإعدادات الافتراضية. (نعم، حدث هذا بالفعل. وهذا هو السبب في وجود هذه القيود.)
منعك من تعديل إعدادات الأمان يعمل كتذكير بأنها خاصة وخاضعة لتحديثات الإعدادات الافتراضية.
وبما أن ميزة التحديث التلقائي هي الشيء الوحيد الذي يجعل هذه الفئات خاصة، فإن نص المساعدة يطلب منك حذف الفئة بالكامل وإنشاء فئة جديدة بدلاً من إعادة استخدامها.
إذا كان إعادة استخدام الفئة ضارًا جدًا، وهو ما لا أشجّعه، فربما يكون إضافة تحذير في إعدادات إعادة تسمية الفئة أكثر منطقية؟ فقواعد الأمان لا تبدو مرتبطة ارتباطًا مباشرًا قويًا بتلك المشكلات المحتملة.
سأسلّط الضوء على بعض النقاط:
فئة “الصالون” تبدو في نفس القارب القابل للتحديث تلقائيًا، لكن إعدادات الأمان قابلة للتعديل.
يمكن إعادة تسمية فئة “ملاحظات الموقع” (تغيير العنوان والاسم التعريفي) دون ملاحظة قفل قواعد الأمان فعليًا. فهي تحمل نفس قواعد الأمان الافتراضية لفئة “عادية” جديدة.
القفل يمنع تغييرات بسيطة نسبيًا مثل إظهار الفئة للمستخدمين المسجلين فقط أو تقييدها بمستويات ثقة معينة.
@ستيفن - أرى فئة الصالة مستشهدًا بها في postgres في جدول ‘site_settings’. لست متأكدًا تمامًا من مدى فائدتها، لكنني أظن أنها تُعالج بشكل مشابه. عندما قمت بالتجربة مع ‘meta_category_id’ (فئة ملاحظات الموقع) في مثيل تجريبي، فقد أثر ذلك على فئة ملاحظات الموقع أثناء إعادة البناء.
لقد جربته للتو على نسخة تجريبية وعمل بشكل جيد، رغم أنه كان مع عدد قليل من المواضيع فقط.
لذا، اتصل بسيرفرك عبر SSH ثم استخدم الأوامر التالية (في هذا المثال، سيتم نقل جميع المواضيع في الفئة 2 إلى الفئة 1، لذا استبدل هذه الأرقام حسب الحاجة):
cd /var/discourse
./launcher enter app
rails c
Topic.where(category_id: 2).update_all(category_id: 1)
يمكنك الحصول على معرفات الفئات من الأرقام في نهاية روابط الفئات.
تعديل: المشكلة الوحيدة هي أنه سينقل أيضًا منشور “حول هذه الفئة”، ويبدو أنه لا يمكن نقله مرة أخرى أو حذفه من واجهة المسؤول. يمكن جعله غير مدرج، لكنني لست متأكدًا مما إذا كان ذلك سيسبب مشاكل. امنحني لحظة، سأقوم بالتحديث قريبًا.
تعديل 2: لذا لنقل موضوع “حول هذه الفئة” مرة أخرى إلى الفئة الصحيحة. استخدم هذا الأمر فقط (حيث يكون معرف الموضوع هو 1 والفئة المطلوبة لنقله إليها هي 2). جربته للتو وعمل:
Topic.where(id: 1).update_all(category_id: 2)
يمكنك الحصول على معرف الموضوع من نهاية رابط الموضوع تمامًا مثل معرفات الفئات.
وفي فئة META، يمكن لمستخدمي إنشاء مواضيع جديدة حول مشكلات محددة يواجهونها. وبمجرد حل هذه المشكلات، يتم وضع علامة “تم الحل” عليها. أما فئة ملاحظات الموقع، فهي كما كانت عند إنشائها لأول مرة. ولكن تجدر الإشارة إلى أن لدينا منتدى صغيرًا يضم أشخاصًا “يعرفون” بعضهم البعض منذ أكثر من 7 سنوات من منتدى آخر توقف عن العمل الآن.
