# إنشاء مواضيع أحداث فردية للأحداث المتكررة

**URL:** <https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600>\
**Category:** Feature\
**Tags:** events\
**Created:** [18 يونيو 2025، 12:33ص UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600 "2025-06-18T00:33:54Z")\
**Posts on this page:** 1\
**Showing post:** 25

<div class="post-metadata">

**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\
**Post date:** [28 سبتمبر 2026، 8:19م UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/25 "2026-09-28T20:19:38Z")

</div>

> [@nathank](#):
>
> هل هناك أي تقدم في هذا الأمر؟ بينما أحب ميزة الأحداث المتكررة، أشعر بمعاناة إدارة أرشفة الأحداث يدويًا بشكل متكرر!

لم يظهر أي تقدم إضافي واضح على طلب الدمج (PR) حتى الآن:

> <https://github.com/discourse/discourse/pull/43187>
>
> \## Summary
> 
> Adds an opt-in mode for recurring Events where each completed occu…rrence is preserved in its own Topic and the next occurrence is created in a successor Topic.
> 
> The new \`discourse\_post\_event\_recurring\_topic\_mode\` enum site setting has two values:
> 
> \- \`reuse\_topic\` — existing behavior and the default
> \- \`create\_next\_topic\` — archive the completed occurrence Topic and create a successor Topic for the next occurrence
> 
> \## Details
> 
> When \`create\_next\_topic\` is enabled, the scheduled event-date monitor:
> 
> \- preserves the completed Topic by converting its Event to a one-off occurrence
> \- appends the occurrence date to the archived Topic title, handling title-length and duplicate-title constraints
> \- creates the successor Topic from the original post content while advancing only the Event start/end dates
> \- preserves category, tags, original author and recurring Event metadata
> \- carries forward only recurring \`going\` invitees; one-off attendance remains on the completed occurrence
> \- performs the rollover transactionally so a failed successor creation leaves the occurrence pending for retry
> \- still emits the event-ended workflow trigger with the completed occurrence's recurring-series metadata
> 
> If the recurrence has no next occurrence, the completed Topic is preserved as a one-off Event and no successor Topic is created.
> 
> The existing \`reuse\_topic\` path is unchanged.
> 
> \## UI smoke test
> 
> With \`discourse\_post\_event\_recurring\_topic\_mode\` set to \`create\_next\_topic\`:
> 
> \*\*Site setting\*\*
> 
> \<img width="678" height="142" alt="01-admin-setting-create-next-topic" src="https://github.com/user-attachments/assets/78dc6698-6886-4c10-81d4-22d991f0f452" /\>
> 
> \*\*Before rollover — recurring occurrence on September 3\*\*
> 
> \<img width="1512" height="958" alt="02-before-rollover-sep-3-every-thursday" src="https://github.com/user-attachments/assets/3150b843-1264-4990-8dd8-2e931e28b9dc" /\>
> 
> \*\*Completed occurrence preserved in the dated Topic\*\*
> 
> \<img width="2048" height="1076" alt="03-archived-topic-2026-09-03" src="https://github.com/user-attachments/assets/d6d28341-f684-4ba8-9b54-2fec0c537bb7" /\>
> 
> \*\*Successor Topic created for the next weekly occurrence\*\*
> 
> \<img width="2048" height="1073" alt="04-successor-topic-sep-10-every-thursday" src="https://github.com/user-attachments/assets/0ff611b4-f316-4130-bb75-7948d36e61e9" /\>
> 
> \## Tests
> 
> Focused specs after rebasing onto current \`main\`:
> 
> \> 22 examples, 0 failures
> 
> Coverage includes the existing reuse-topic behavior, normal successor rollover, final recurrence, all-day timezone handling, fenced-code Event markup, title collisions/truncation, restricted original authors, transactional retry behavior, recurring RSVP inheritance, and workflow event-ended payloads.
> 
> The UI and scheduled-job smoke tests confirmed that the completed Topic was preserved with a dated title and that a successor Topic was created for the following weekly occurrence, including through the normal supervised Sidekiq scheduler.

ما زلت أأمل أن تبقى هذه الميزة ضمن إضافة الأحداث المدمجة (bundled Events plugin) بدلاً من الحاجة إلى صيانتها بشكل منفصل.

> [@Ethsim2](#):
>
> كانت الخطاف (hook) الذي أضفته إلى مثيلي المستضاف ذاتيًا جهدًا كبيرًا مقابل تحسين لم يدم طويلًا في نواة سريعة التطور.

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

في مثيلي المستضاف ذاتيًا، أستخدم بالفعل خطاف `after_code` لترحيل (backport) صغير لطلب دمج من المنبع. يتحقق الخطاف أولًا من علامات تُظهر أن الميزة قد وصلت إلى المنبع. إذا لم تصل، فإنه يقوم بتنزيل التصحيح (patch) لالتزام (commit) معروف، ثم يشغّل `git apply --check`، وبعد ذلك فقط يطبقه باستخدام `git apply`.

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

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

السبب هو أن #43187 يعدّل بالفعل مسار التمرير (rollover) الخادمي المجدول الخاص بإضافة الأحداث المدمجة نفسها. يمكن لخطاف `after_code` تطبيق نفس تصحيح المنبع تقريبًا مباشرةً أثناء إعادة البناء. أما الإضافة المنفصلة فستحتاج إلى إعادة إنشاء ذلك التكامل عبر نقطة توسيع (extension point)، أو بطريقة أخرى إضافة/تجاوز سلوك `MonitorEventDates` الداخلي، مما يضيف طبقة أخرى وقد يكون هشًا بنفس القدر.

السلبي في نهج `after_code` هو أنه لا يزال مرتبطًا بالشكل الدقيق لرمز المنبع. لأن سلوك موضوع الخلف (successor-topic) يمس `MonitorEventDates`، يمكن الاستمرار في استخدام تصحيح الالتزام الثابت نفسه طالما نجح `git apply --check`. إذا قام المنبع بتغيير ذلك الرمز بما يكفي لإيقاف مطابقة سياق التصحيح، فسيحتاج إلى إعادة الأساس (rebase) أو تكييف التغيير على الفرع الرئيسي الحالي (main)، وإنشاء التزام جديد، وتحديث الخطاف لاستخدام معرف (SHA) ذلك الالتزام الجديد.

لذا تبقى تفضيلي:

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

حتى ذلك الحين، سيكون تصحيح `after_code` حلًا عمليًا مؤقتًا للمضيفين ذاتيًا، لكنني لن أعتبره آلية التوزيع المثالية على المدى الطويل.

---

_[View the full topic](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600)._