أوضاع القراءة فقط في Discourse

[Discourse]

يشرح هذا الدليل أوضاع القراءة فقط المتاحة في Discourse، وكيفية تمكينها وتعطيلها، والسيناريوهات التي قد ترغب في استخدام كل وضع فيها.

مستوى المستخدم المطلوب: المسؤول

يتطلب إدارة مجتمع عبر الإنترنت نابض بالحياة على Discourse أحيانًا من المسؤولين تقييد نشاط المستخدمين مؤقتًا. يمكن أن تتراوح هذه الحالات من إجراء صيانة الخادم، أو تسهيل النسخ الاحتياطي، أو نقل الخوادم. خلال هذه الأوقات، من الضروري تقييد أنشطة المنتدى دون إغلاق وصول المستخدمين تمامًا.

يقدم Discourse أوضاع قراءة فقط مختلفة يمكن للمسؤولين تمكينها لتجميد أنواع مختلفة من التفاعلات داخل الموقع مؤقتًا.

يستكشف هذا الدليل هذه الأوضاع، مع التركيز تحديدًا على كيفية تمكينها وتعطيلها، بما في ذلك التعامل مع الحالات التي تتداخل فيها أوضاع معينة.

فهم أوضاع القراءة فقط

يدعم Discourse مستويين مختلفين من أوضاع القراءة فقط مصممين ليناسبوا احتياجات إدارية متنوعة. وهي:

1. وضع القراءة فقط الكامل

• يقيّد جميع عمليات الكتابة في المنتدى، مما يمنع أي مستخدم من إنشاء أو تعديل المحتوى، مثل النشر، أو التعليق، أو الإعجاب.
• يسمح للمنتدى بأن يكون “مجمّدًا” في حالته الحالية، مما يسمح للمستخدمين بقراءة المحتوى الحالي والتنقل فيه دون التأثير على قاعدة البيانات.
• يمنع تغيير أي إعدادات موقع للمسؤول أو تخصيصات الموقع للحفاظ على الحالة الحالية لقاعدة البيانات.
• يعطل تسجيل الدخول الجديد للمستخدمين العاديين. لا يزال بإمكان المسؤولين تسجيل الدخول باستخدام تدفق تسجيل الدخول عبر البريد الإلكتروني للمسؤول (/u/admin-login).

2. وضع الكتابة للموظفين فقط

• يقيّد المستخدمين العاديين من عمليات الكتابة في المنتدى، مثل النشر، أو التعليق، أو الإعجاب. يقتصر المستخدمون العاديون على عمليات القراءة فقط، لكنهم لا يزالون قادرين على تسجيل الدخول إلى حساباتهم.
• يسمح بنشاط المسؤولين والمحررين بالاستمرار بشكل طبيعي. يمكن للمسؤولين تغيير إعدادات الموقع، ويمكن لمستخدمي الموظفين تنفيذ عمليات كتابة مثل النشر، أو الإعجاب، أو تعديل الملفات الشخصية.

تضمن هذه الأوضاع المرونة في إدارة قابلية تشغيل المنتدى خلال الفترات الإدارية الحرجة.

كيفية تمكين/تعطيل أوضاع القراءة فقط

يجب على المسؤولين إدارة الانتقال بين أوضاع القراءة فقط المختلفة بعناية. قبل تمكين أي وضع قراءة فقط، تأكد من تعطيل أي وضع تم تفعيله سابقًا.

وضع القراءة فقط الكامل

عبر وحدة تحكم Rails

إذا كان لديك وصول إلى تثبيت Discourse، فاستخدم واجهة سطر أوامر Rails الخاصة بـ Discourse لتنفيذ الأمر التالي بعد الدخول إلى حاوية Docker الخاصة بك باستخدام ./launcher enter app ثم وحدة تحكم Rails باستخدام rails c:

Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

عبر لوحة المسؤول

إذا كان لديك وصول إداري عبر واجهة الويب، فيمكنك الانتقال إلى Admin > Backups > Enable Read-Only Mode لتمكين وضع القراءة فقط.

لتعطيل وضع القراءة فقط، نفذ أمر Rails التالي:

Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY)

أو، استخدم لوحة المسؤول بالانتقال إلى Admin > Backups > Disable Read-Only Mode.

وضع الكتابة للموظفين فقط

يمكن تمكين/تعطيل وضع الكتابة للموظفين فقط من وحدة تحكم Rails الخاصة بـ Discourse فقط. إذا كان موقعك مستضافًا بواسطة Discourse، يرجى التواصل مع team@discourse.org إذا كنت ترغب في تمكين أو تعطيل أي من هذه الأوضاع.

