بحاجة إلى مساعدة في تحديد مشاركات المستخدم حسب الفئة والإطار الزمني

مرحباً بالجميع،

أبحث عن بعض الإرشادات حول كيفية تحقيق وظيفة معينة في Discourse. أنا أدير مجتمعًا حيث أحتاج إلى تطبيق قاعدة تمنع المستخدمين من إنشاء موضوع جديد في فئتين محددتين إذا كانوا قد نشروا بالفعل في أي من هاتين الفئتين خلال الـ 14 يومًا الماضية. يجب أن ينطبق هذا القيد حتى لو تم حذف موضوعهم السابق.

بعد بعض البحث، عثرت على discourse-flexible-rate-limits، والذي يبدو أنه قد يكون نقطة انطلاق جيدة. يسمح بحدود معدل مرنة بناءً على مجموعات المستخدمين والإجراءات، ولكنه يركز على التردد قصير المدى (دقائق، ساعات، أيام) ولا يدعم بشكل مباشر:

  1. التحقق من المشاركات عبر فئات متعددة.
  2. فرض إطار زمني يصل إلى 14 يومًا.
  3. تضمين المواضيع المحذوفة في الفحص.

قبل التعمق في تخصيص هذه الإضافة أو إنشاء شيء من الصفر، أردت أن أسأل:

  • هل يعرف أحد أي إضافة موجودة أو طريقة قد تتعامل بالفعل مع هذا النوع من الوظائف؟
  • هل هناك أساليب موصى بها لتعديل إضافة موجودة مثل discourse-flexible-rate-limits لتضمين قيد عبر الفئات وطويل الأجل؟
  • أي نصائح عامة حول كيفية تنفيذ هذا بفعالية؟

سأكون ممتنًا لأي رؤى أو اقتراحات من هذا المجتمع الرائع. إذا كان هناك اهتمام، فسأكون سعيدًا أيضًا بمشاركة التحديثات حول كيفية تنفيذي لهذا في النهاية.

شكرًا جزيلاً مقدمًا على مساعدتكم!

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

من المحتمل أن يكون العمل من 3 إلى 5 ساعات، وربما أكثر مع مواصفات/اختبارات جيدة.

إعجابَين (2)

مرحباً، @pfaffman ، أتمنى لك عطلة سعيدة وشكراً على الرد!

لقد حاولت إنشاء مخطط انسيابي لتوضيح الأمر:

flowchart TB
    A0(يحاول المستخدم إنشاء موضوع جديد في الفئة أ أو ب) -- --> A1{هل المستخدم في<br>مجموعة معفاة--مسؤول، مشرف، TL3، TL4، مشتركين؟}
    A1 -- لا -- --> B1(تحقق من آخر موضوع للمستخدم في الفئات أ، ب، أو ج،<br>بما في ذلك السجلات المخفية أو المحذوفة)
    A1 -- نعم -- --> Z1(السماح بالنشر)

    B1 -- --> B2{هل تم إنشاء آخر موضوع<br>خلال 14 يومًا؟}
    B2 -- نعم -- --> C1(حظر النشر + عرض خطأ،<br>عرض فترة الانتظار،<br>رابط للقواعد)
    C1 -- --> E1(حفظ المسودة +<br>تعطيل زر الإرسال) ---> End(نهاية)
    B2 -- لا -- --> D1(السماح بالنشر)

    D1 -- --> End(نهاية)
    Z1 -- --> End(نهاية)
