안녕하세요,
반복 이벤트는 개별 이벤트로 취급되지만, 하나를 생성할 때 개별 토론 주제가 생성되지 않습니다.
따라서 반복 이벤트 중 하나를 클릭하여 참여하면, 그 참여가 모든 이벤트에 표시됩니다.
반복 이벤트를 생성할 때 첫 번째 이벤트와 동일한 기반을 가진 개별 이벤트/주제가 생성되어야 하지 않나요?
3개의 좋아요
sam
6월 18, 2025, 4:34오전
2
This is very much a feature request. I hear you, would be nice if you could pick a particular event in a sequence.
3개의 좋아요
nathank
4월 8, 2026, 5:22오전
3
이 부분에 대해 어떤 진전이 있었나요?
캘린더에서 여러 이벤트를 제어하는 단일 이벤트 주제(Topic) 대신, 각 이벤트마다 새로운 주제가 생성되어야 합니다.
현재 유일한 현실적인 우회 방법은 수동으로 여러 새로운 주제를 만드는 것입니다. 이는 물론 최신 피드를 매우 귀찮을 정도로 가득 채우게 되며(어떤 식으로든 완화 조치가 필요합니다), 과도한 알림을 보내지 않도록 주의해야 한다는 점도 요구합니다. 이는 이 기능을 구현하는 데 있어 일부 어려움들을 드러내 주는 것 같습니다.
1개의 좋아요
Ethsim2
4월 11, 2026, 9:08오전
4
토픽의 보조 이벤트에 eventBorderColor와 eventBackgroundColor를 통해 윤곽선과 같은 다른 외관을 적용하는 것이 허용될까요?
다음 속성을 조합하여 레이어링을 시뮬레이션할 수 있습니다:
속성
주요 (확정됨)
잠정 / 보조
eventBackgroundColor
단색 (solid)
다름 / 밝음
eventBorderColor
채움색과 동일
강한 대비
경계 스타일
실선 (solid)
점선 (dashed)
투명도 (opacity)
1
1
이것은 실제 스택킹 없이 시각적 위계 구조를 만들어 줍니다.
nathank
4월 12, 2026, 10:36오후
5
귀여운 아이디어지만, 아직 충분하지는 않을 것 같아요. 시리즈의 각 이벤트에는 각각 별도의 RSVP, 추가 정보, 그리고 토론이 필요합니다.
Ethsim2
4월 13, 2026, 6:31오전
6
RSVP는 poll(투표)로 대체될 것이며, 이 토픽의 모든 이벤트는 standalone(독립형, 기본 스타일 및 스타일화된 보조 스타일)이 됩니다. 모든 이벤트는 동일한 주제, 즉 여러 시간 중 하나를 확정하는 복잡성에 관한 것입니다.
실제로는 시리즈라고 할 수도 없고, 아웃룩으로 구현할 수도 있는 것이 아닙니다.
이것이 바로 대학과 같은 기관이 방어적이고 허구적인 아웃룩 시리즈에서 벗어나 디스커스로 전환하게 만드는 특별한 비법입니다.
nathank
7월 14, 2026, 12:24오전
7
지난 몇 달간 개편된 플러그인을 사용해 본 뒤 다시 이 문제를 꺼냅니다. 이제 반복 옵션이 더 다양해져서 꽤 잘 작동하고 있어요 — 특히 매월 X번째 날 지정 기능과, 이벤트 또는 시리즈 전체에 대한 RSVP 기능이 특히 유용하죠.
하지만 여전히 핵심적인 문제가 남아 있습니다: 마지막 이벤트의 내용 아카이빙.
해당 사용 사례는 게시물이나 토론이 꽤 많이 달린 반복 이벤트입니다. 첨부 파일이나 이미지가 포함될 수도 있습니다. 가장 대표적인 예는 정기적인 업무 회의입니다.
현재로서는 이 결과로 생긴 어수선한 상태를 어쨌든 수동으로 정리해야 합니다. 반복 기능은 단순히 이벤트 날짜만 변경하고 RSVP만 초기화하기 때문입니다. 수동으로 처리할 수 있는 방법은 다음과 같습니다:
이벤트 전 또는 중 반복 설정을 끄고, 다음 달을 위한 새 이벤트를 게시합니다.
관련 게시물을 전용 아카이브 게시물로 이동합니다.
이벤트 게시물에 달린 게시물을 자동 삭제합니다(다만 이 작업의 타이밍이 다소 어색합니다).
이러한 유형의 이벤트는 반복 기능을 완전히 포기하고 모든 것을 수동으로 처리합니다.
아쉽게도 이 방법들 중 어느 것도 만족스럽지 않습니다.
반복 기능이 현재 이벤트 주제를 그대로 보존하고, 이벤트가 완료되면 다음 이벤트를 위한 새로운 주제를 생성하도록 하고 싶습니다.
이렇게 하면 현재의 자연스러운 흐름을 유지할 수 있을 뿐만 아니라, 과거 이벤트에 대한 적절한 아카이브가 자동으로 보존되며, 새 이벤트에는 ‘깔끔한’ 주제가 제공될 것입니다.
그 대가(복잡성 증가 외)는 활성 이벤트의 URL이 변경된다는 점입니다. 일부 경우에서 이것이 문제가 될 수 있다고 봅니다.
1개의 좋아요
안녕하세요, 이 경우 반복 이벤트 시리즈의 현재 이벤트가 종료될 때까지 기다린 후에야 다음 이벤트에 구독할 수 있다는 뜻이 되나요?
제가 Joomla에서 작업해본 대부분의 이벤트 플러그인은 이벤트 시리즈를 바로 생성합니다. 여기에서 제안하신 아이디어처럼 이벤트별로 개별 주제/URL을 생성하는 방식이 더 적절한 모델이라고 생각합니다.
반복 이벤트가 시작되기 x일 전까지 구독을 허용하지 않는 옵션을 제공하는 것도 실용적일 것입니다.
아카이빙 관련해서, 이벤트는 대부분 자체 하위 카테고리 안에 있거나 태그를 붙일 수 있을 정도로 충분히 묶여 있어서, 이들을 함께 유지하고 자동화된 작업을 수행할 수 있지 않나요?
nathank
8월 31, 2026, 9:26오전
9
네, 하지만 현재 상황과 다르지 않습니다. 현재도 현재 이벤트나 전체 시리즈에 대해 RSVP할 수 있으니까요.
이벤트를 복제하고 답변을 이동하는 작업, 혹은 유사한 작업을 말씀하시는 건가요? 워크플로(Workflows)가 이 일을 할 수 있을 것 같습니다. 그 부분을 살펴볼 계획이었거든요.
제 경험상 이벤트에서 시리즈 전체에 RSVP를 보내는 것보다, 시리즈의 특정 이벤트를 나중에 구독하는 기능이 더 많이 사용되었습니다. 물론 두 옵션 모두 중요합니다.
네, 맞습니다. 하지만 제 설치 환경에서는 해당 기능을 수행하는 워크플로우를 찾을 수 없네요.
이것은 그 자체로 별도의 기능 요청 사항일 수 있으며, 이벤트 주제 범위를 벗어난 흥미로운 내용이라 새로운 주제를 별도로 생성해야 할 것 같습니다.
우리는 특정 조건이 충족되면 자동으로 아카이빙되는 기능이 필요합니다. 여기서는 "이벤트 날짜 또는 존재하는 경우 종료 날짜"가 과거이거나, 주제가 x일 이상 닫힌 상태일 때 트리거가 되도록 해야 합니다. 또한 이벤트가 끝난 후에도 며칠 동안 사람들이 댓글을 달 수 있도록, 작업이 실행되기 전 선택 가능한 지연 시간을 설정할 수 있으면 좋겠습니다.
Ethsim2
9월 3, 2026, 12:02오후
11
여기서 일부 진전이 있었습니다.
워크플로우용 Event ended 트리거가 이제 병합되었습니다:
main ← events-workflow-triggers
merged 10:09AM - 02 Sep 26 UTC
Previously, the events plugin had no way to drive a workflow from an RSVP or fro… m an event finishing, and a trigger node contributed by any plugin was added to the registry but never subscribed to its `DiscourseEvent` — so it saved fine, showed up in the palette, and silently never fired.
This change wires the subscription into node registration, which drops the hand-rolled `on(...)` workarounds in assign, topic voting and chat, and adds `trigger:event_participation_changed` and `trigger:event_ended`, both scopable to a single topic.
---
Split into two commits, since the first touches shared infrastructure:
- **`FIX: Subscribe trigger events for workflow nodes added by plugins`** — claiming a node now registers *and* subscribes it, and contributing plugins are flushed before the host claims its own, so ownership lands on them. Because the subscription goes through `Plugin::Instance#on`, a node stops listening while *its own* plugin is disabled rather than following the host's setting. This also drops a duplicate registration that let `trigger:chat_message_created` show in the palette while chat was disabled.
- **`FEATURE: Workflow triggers for event participation and event end`** — the two triggers. No `on(...)` wiring needed in the events plugin thanks to the commit above.
Three behaviour changes in the events plugin, each deliberate:
- Withdrawing an RSVP destroyed the record without publishing anything, so attendance state built from these triggers could never recover from someone leaving. Removal now publishes, and reads as `status: null` with `removed: true`. The livestream chat sync skips removals, so its follow/unfollow behaviour is unchanged.
- The ended occurrence travels with `:discourse_post_event_event_ended`. `set_next_date` moves the event on immediately afterwards, and `Event#starts_at` returns `nil` once a bounded series is past `recurrence_until`, so the event alone cannot say which occurrence ended.
- Re-submitting an unchanged RSVP still publishes, so the trigger ignores it rather than running a workflow twice for one decision.
Payload is `{event, post, topic, stats}`, plus `{user, participation}` on the participation trigger — modelled on `WebHook.build_calendar_event_payload` rather than `EventSerializer`, which goes admin-truthy under a system guardian. No JS, no core changes, no new site settings.
### Known gaps, documented rather than fixed
Bulk invite, `Event#create_invitees` (`insert_all!`), `reset_invitee_notifications` (`update_all`), `enforce_private_invitees!` (`delete_all`) and event/user destroy stay silent. `create_attendance!` swallows `RecordNotUnique`, so a concurrent first RSVP fires nothing. `event_ended` can re-fire if an edit resets `finished_at`, and is missed when an event is closed early: `EventDate.pending` merges `Event.open`, so the in-flight occurrence leaves the job's scope.
`EventListener` does not rescue `new`/`valid?`/`matches?` and `DiscourseEvent.trigger` re-raises, so a raising subscriber aborts `MonitorEventDates` mid-`find_each`. Adding `continue_on_error:` there breaks existing `track_events` assertions, so it is left for its own commit.
### Testing
Full `discourse-workflows` and `discourse-events` backend suites pass (4005 examples), plus the workflow specs in chat, assign and topic voting. Verified at runtime that all 22 trigger nodes have exactly one subscription and there are no duplicate registrations, and that both new nodes disappear from the palette and stop dispatching when `discourse_events_enabled` is off.
Meta: https://meta.discourse.org/t/discourse-calendar-events-webhook-triggers-automations-plugin/409623
또한 워크플로우에는 이미 기존 주제를 Get하고 새 주제를 Create할 수 있는 Topic 액션이 있으며, Wait 노드도 있습니다. 따라서 제안된 롤오버의 상당 부분은 전용 이벤트별 아카이빙 기능이 아니라 워크플로우로 구성할 수 있을 가능성이 큽니다.
다음과 같은 구조가 가능합니다:
Event ended → Wait → Topic / Get → Topic / Create
이 방식을 사용하면 기존 주제의 제목/본문/카테고리 데이터를 사용하여 후속 주제를 생성하는 동시에, 완료된 주제는 그대로 아카이브로 유지할 수 있습니다.
아직 확인이 필요한 부분은 기존 주제의 어떤 부분을 자동으로 복사할 것인지입니다. 예를 들어 태그, 업로드 파일, 이벤트 반복 상태, 그리고 답글을 이동할지 아니면 그대로 둘지 여부 등이 해당됩니다.
저는 또한 워크플로우에 Event 액션을 도입하는 오픈된 PR이 있습니다:
main ← Ethsim12:workflow-event-close
opened 06:39PM - 26 Aug 26 UTC
## What does this change?
Adds an `Event` action to Discourse Workflows, allo… wing a workflow to:
- Close an event
- Open an event
The action accepts a topic ID and optional actor. The event is resolved from the
topic's first post, consistent with the Events plugin's existing requirement that
an event belongs to the first post.
Rather than updating the event record directly, the action updates the `[event]`
block in the post raw using the normal workflow post-editing path. This allows the
existing Events post-edit synchronization to update the persisted event state.
Edits use the workflow execution context's `edit_post`, which applies the actor's
normal post-edit permissions and uses `skip_workflows: true` to avoid recursively
triggering workflows from the event state change.
The action is idempotent when the event is already in the requested state.
## Example
A `Post created` trigger can use:
- Action: `Event` → `Close event`
- Topic ID: `Input → topic.id`
- Performed by user: System user
This allows, for example, a reply to an event topic to automatically close the
event without closing the topic itself.
## Testing
- RuboCop: no offenses
- Syntax Tree: all files match expected format
- New Event workflow specs after final rebase: 8 examples, 0 failures
- Full `discourse-events` suite before final formatting/rebase: 1124 examples, 0 failures
- Manual browser test confirmed:
- `Post created` → `Event / Close event`
- dynamic `topic.id`
- System user actor
- replying to the topic immediately changed the event to `Closed`
- the topic itself remained open
- the change appeared live without a page refresh
- workflow execution completed successfully
## Screenshots
### Event workflow actions
<img width="1920" height="965" alt="workflow_screen_with_events_menu" src="https://github.com/user-attachments/assets/d283e9e6-e1db-4f5e-8cf9-3ed5c31f55fc" />
### Configuring the Event action with the triggering topic
<img width="1921" height="1003" alt="configuring_events_step" src="https://github.com/user-attachments/assets/725e28ca-f8f2-45f3-b124-4c3310c69eb9" />
### Event automatically closed after the workflow runs
<img width="1920" height="1000" alt="event_topic_after_auto_close" src="https://github.com/user-attachments/assets/a66138ad-bbaa-498a-9d87-2bd1eef9e495" />
기본 PR에는 Close event와 Open event가 포함되어 있으며, Set attendance를 추가하는 스택된 후속 PR도 있습니다:
main ← Ethsim12:workflow-event-attendance
drafted 01:21PM - 29 Aug 26 UTC
Depends on #42932.
This is a stacked follow-up to #42932 adding `Set attendance… ` to the Event workflow action.
Until #42932 merges, GitHub's diff also contains the prerequisite Event action changes. Once #42932 is merged, this branch will be rebased onto the updated `main` so this PR contains only the attendance changes.
해당 액션은 구조적으로, 적절한 경우 추가적인 이벤트 전용 작업을 별도의 후속 작업으로 추가할 수 있도록 설계되었습니다.
1개의 좋아요
좋은 제안 감사합니다. 종료 조건은 도움이 될 수 있지만, 원래 상황에는 완전히 적용되지 않을 수도 있습니다.
특히 반복 이벤트의 경우 이벤트 카테고리가 매우 커질 수 있으므로, x일 이상 종료된 모든 토픽 이벤트를 과거 토픽 카테고리로 자동 아카이빙/이동하거나 아카이브하는 방법을 제공하는 것이 합리적일 것입니다.
하지만 이 아카이빙 문제는 반복 이벤트가 메인 이벤트 토픽과 연결된 개별 토픽이 되도록 하는 결정에 달려 있습니다.
1개의 좋아요
Ethsim2
9월 3, 2026, 5:37오후
13
이 기능을 선택적(opt-in) 반복 이벤트 모드로 구현한 PR을 열었습니다:
main ← Ethsim12:feature-recurring-event-topic-mode
opened 05:23PM - 03 Sep 26 UTC
## 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.
두 가지 옵션을 가진 discourse_post_event_recurring_topic_mode 사이트 설정을 추가합니다:
reuse_topic — 기존 동작이며 기본값입니다.create_next_topic — 완료된 발생(occurrence)의 토픽을 유지하고 다음 발생을 위해 새 토픽을 생성합니다.
create_next_topic를 사용하면, 발생이 종료되면 완료된 토픽은 해당 완료된 발생에 이벤트가 고정된 상태로 유지되고 재귀 설정은 제거됩니다. 이후 다음 재귀를 위해 후속 토픽이 생성되며, 원래 제목/본문, 카테고리, 태그, 작성자는 유지되지만 이벤트 날짜는 진행됩니다.
자동화 테스트는 또한 RSVP 롤오버(이관) 의미를 다루며, 반복되는 going 참석 상태는 후속 토픽으로 이관되는 반면, 일회성 참석 상태는 완료된 발생에 그대로 남아 있습니다.
이 롤오버는 트랜잭션 기반으로 처리되므로, 후속 토픽 생성에 실패할 경우 발생 상태가 보류(pending)로 유지되며 절반만 완료된 상태로 방치되지 않고 재시도할 수 있습니다.
이것은 구체적으로 "현재 발생이 종료되면 다음 토픽을 생성한다"는 모델을 구현합니다. 위에서 @opcourdis가 언급한 대안 모델인, 모든 미래 발생을 사전에 개별 토픽으로 생성하는 방식은 아직 지원하지 않습니다.
기존 동작이 여전히 기본값이므로, 완료된 이벤트 토픽을 아카이브로 활용하기를 원하는 사이트는 이를 선택적으로 적용할 수 있습니다.
1개의 좋아요
감사합니다. 이 모델은 이미 주최자에게 매우 잘 작동합니다. 이제 주최자들은 매번 이벤트를 다시 생성할 필요가 없다는 것을 확신할 수 있으며, 주최자가 특정 이유로 인해 언제든지 이벤트를 취소할 수 있으므로 사람들이 미리 구독하지 않는다는 안전장치도 제공합니다.
제가 제안한 ‘미리 생성’ 모델도 많은 경우에 작동하며, 여러분의 이벤트 후속 모델과 보완적으로 작용할 것입니다.
그리고 이벤트 후속 모드 PR 에 대해:
새 이벤트에 구독한 사람들이 원래 이벤트/토픽과 마찬가지로 해당 토픽/이벤트가 반복 이벤트 시리즈의 일부임을 여전히 알 수 있는가?
이벤트에 기존 게스트를 자동으로 초대하는 것이 옵트아웃/옵트인 옵션인가? 이렇게 묻는 이유는, 이미 첫 번째 이벤트를 통해 그들에게 이벤트와 시리즈를 한 번 홍보했으므로, 향후 이벤트가 반드시 그들에게 항상 홍보해야 할 이벤트는 아니기 때문입니다.
Ethsim2
9월 3, 2026, 8:02오후
15
네, 후속 이벤트가 반복 구성을 유지한다는 의미에서 그렇습니다. 예를 들어 GUI 스모크 테스트에서 원래 발생 건은 매주 목요일로 표시되었고, 롤오버 후 후속 토픽도 매주 목요일로 표시되며 날짜가 다음 주로 진행되었습니다.
이 PR에서 추가하지 않은 것은 완료된 토픽과 그 후속 토픽을 연결하는 별도의 크로스 토픽 시리즈 관계입니다. 완료된 토픽은 일회성으로 아카이브된 발생 건이 되며, 후속 토픽이 반복을 이어갑니다. 해당 토픽들 사이에 명시적인 시리즈/부모 관계가 유용하다면 별도의 개선 사항으로 추가할 수 있습니다.
모든 게스트/참석자를 새 이벤트로 자동으로 이관하지 않습니다.
후속 이벤트는 반복/시리즈 RSVP가 활성화된 상태로 참석한 사람들만 상속합니다. 개별 발생 건에만 참석 RSVP를 한 사람은 완료된 토픽에 머물며 후속 이벤트에 추가되지 않습니다.
따라서 현재로서는 시리즈에 RSVP하는 기존 선택이 향후 후속 이벤트로 이관되는 데 대한 옵트인으로 작용하며, 이를 제어하는 별도의 사이트 설정은 없습니다.
1개의 좋아요