لتمكين وضع الكتابة للموظفين فقط، استخدم أمر وحدة تحكم Rails التالي:

Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

للتعطيل:

Discourse.disable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)

أفضل الممارسات

• التواصل في الوقت المناسب: أبلغ مجتمعك بفترات القراءة فقط المجدولة مسبقًا لوضع توقعات مناسبة.
• الاختبار: قبل تنفيذ هذه الأوضاع أثناء العمليات الحرجة، قم بإجراء اختبارات خلال فترات انخفاض حركة المرور لفهم تأثيرها.
• التوثيق: احتفظ بسجلات مفصلة عن متى ولماذا تم تمكين أو تعطيل كل وضع للمساعدة في التخطيط التشغيلي المستقبلي.

الأسئلة الشائعة

• كم من الوقت يستغرق تمكين/تعطيل وضع القراءة فقط؟

  • التغيير فوري. ومع ذلك، قد يختلف تجربة المستخدم قليلاً اعتمادًا على إجراءاتهم خلال فترة الانتقال.

• مساعدة! لقد تم إقصاؤي من موقعي بسبب وضع القراءة فقط - ماذا يمكنني أن أفعل للوصول إلى موقعي مرة أخرى؟

  • انظر: تسجيل الدخول مرة أخرى كمسؤول بعد إقصاء نفسك باستخدام وضع القراءة فقط أو تكوين SSO غير صالح

• لاحظت أن هناك أوضاع READ-ONLY أخرى مدرجة في discourse/lib/discourse.rb، ماذا تفعل هذه الأوضاع؟

  • يُستخدم READONLY_MODE_KEY بشكل أساسي لعملية النسخ الاحتياطي والاستعادة ويتم تفعيله بواسطة التطبيق نفسه. يمكن أيضًا تمكين أو تعطيل هذا الوضع من واجهة سطر أوامر Discourse باستخدام discourse enable_readonly و discourse disable_readonly. ومع ذلك، لن يظل هذا المفتاح ساريًا بعد إعادة تشغيل الحاوية.
  • يُستخدم USER_READONLY_MODE_KEY عندما يضغط المسؤول على زر القراءة فقط في واجهة المسؤول. الشيء الخاص بهذا المفتاح هو أننا لا نعيّنه كمفتاح منتهي الصلاحية لأن وضع القراءة فقط الذي تم تفعيله بواسطة مستخدم يحتاج إلى البقاء بعد إعادة تشغيل الحاوية. يتم تعيين المفاتيح الأخرى بوقت انتهاء صلاحية (60 ثانية لـ READONLY_MODE_KEY، و 300 ثانية لـ PG_READONLY_MODE_KEY) ولدينا خيط لتوسيع انتهاء الصلاحية كل 30 ثانية لضمان عدم بقاء التطبيق عالقًا في وضع القراءة فقط.
  • يُستخدم PG_READONLY_MODE_KEY و PG_FORCE_READONLY_MODE_KEY لعملية التحويل الفاشل في PG. الأول يتم تعيينه كمفتاح منتهي الصلاحية بينما الثاني غير منتهي الصلاحية.

[Ed_S]

@SaraDev

2. وضع قراءة فقط للمستخدم

• يقيد المستخدمين القياسيين من إجراء عمليات الكتابة مثل النشر أو الإعجاب أو تعديل الملفات الشخصية.
• يسمح لأنشطة المسؤول والمشرف بالاستمرار بشكل طبيعي.

3. وضع كتابة للموظفين فقط

• يسمح فقط لأعضاء هيئة الموظفين (المسؤولين والمشرفين) بالكتابة في المنتدى.
• يقتصر المستخدمون القياسيون على عمليات القراءة.

لا أرى فرقًا! هل يمكن تعديل هذه الأوصاف وفقًا لذلك، إذا كان هناك بالفعل فرق؟

[SaraDev (Sara Devlaeminck)]

@Ed_S

لا أرى فرقًا! هل يمكن تعديل هذه الأوصاف وفقًا لذلك، إذا كان هناك بالفعل فرق؟

لقد قمت بتحديث الدليل لتقديم توضيح إضافي هنا، يُرجى إخبارنا إذا كانت لا تزال لديك أي أسئلة حول أي من أوضاع القراءة فقط.

[pfaffman (Jay Pfaffman)]

ولكن ماذا يفعل الأمر

discourse enable_readonly؟

script/discourse

إنه يستخدم READONLY_MODE_KEY، والذي يضبط ttl على 60، لذا يتم إيقافه مرة أخرى في مرحلة ما. الآن أرى أن

@SaraDev

