نحن بحاجة حقًا إلى إنشاء موضوع جديد لكل حدث، بدلاً من أن يتحكم موضوع واحد في مجموعة من الأحداث الظاهرة في التقويم.
في الوقت الحالي، البديل الوحيد العملي هو إنشاء مجموعة من المواضيع الجديدة يدويًا. وهذا بالطبع يملأ شريط “الأحدث” بطريقة مزعجة للغاية (وهو ما يحتاج إلى معالجة بطريقة ما)، بالإضافة إلى ضرورة الحرص على عدم الإكثار من التنبيهات. أعتقد أن هذا يسلط الضوء على بعض التحديات في إضفاء الحياة على هذه الميزة.
العودة إلى هذا الموضوع بعد استخدام الإضافة المُحدّثة خلال الأشهر القليلة الماضية؛ إنها تعمل بشكل جيد للغاية الآن بعد أن أصبح لدينا المزيد من خيارات التكرار - خاصةً “اليوم X من الشهر”، والقدرة على الرد على الدعوة (RSVP) إما للحدث نفسه أو للسلسلة بأكملها.
ومع ذلك، لا يزال هناك مشكلة رئيسية قائمة: أرشفة محتوى آخر حدث.
حالة الاستخدام هي حدث متكرر يرتبط به عدد لا بأس به من المنشورات / النقاشات. وقد يشمل ذلك الملفات المرفقة والصور. أوضح مثال على ذلك هو اجتماع عمل دوري.
في الوقت الحالي، يجب ترتيب هذا الفوضى الناتجة يدويًا بطريقة أو بأخرى، لأن ما يفعله التكرار هو ببساطة تغيير تاريخ الحدث ومسح الردود على الدعوات (RSVP). الخيارات اليدوية هي:
إيقاف التكرار قبل / أثناء الحدث ونشر حدث جديد للشهر القادم
نقل المنشورات ذات الصلة إلى منشور أرشيف مخصص
حذف المنشورات تلقائيًا من منشور الحدث (على الرغم من أن توقيت ذلك غير مريح)
نسيان فكرة التكرار تمامًا لهذا النوع من الأحداث وإجراء كل شيء يدويًا
لسوء الحظ، لا يبدو أي من هذه الخيارات جيدًا.
ما أود رؤيته بدلاً من ذلك
أود أن يحافظ التكرار على موضوع الحدث الحالي كما هو، ولكن بمجرد اكتماله، تقوم الإضافة بإنشاء موضوع جديد للحدث التالي.
سيحافظ ذلك على سلاسة التجربة الجميلة، وسيضمن تلقائيًا الاحتفاظ بأرشيف مناسب للحدث السابق - بالإضافة إلى توفير موضوع “نظيف” للحدث الجديد.
الثمن الذي يجب دفعه (بجانب زيادة التعقيد) هو أن الحدث النشط سيكون له عنوان URL جديد. يمكنني تصور أن هذا قد يمثل مشكلة في بعض الحالات.
مرحبًا، هذا يعني أنه سيتعين عليك انتظار إغلاق الحدث الحالي ضمن سلسلة الأحداث المتكررة قبل أن تتمكن من الاشتراك في الحدث التالي؟
معظم مكوّنات الإضافات الخاصة بالأحداث التي عملتُ عليها في Joomla تنشئ سلسلة الأحداث مباشرةً، تمامًا كما ستنشئ فكرتك هنا مواضيع/روابط فردية لكل حدث على حدة، وأعتقد أن هذا هو النموذج الصحيح.
كما سيكون من العملي أيضًا توفير خيار لمنع الاشتراك قبل x أيام من الأحداث المتكررة.
أما بالنسبة لجزء الأرشفة، أليس الأحداث مقيمةً في الغالب في فئة فرعية خاصة بها أو قابلةً للوسوم بشكل كافٍ للحفاظ على تجميعها معًا وتطبيق إجراء تلقائي عليها؟
في تجربتي مع الأحداث، يُستخدم تأكيد الحضور للسلسلة بأكملها أقل من إمكانية الاشتراك في حدث محدد لاحقًا في السلسلة؛ ومع ذلك، فإن كلا الخيارين مهمان.
نعم، لكنني لا أرى في تثبيتتي أي سير عمل (workflow) يقوم بذلك.
ربما يكون هذا بحد ذاته طلب ميزة أخرى ومثيرًا للاهتمام خارج نطاق موضوع الأحداث، وقد/يجب أن أنشئ موضوعًا آخر لهذا الغرض.
سنحتاج إلى إجراء أرشفة تلقائي يُفعَّل عند استيفاء شروط معينة؛ هنا سيكون الشرط أن يكون “تاريخ الحدث أو تاريخ الانتهاء إذا كان موجودًا” في الماضي، أو أن يكون الموضوع مغلقًا منذ x أيام، مع إمكانية تحديد تأخير اختياري قبل حدوث الإجراء بحيث يمكن أن يبقى موضوع الحدث ظاهرًا حتى يتمكن الأشخاص من التعليق بعد الحدث لبضعة أيام.
تم الآن دمج مُفعِّل Event ended (انتهاء الحدث) للعمليات المؤتمتة (Workflows):
بالإضافة إلى ذلك، تملك العمليات المؤتمتة بالفعل إجراء Topic (موضوع) يمكنه Get (جلب) موضوع موجود وCreate (إنشاء) موضوع جديد، كما يوجد عقدة Wait (انتظار). لذا، قد يكون من الممكن بالفعل تركيب جزء كبير من آلية الترحيل المقترحة كعملية مؤتمتة بدلاً من الحاجة إلى ميزة أرشفة مخصصة لحدث معين.
قد يُنشئ موضوعاً جديداً باستخدام بيانات عنوان/نص/فئة الموضوع القديم، مع إبقاء الموضوع المكتمل سليماً كسجل أرشيفي.
ما لا يزال بحاجة إلى التحقق منه هو تحديد الأجزاء بالضبط من الموضوع القديم التي يجب نسخها تلقائياً - على سبيل المثال، الوسوم، الملفات المرفوعة، حالة تكرار الحدث، وما إذا كان يجب نقل الردود أم تركها كما هي.
لدي أيضاً طلب سحب (PR) مفتوح يُدخل إجراء Event (حدث) إلى العمليات المؤتمتة:
يضيف طلب السحب الأساسي إجراء Close event (إغلاق الحدث) وOpen event (فتح الحدث)، ولدي متابعة مكدسة تضيف Set attendance (تحديد الحضور):
تم هيكلة الإجراء بحيث يمكن إضافة عمليات محددة للحدث الأخرى كمتابعات منفصلة حيث يكون ذلك مناسباً.
جهود رائعة، شكرًا. يمكن أن تكون شروط الإغلاق مفيدة، لكنها قد لا تكون قابلة للتطبيق بالكامل على الوضع الأصلي.
يمكن أن يكبر تصنيف الأحداث بشكل كبير، خاصةً مع الأحداث المتكررة، ومن المنطقي توفير طريقة لأرشفة/نقل تلقائي أي موضوع حدث أُغلق منذ x أيام إلى تصنيف موضوعات سابقة أو أرشفته.
لكن مسألة الأرشفة هذه تعتمد على قرار جعل الأحداث المتكررة مواضيع فردية مرتبطة بموضوع الحدث الرئيسي.
لقد فتحت طلب سحب (PR) لتنفيذ هذا كوضع تكرار اختياري للحدث:
يضيف هذا الإعداد discourse_post_event_recurring_topic_mode للموقع مع خيارين:
reuse_topic — السلوك الحالي والافتراضي
create_next_topic — الحفاظ على موضوع الحدّة المكتملة وإنشاء موضوع جديد للحدّة التالية
مع create_next_topic، عندما تنتهي حدّة ما، يُحتفظ بالموضوع المكتمل مع تثبيت الحدث على تلك الحدّة وإزالة التكرار. ثم يُنشأ موضوع خلفة للحدّة التالية، مع الحفاظ على العنوان الأصلي/المحتوى، والتصنيف، والوسوم، والمؤلف، بينما يتم تحديث تواريخ الحدث.
تغطي الاختبارات الآلية أيضًا دلالات انتقال الحضور (RSVP): يتم نقل حضور going المتكرر إلى الموضوع الخلفة، بينما يبقى الحضور لمرة واحدة مع الحدّة المكتملة.
الانتقال معاملة (transactional) أيضًا، لذا إذا فشل إنشاء الموضوع الخلفة، تبقى الحدّة معلقة ويمكن إعادة المحاولة بدلاً من تركها مكتملة جزئيًا.
هذا التنفيذ محدد لنموذج “إنشاء الموضوع التالي عند انتهاء الحدّة الحالية”. إنه لا يولّد بعد موضوعات فردية لجميع الحدّات المستقبلية مسبقًا، وهو النموذج البديل الذي ذكره @opcourdis أعلاه.
يبقى السلوك الحالي هو الافتراضي، لذا هذا اختيار اختياري للمواقع التي تريد أن يعمل موضوع الحدث المكتمل كالأرشيف.
شكرًا لك، هذا النموذج يعمل بشكل رائع بالفعل للمنظمين الذين يمكنهم الآن أن يعرفوا بثقة أنهم لن يضطروا إلى إعادة إنشاء الحدث في كل مرة، كما أنه يمنحهم الأمان بأن الناس لن يبدؤوا بالاشتراك مسبقًا، لأن المنظمين يمكنهم دائمًا إلغاء الحدث لأسباب معينة.
النموذج الذي اقترحته لإنشاء الأحداث مسبقًا يعمل أيضًا في العديد من الحالات وسيكمل نموذج خلفة الأحداث الخاص بك.
1° هل سيظل الأشخاص الذين يشتركون في الحدث الجديد على علم بأن الموضوع/الحدث جزء من سلسلة أحداث متكررة، كما هو الحال مع الحدث/الموضوع الأصلي؟
2° هل دعوة الضيوف الأصليين تلقائيًا إلى الحدث خيار اختياري (إلغاء الاشتراك أو الاشتراك)؟ أقول هذا لأن الحدث المستقبلي ليس بالضرورة حدثًا تريد دائمًا الترويج له للضيوف، خاصة أنك قد قمت بالفعل بالترويج للحدث وسلسلته لهم مرة واحدة من خلال الحدث الأول.
نعم، بمعنى أن الحدث التالي يحتفظ بإعدادات التكرار. على سبيل المثال، في اختبار الدخان للواجهة الرسومية، كانت النسخة الأصلية تعرض كل يوم خميس، وبعد التناوب، عرض الموضوع التالي أيضًا كل يوم خميس مع تقدم التاريخ إلى الأسبوع التالي.
ما لا يضيفه هذا طلب الجلب (PR) هو علاقة سلسلة عبر المواضيع تربط بين الموضوع المكتمل وخليفته. يصبح الموضوع المكتمل نسخة مؤرشفة لمرة واحدة، بينما يحمل الخليفة التكرار إلى الأمام. يمكن أن تكون علاقة سلسلة/أب صريحة بين هذه المواضيع تحسينًا منفصلًا إذا ثبتت فائدتها.
لا ينقل كل ضيف/حاضر تلقائيًا إلى الحدث الجديد.
يرث الخليفة فقط الأشخاص الذين كانوا حاضرين مع تمكين تأكيد الحضور للتكرار/السلسلة. الشخص الذي أكد حضوره حاضر للنسخة الفردية فقط يبقى على الموضوع المكتمل ولا يُضاف إلى الخليفة.
لذلك، حاليًا، يعمل خيار تأكيد الحضور للسلسلة كخيار دخول (Opt-in) للانتقال إلى الأحداث الخليفة المستقبلية، بدلاً من وجود إعداد موقع آخر يتحكم في ذلك.
من الرائع أن يُذكر التكرار، فهذا كافٍ، كما أن الفئة أو الفئة الفرعية تنقل أيضًا أن الحدث جزء من سلسلة. بمجرد التفكير في الأمر، أدركت كم يمكن أن تكبر فئة فرعية للأحداث عندما تكون هناك أحداث متكررة، ومن هنا جاء النقاش حول سير عمل الأرشفة التلقائية/الأتمتة في وقت سابق من هذا الموضوع.