# 为重复事件创建独立的话题
**URL:** https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600
**Category:** Feature
**Tags:** events
**Created:** [2025 年6 月 18 日 00:33 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600 "2025-06-18T00:33:54Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@opcourdis](https://meta.discourse.org/u/opcourdis)
#### Post date: [2025 年6 月 18 日 00:33 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/1 "2025-06-18T00:33:54Z")
您好，
周期性事件是单独的事件，但是当您创建一个周期性事件时，它不会创建单独的主题。
因此，如果您点击其中一个周期性事件以参与其中，那么您的参与将显示在所有事件中。
创建周期性事件时，难道不应该创建与第一个事件具有相同基础的单独事件/主题吗？
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2025 年6 月 18 日 04:34 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/2 "2025-06-18T04:34:06Z")
这确实是一个功能请求。我理解，如果能在一个序列中选择某个特定事件就太好了。
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [2026 年4 月 8 日 05:22 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/3 "2026-04-08T05:22:55Z")
> [@j.jaffeux](#):
>
> 是的，我们会谈到这一点，这需要多个步骤才能达成，我们在过去几周已经朝着这个方向迈出了很多步伐。
在这方面有什么进展吗？
我们确实需要为每个活动创建一个新的主题，而不是让一个单一的活动主题控制日历中可见的多个活动。
目前，唯一可行的变通方法是手动创建一批新主题。当然，这会以一种非常烦人的方式填满“最新动态”信息流（需要以某种方式缓解），同时也要求你小心不要过度通知。我想这凸显了在实现这一功能时面临的一些挑战。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026 年4 月 11 日 09:08 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/4 "2026-04-11T09:08:37Z")
> [@nathank](#):
>
> 一个单一事件主题控制日历中可见的大量事件。
如果主题中的_次要_事件具有不同的外观（例如通过 `eventBorderColor` 和 `eventBackgroundColor` 设置轮廓），是否可以接受？
> **[Event Display - Docs
| FullCalendar](https://fullcalendar.io/docs/event-display)**
>
> How to control the appearance of events on your calendar.
您可以通过组合以下属性来模拟分层效果：
| 属性 | 主要（已确认） | 暂定 / 次要 |
| --- | --- | --- |
| eventBackgroundColor | 实心填充 | 不同颜色 / 浅色 |
| eventBorderColor | 与填充色相同 | 强烈对比 |
| 边框样式 | 实线 | 虚线 |
| 不透明度 | 1 | 1 |
这样可以在无需实际堆叠的情况下创建视觉层次结构。
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [2026 年4 月 12 日 22:36 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/5 "2026-04-12T22:36:57Z")
这个主意很可爱，但我觉得还远远不够——系列中的每个活动都需要独立的 RSVP、补充信息和讨论。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026 年4 月 13 日 06:31 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/6 "2026-04-13T06:31:16Z")
RSVP 将被 `poll` 取代，因此主题中的所有活动都将是“独立”的。这些活动都围绕同一件事：从多个时间中锁定一个具体时间。
这既不是一个系列，也无法在 Outlook 中实现。
这正是让像我就读的这样的机构，从防御性地使用虚假的 Outlook 系列转向 Discourse 的“独特秘诀”。
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [2026 年7 月 14 日 00:24 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/7 "2026-07-14T00:24:10Z")
在使用了更新后的插件几个月后，我再次回到这里；现在有了更多的重复选项，尤其是每月的第X天和为事件或系列进行RSVP的能力，它运行得相当不错。
然而，一个关键问题仍然存在： **归档最后一个事件的内容。**
使用场景是一个有很多帖子/讨论的重复事件。这可能包括附件文件和图片。最明显的例子是定期工作会议。
目前，这种混乱需要以某种方式手动整理，因为重复所做的只是更改事件的日期并清除RSVP。手动选项有：
1. 在事件之前/期间关闭重复并为下个月发布新事件
2. 将相关帖子移动到专用的归档帖子
3. 在事件帖子上自动删除帖子（尽管这个时机很尴尬）
4. 忘记这些类型事件的整个重复功能，并完全手动操作
不幸的是，这些都不是很好的选择。
### 我希望看到的替代方案
我希望重复功能能够保持当前事件主题不变，但一旦完成，插件将为下一个事件创建一个 **新** 的主题。
这将保持流畅的体验，并自动确保保留过去事件的适当归档——同时也为新事件提供一个“干净”的主题。
付出的代价（除了增加的复杂性）是活跃事件将有一个新的URL。我可以看到这在某些情况下可能会成为一个问题。
---
### Author:  [@opcourdis](https://meta.discourse.org/u/opcourdis)
#### Post date: [2026 年8 月 23 日 17:47 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/8 "2026-08-23T17:47:35Z")
> [@nathank](#):
>
> 我希望重复功能能够保持当前事件主题（Event topic）完整不变，但一旦该事件完成，插件会为下一个事件创建一个 **新的** 主题。
你好，这意味着你需要等待当前重复事件系列中的事件关闭后，才能订阅下一个事件吗？
在我经手过的多数 Joomla 事件插件中，它们会直接创建事件系列，而像你这里提出的想法那样，为每个事件创建独立的主题/URL，我认为这是正确的模式。
提供一个选项，允许在重复事件开始前 x 天内禁止订阅，也会非常实用。
至于归档部分，事件通常不是都位于自己的子类别中，或者已经足够可以通过标签（tag）来归类，从而将它们保持在一起并对其进行自动化操作吗？
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [2026 年8 月 31 日 09:26 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/9 "2026-08-31T09:26:01Z")
> [@opcourdis](#):
>
> 你好，这意味着在你能订阅下一个活动之前，必须先等待当前重复活动系列中的活动结束，对吗？
是的，但这与目前的情况并没有区别，因为在目前你既可以回复当前活动，也可以回复整个系列。
> [@opcourdis](#):
>
> 至于归档部分，活动不是大多都位于各自的子类别中，或者可以通过标签将它们归类在一起，从而对它们执行自动化操作吗？
你是指克隆活动并移动回复的操作，还是类似的功能？也许“工作流”（Workflows）可以做到这一点；我一直想研究一下这个功能。
---
### Author:  [@opcourdis](https://meta.discourse.org/u/opcourdis)
#### Post date: [2026 年9 月 3 日 11:52 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/10 "2026-09-03T11:52:14Z")
> [@nathank](#):
>
> 是的，但这与目前的情况并没有区别，因为你现在既可以回复当前活动，也可以回复整个系列活动。
根据我对活动的经验，回复整个系列的情况使用得较少，而能够稍后订阅系列中某个具体活动则更常用；不过这两种选项都很重要。
> [@nathank](#):
>
> 你是指克隆活动并移动回复的操作，还是类似的功能？也许“工作流”（Workflows）可以做到这一点；我一直打算研究一下这个功能。
是的，不过我在我的安装环境中没有看到任何执行此操作的工作流。
这本身可能是一个独立的功能请求，而且其意义超出了“活动”主题的范围，所以我可以/应该为此创建另一个主题。
我们需要一个在特定条件下触发的自动归档操作；在这里，条件应该是“活动日期或结束日期（如果存在）”已过去，或者主题已关闭 x 天。也许还可以设置一个可选择的延迟时间，以便在活动结束后几天内，活动主题仍然可见，供人们评论。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026 年9 月 3 日 12:02 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/11 "2026-09-03T12:02:15Z")
这里已经取得了一些进展。
`Event ended`（活动结束）工作流触发器现已合并：
[https://github.com/discourse/discourse/pull/42634](https://github.com/discourse/discourse/pull/42634)
此外，工作流（Workflows）中已经有一个 `Topic`（主题）操作，它可以 `Get`（获取）现有主题并 `Create`（创建）新主题，并且还有一个 `Wait`（等待）节点。因此，提议的许多轮换（rollover）功能可能已经可以作为工作流进行组合，而不需要专门针对特定事件的归档功能。
类似于以下流程：
`Event ended` → `Wait` → `Topic / Get` → `Topic / Create`
这可能利用旧主题的标题/正文/分类数据创建一个后续主题，同时保留已完成的主题作为归档。
仍需确认的是，旧主题中具体哪些部分应该自动复制——例如标签、上传文件、活动重复状态，以及回复是应该移动还是简单地留在原地。
我还提交了一个引入 `Event`（活动）操作到工作流的未合并 PR：
[https://github.com/discourse/discourse/pull/42932](https://github.com/discourse/discourse/pull/42932)
基础 PR 添加了 `Close event`（关闭活动）和 `Open event`（打开活动），我还有一个堆叠的后续 PR 用于添加 `Set attendance`（设置出席状态）：
[https://github.com/discourse/discourse/pull/43028](https://github.com/discourse/discourse/pull/43028)
该操作的结构设计使得可以在有意义的情况下，通过单独的后续 PR 添加更多特定于活动的操作。
---
### Author:  [@opcourdis](https://meta.discourse.org/u/opcourdis)
#### Post date: [2026 年9 月 3 日 12:22 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/12 "2026-09-03T12:22:06Z")
感谢大家的努力，关闭条件可能很有帮助，但未必完全适用于最初的情况。
> [@nathank](#):
>
> 然而，一个关键问题仍然存在： **归档最后一个事件的内容。**
事件类别可能会变得很大，尤其是对于定期事件而言。因此，提供一种方式，将关闭超过 x 天的任何主题事件自动归档/移动到一个“过去事件”类别中，或者将它们归档，这是很有意义的。
**但这个问题取决于** 是否决定让定期事件成为链接到主事件主题的独立主题。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026 年9 月 3 日 17:37 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/13 "2026-09-03T17:37:54Z")
> [@nathank](#):
>
> 我希望重复事件（recurrence）能保持当前的 Event 主题（Topic）完整不变，但一旦该次事件完成，插件就会为下一次事件创建一个 **新的** 主题。
我已经提交了一个 PR，实现了一种可选的重复 Event 模式：
>
>
> \## 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\*\*
>
> \
>
> \*\*Before rollover — recurring occurrence on September 3\*\*
>
> \
>
> \*\*Completed occurrence preserved in the dated Topic\*\*
>
> \
>
> \*\*Successor Topic created for the next weekly occurrence\*\*
>
> \
>
> \## 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.
它添加了一个站点设置 `discourse_post_event_recurring_topic_mode`，包含两个选项：
- `reuse_topic` — 现有行为，也是默认选项
- `create_next_topic` — 保留已完成的单次事件主题，并为下一次事件创建新主题
在使用 `create_next_topic` 时，当某次事件结束时，已完成的主题将被保留，其 Event 将固定在该次已完成的事件上，并移除重复设置。随后会为下一次重复事件创建一个继任主题，保留原标题、正文、分类、标签和作者，同时更新 Event 的日期。
自动化测试还涵盖了 RSVP 的滚动语义：重复的 `going`（参加）状态会延续到继任主题中，而单次参加状态则保留在已完成的事件中。
该滚动过程也是事务性的，因此如果创建继任主题失败，当前事件将保持待定状态，可以重试，而不会处于半完成状态。
这具体实现了“当当前事件结束时创建下一个主题”的模型。它目前不会提前为所有未来的事件生成独立主题，这是 @opcourdis 上面提到的另一种模型。
现有行为仍然是默认选项，因此对于希望已完成的事件主题充当存档的站点，此功能是可选启用的。
---
### Author:  [@opcourdis](https://meta.discourse.org/u/opcourdis)
#### Post date: [2026 年9 月 3 日 19:06 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/14 "2026-09-03T19:06:02Z")
> [@Ethsim2](#):
>
> 它目前还不会提前为所有未来发生的活动生成单独的 Topic，而这正是 @opcourdis 在上面提到的替代方案。
谢谢，这个模型对组织者来说已经非常实用了。现在他们可以确信，每次都不必重新创建活动，同时也提供了一种保障，即人们不会提前订阅，因为组织者总是可以出于某些特定原因取消活动。
我建议的“提前创建”模型在许多场景下也是可行的，并且可以作为你“活动继任者”模型的补充。
顺便说一下，关于[活动继任者模式 PR](https://github.com/discourse/discourse/pull/43187)：
1° 订阅了新活动的人，是否仍然能得知该 Topic/活动属于一个定期活动系列，就像原始活动/Topic 那样？
2° 你自动邀请原始嘉宾参加活动的功能，是可选退出（opt-out）还是可选加入（opt-in）的？我之所以这么问，是因为未来的活动并不一定是你希望总是向嘉宾推广的活动，因为你已经通过第一个活动及其系列向他们推广过一次了。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026 年9 月 3 日 20:02 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/15 "2026-09-03T20:02:26Z")
> [@opcourdis](#):
>
> 订阅新事件的人是否仍然能知道该主题/事件是循环事件系列的一部分，就像原始事件/主题那样？
是的，因为后续事件会保留循环配置。例如，在 GUI 冒烟测试中，原始实例显示为“每周四”，而在轮换后，后续主题也显示为“每周四”，且日期已推进到下一周。
此 PR 没有添加将已完成的主题与其后续者关联起来的独立跨主题系列关系。已完成的主题将成为一次性归档实例，而后续者则继续承载循环设置。如果证明有用，可以在这些主题之间建立明确的系列/父级关系，作为单独的功能增强。
> [@opcourdis](#):
>
> 自动邀请原始客人参加事件是一个可选退出/加入（opt out/in）选项吗？
它不会自动将每位客人/参与者带入新事件。
后续者仅继承那些在启用循环/系列 RSVP 的情况下标记为“参加”的人员。仅对单个实例 RSVP“参加”的人将保留在已完成的主题中，而不会被添加到后续者中。
因此，目前选择 RSVP 到该系列实际上起到了加入未来后续事件的 opt-in 作用，而不是由另一个站点设置来控制此行为。
---
### Author:  [@opcourdis](https://meta.discourse.org/u/opcourdis)
#### Post date: [2026 年9 月 3 日 20:29 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/16 "2026-09-03T20:29:50Z")
1. 如果提到了重复性，那就足够了，而且类别或子类别也能传达出该活动属于系列的一部分。不过，一想到有重复性活动存在时，活动的子类别可能会变得多么庞大，我就意识到这确实是个问题，这也是之前在这个话题中讨论自动归档工作流/自动化的原因。
2. 谢谢你的澄清。
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [2026 年9 月 8 日 10:18 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/17 "2026-09-08T10:18:47Z")
哇！听起来非常棒——而且正是我们所需要的。
我很欣赏它似乎能很好地融入现有功能。
我们该如何有效地请求对你们的 PR 进行审查？
另外，是否有可能/方便将其打包为一个插件（以防他们目前还不想采用它）？
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026 年9 月 8 日 14:01 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/18 "2026-09-08T14:01:56Z")
谢谢——很高兴这符合你最初设想的用例。
关于审查，PR 已经开放，并已从本主题中链接过去。我认为没有单独的公开审查请求渠道可供我使用，所以最有帮助的做法可能是，让那些真正会使用这个功能的人在 PR 上添加一个表情反应或简短评论，以确认该用例。我不想反复单独去打扰各个工作人员。
它也可以被打包成一个独立的插件，尽管这不会完全简单。目前的实现完全位于捆绑的 #events 插件内部，但它既修改了现有的计划事件日期滚动逻辑，又添加了后继主题服务。因此，一个外部插件需要挂钩或覆盖 #events 中的这部分逻辑，这在面对上游变更时会更加脆弱。
所以，我的首选方案是先看看上游 PR 是否会被接受。如果它没有被接受，或者看起来在很长一段时间内都不会被合并，那么将其提取为一个独立的插件将是一个可行的备选方案。
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [2026 年9 月 10 日 03:31 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/19 "2026-09-10T03:31:35Z")
已经回应并评论了！不确定这能帮上多大忙，但我会尽力而为。
> [@Ethsim2](#):
>
> 所以我的建议是先看看上游的 PR 是否被接受。如果没被接受，或者看起来很长一段时间内都不会合并，那么将其提取为一个独立的插件将是一个可行的备选方案。
这完全说得通。不过，总是有个“B 计划”比较好！！
---
### Author:  [@lindsey](https://meta.discourse.org/u/lindsey)
#### Post date: [2026 年9 月 11 日 12:02 UTC](https://meta.discourse.org/t/create-individual-event-topics-for-recurring-events/370600/21 "2026-09-11T12:02:54Z")
@Ethsim2 我们会查看你的 PR 及其底层功能，并很快跟进下一步操作！