وحاولت أيضًا إنشاء مواصفات بسيطة للمساعدة في التوضيح
```mermaid
flowchart TB
    A0(يحاول المستخدم إنشاء موضوع جديد في الفئة أ أو ب) -- --> A1{هل المستخدم في<br>مجموعة معفاة--مسؤول، مشرف، TL3، TL4، مشتركين؟}
    A1 -- لا -- --> B1(تحقق من آخر موضوع للمستخدم في الفئات أ، ب، أو ج،<br>بما في ذلك السجلات المخفية أو المحذوفة)
    A1 -- نعم -- --> Z1(السماح بالنشر)

    B1 -- --> B2{هل تم إنشاء آخر موضوع<br>خلال 14 يومًا؟}
    B2 -- نعم -- --> C1(حظر النشر + عرض خطأ،<br>عرض فترة الانتظار،<br>رابط للقواعد)
    C1 -- --> E1(حفظ المسودة +<br>تعطيل زر الإرسال) ---> End(نهاية)
    B2 -- لا -- --> D1(السماح بالنشر)

    D1 -- --> End(نهاية)
    Z1 -- --> End(نهاية)

شرح المخطط الانسيابي

  1. A0: يبدأ المستخدم بإنشاء موضوع جديد في الفئة أ أو ب.

  2. A1: يتحقق النظام مما إذا كان المستخدم ينتمي إلى أي مجموعة معفاة:

    • المسؤولون
    • المشرفون
    • مستوى الثقة 3 (TL3)
    • مستوى الثقة 4 (TL4)
    • مجموعة “المشتركين” المخصصة
    • إذا كانت الإجابة نعم، يتم تخطي فحص فترة الانتظار والسماح بالنشر فورًا (Z1).
    • إذا كانت الإجابة لا، انتقل إلى B1.
  3. B1: يسترجع النظام آخر موضوع تم إنشاؤه بواسطة المستخدم في الفئات أ، ب، أو ج. يجب أن يشمل هذا البحث:

    • المواضيع المحذوفة بشكل ناعم (لم يتم إزالتها نهائيًا من قاعدة البيانات).
    • المواضيع المنقولة إلى فئات مخفية أو خاصة بالامتثال (مثل الفئة ج).
  4. B2: يتحقق النظام مما إذا كان تاريخ إنشاء آخر موضوع هو خلال الأيام الـ 14 الماضية.

    • نعم → انتقل إلى C1 (يتم حظر النشر).
    • لا → انتقل إلى D1 (السماح بالنشر).
  5. C1: يعرض النظام رسالة خطأ تخبر المستخدم بأنه لا يزال تحت فترة الانتظار. يجب أن تتضمن الرسالة:

    • بيان مبسط بأنه لا يمكنه النشر بعد.
    • الوقت المتبقي بالأيام والساعات (لا دقائق).
    • رابط لصفحة قواعد المجتمع (مقدم أدناه).
  6. E1: بعد عرض الخطأ، يتم حفظ محتوى المستخدم تلقائيًا كمسودة، ويتم تعطيل زر “إرسال” أو “إنشاء موضوع”.

  7. D1: إذا مرت أكثر من 14 يومًا منذ آخر موضوع للمستخدم، يسمح النظام بنشر الموضوع الجديد.

  8. Z1: المستخدم في مجموعة معفاة، لذا يمكنه النشر دون قيود.

2. المواصفات التفصيلية

2.1 المجموعات المقيدة مقابل المجموعات المعفاة

  • المجموعات المقيدة:
    • أي مستخدمين ليسوا ضمن المجموعات المعفاة التالية (عادةً TL0، TL1، TL2).
  • المجموعات المعفاة:
    1. المسؤولون
    2. المشرفون
    3. مستوى الثقة 3 (TL3)
    4. مستوى الثقة 4 (TL4)
    5. المشتركون (مجموعة مخصصة)

تتجاوز هذه المجموعات المعفاة فحص الـ 14 يومًا تمامًا.

2.2 الفئات ذات الصلة

  • محاولة إنشاء موضوع جديد:
    • يتم تشغيله عندما يحاول مستخدم (في مجموعة مقيدة) إنشاء موضوع جديد في الفئة أ أو ب.
  • التحقق من آخر موضوع:
    • يتحقق النظام من آخر موضوع تم إنشاؤه بواسطة المستخدم في الفئات أ، ب، أو ج (حيث ج هي فئة “مخفية” أو “خاصة بالامتثال”).

ملاحظة: يتم تضمين الفئة ج لالتقاط المواقف التي يتم فيها نقل موضوع المستخدم للحذف/الإخفاء/الامتثال. إذا أنشأ المستخدم موضوعًا في الفئة ج خلال الـ 14 يومًا الماضية، فإنه يُحتسب أيضًا ضمن فترة الانتظار.

2.3 منطق فترة الانتظار لمدة 14 يومًا

  • إذا تم إنشاء أحدث موضوع للمستخدم (في أ/ب/ج) خلال 14 يومًا، فاحظر إنشاء موضوع جديد في أ أو ب.
  • إذا مرت أكثر من 14 يومًا، فاسمَح به.

حساب الوقت

  • اعرض الوقت المتبقي بالأيام والساعات (على سبيل المثال، “متبقي 3 أيام و 12 ساعة”).
  • لا حاجة لعرض الدقائق أو الثواني.

2.4 الحظر وحفظ المسودة

  • سلوك الحظر:
    • عندما يتم حظر المستخدم، اعرض رسالة خطأ (C1).
    • يقوم النظام بحفظ محتوى المستخدم تلقائيًا كمسودة.
    • يصبح زر “إرسال” معطلاً حتى لا يتمكن المستخدم من المتابعة.
  • نموذج رسالة الخطأ (مبسط):

عذرًا، لا يمكنك إنشاء موضوع جديد في هذه الفئة بعد.
تم نشر آخر موضوع لك قبل أقل من 14 يومًا،
ويتبقى لديك {X أيام و Y ساعات} قبل أن تتمكن من النشر مرة أخرى.
لمزيد من التفاصيل، راجع قواعد مجتمعنا:
https://community.lezismore.org/t/topic/26/2

2.5 المرونة المستقبلية

  1. فئات إضافية:
    • حالياً تم تكوين أ، ب، وج فقط.
    • إذا احتجت إلى إضافة أو إزالة فئات من فترة الانتظار هذه في المستقبل، فتأكد من أن النظام أو المكون الإضافي يمكن توسيعه دون تغييرات كبيرة في الكود.
  2. فترات زمنية مختلفة:
    • يمكن أن تكون فترة الـ 14 يومًا قابلة للتكوين في إعدادات المكون الإضافي (في حال أردت 7 أيام، 30 يومًا، إلخ).
  3. تعيينات المجموعات الديناميكية:
    • يجب دعم مجموعات معفاة إضافية أو أقل (على سبيل المثال، إذا أضفت “المشتركين” أو أزلتها).

3. الملخص

  1. تخضع المجموعات المقيدة (TL0، TL1، TL2، أو أي مستخدم ليس في مجموعة معفاة) لفترة انتظار مدتها 14 يومًا قبل إنشاء موضوع آخر في الفئتين أ أو ب.
  2. يمكن للمجموعات المعفاة (المسؤول، المشرف، TL3، TL4، “المشتركون”) النشر دون قيود.
  3. يتحقق النظام من إنشاء آخر موضوع في الفئات أ، ب، أو ج (بما في ذلك المحذوف ناعمًا أو المخفي). إذا تم إنشاؤه خلال 14 يومًا، يتم حظر الموضوع الجديد.
  4. رسالة الخطأ: تعرض الوقت المتبقي بالأيام/الساعات وتربط بقواعد المجتمع على:
  5. المسودة: عند الحظر، يتم حفظ منشور المستخدم كمسودة، ويتم تعطيل زر الإرسال.
  6. يمكن توسيع هذه المواصفات لتشمل فئات إضافية أو أطر زمنية مختلفة في المستقبل.

سأكون ممتنًا لأي اقتراحات!

إعجاب واحد (1)

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

3 إعجابات

أوه، يمكنني الآن فهم حلك. :folded_hands: بينما قد يبدو هذا النهج مباشرًا، إلا أنني قلق بشأن ما يلي:

  1. حقوق القراءة مقابل النشر

    • حاليًا، يمكن للمستخدمين في المستوى 1 (أو أعلى) القراءة و النشر في الفئتين أ و ب.
    • إذا أزلنا المستخدم من المستوى 1 كلما انتهك قاعدة الـ 14 يومًا، فسيخسر حق القراءة أيضًا. لكننا نريد فقط منعه من النشر، وليس من القراءة.
  2. الحاجة إلى تقسيم المجموعات

    • لحل سيناريو “القراءة ولكن لا يمكن النشر”، سيتعين علينا إنشاء مجموعات فرعية متعددة:
    • المستوى 1 محدود - يمكنه القراءة والرد، ولكن لا يمكنه إنشاء مواضيع في أ أو ب.
    • المستوى 1 كامل - يمكنه القراءة والرد وإنشاء مواضيع.
    • إذا انتهك المستخدم قاعدة الـ 14 يومًا، فسننقله من المستوى 1 كامل إلى المستوى 1 محدود. يبدو هذا أكثر تعقيدًا.
  3. تعقيد الأتمتة

    • حتى مع وجود مجموعات منفصلة، سيتعين علينا إعادة المستخدم تلقائيًا إلى المجموعة “الكاملة” بمجرد انتهاء فترة الانتظار الخاصة به.
    • هذا يعني أنه يجب علينا تنفيذ منطق (مثل مهمة مجدولة أو كود مخصص) يحسب متى تنتهي فترة الـ 14 يومًا ثم يعيد تعيين المستخدم من المستوى 1 المحدود إلى المستوى 1 الكامل.
    • بصفتي شخصًا غير مبرمج، لا أشعر بالثقة في التعامل مع مثل هذه الأتمتة المعقدة بنفسي.

بمعنى آخر، بينما قد يتجنب إزالة المستخدمين من مجموعات معينة تعديل منطق النشر مباشرة، إلا أنه ينشئ مجموعات إضافية وقواعد معقدة. نريد فقط تقييد النشر لمدة 14 يومًا، وليس حق القراءة أو الامتيازات الأخرى.

شكرًا جزيلاً على أي اقتراحات أو أفكار. لقد حاولت دمج الأشياء عبر واجهات برمجة تطبيقات Discourse و webhooks في n8n، ولكن نظرًا لخلفيتي المحدودة في البرمجة، كان الأمر صعبًا للغاية بالنسبة لي.