يمكن أيضًا تمكين هذا الوضع أو تعطيله من واجهة سطر أوامر Discourse باستخدام discourse enable_readonly و discourse disable_readonly. ومع ذلك، لن تدوم هذه المفتاح بعد إعادة تشغيل الحاوية.

هل هناك أي سبب لأن يكون هذا هو السلوك الافتراضي لهذا الأمر؟ لقد استغرق الأمر مني ما يقرب من عقد من الزمان لأتعلم أن هذا الأمر يختلف تمامًا عن وضع القراءة فقط في واجهة الويب حتى بعد أن تعرضت للحرق عدة مرات. وأتذكر الآن أن شخصًا ما حاول إخباري عن هذه المفاتيح مرة واحدة وفشلت في فهم أهميتها.

في رأيي، سيكون الشيء الأكثر منطقية الذي يقوم به discourse enable_readonly هو تنفيذ Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY). أتمنى لو لاحظت ذلك منذ سنوات عديدة!

هل يمكنني تقديم طلب سحب (PR) شيء كهذا:

  desc "enable_readonly", "تمكين وضع القراءة فقط، مما يسمح بكتابة الموظفين"
  def staff_writes_only
    load_rails

    Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY)
    puts 'الموقع الآن في وضع القراءة فقط مع السماح بكتابة الموظفين.'
  end

[pmusaraj (Penar Musaraj)]

@pfaffman

IMHO a much more sane thing for discourse enable_readonly to do would be to do a Discourse.enable_readonly_mode(Discourse::STAFF_WRITES_ONLY_MODE_KEY). I wish I’d noticed that many years ago!

لستُ على دراية تامة بهذا، ولكني أعتقد أنه سيكون مربكًا لـ enable_readonly_mode تعيين الموقع إلى staff_writes_only_mode. إنهما وضعان مختلفان، عند إجراء عمليات معينة، لن ترغب في السماح للموظفين بالكتابة في قاعدة البيانات (أثناء الاستعادة، على سبيل المثال، سيتم إزالتهم).

ربما يمكننا بدلاً من ذلك القيام ببعض الأشياء الأخرى هنا:

1. توضيح أن وضع القراءة فقط يحدد وقتًا محددًا (TTL) في وصف تلك المهمة.
2. إضافة مهمة تستدعي keep_readonly_mode حتى يمكن تمديدها لأكثر من 60 دقيقة.
3. إضافة مهام enable_staff_writes_only و disable_staff_writes_only.

[pfaffman (Jay Pfaffman)]

@pmusaraj

لست على دراية تامة بهذا، ولكن أعتقد أنه سيكون مربكًا لـ enable_readonly_mode لتعيين الموقع على staff_writes_only_mode.

أتفق، ولكن سيكون أقل إرباكًا من “تعيين وضع القراءة فقط لفترة من الوقت”.

@pmusaraj

تريد من الموظفين عدم السماح بالكتابة في قاعدة البيانات (أثناء الاستعادة، على سبيل المثال، سيتم إزالتهم).

أنا متأكد من أن نص الاستعادة يضبط وضع القراءة فقط بنفسه، لذلك لا يتأثر بهذا الأمر.

@pmusaraj

• توضيح أن وضع القراءة فقط يضبط TTL في وصف تلك المهمة

أفضل أن يعلن أنه تم تعيينه لمدة X دقائق عند تعيينه. ليس من السهل العثور على الوصف.

@pmusaraj

• إضافة مهمة تستدعي keep_readonly_mode حتى يمكن تمديدها إلى أكثر من 60 دقيقة

ربما. لست متأكدًا من سيستخدمها.

@pmusaraj

1. إضافة مهام enable_staff_writes_only و disable_staff_writes_only

سيكون ذلك رائعًا!

أيضًا، نحتاج إلى توضيح أننا لا نخلط بين مهام rake والأوامر المتاحة من خلال أمر discourse.

[pmusaraj (Penar Musaraj)]

@pfaffman

أفضل أن يعلن أنه مضبوط لمدة X دقائق عند ضبطه. ليس من السهل العثور على الوصف.

منطقي. هل هناك أي فرصة لتقديم هذا كـ PR؟ نفس الشيء بالنسبة لأوامر enable_staff_writes_only و disable_staff_writes_only، إن أمكن. شكراً!

[Ethsim2 (Ethan)]

أنا فضولي بشأن أي الساعات تتوقف بعد بدء التشغيل في وضع القراءة فقط؟ هل ستحدث ارتفاعات في الموضوع بعد تعيين وضع القراءة فقط؟

[Ethsim2 (Ethan)]

يبدو أيضًا أن التحديثات لا تعمل إذا تم تعيين وضع القراءة فقط بواسطة واجهة مستخدم الويب