putty
(putty)
August 28, 2026, 8:16pm
42
Thanks, that did solve it!
3 Likes
Ethsim2
(Ethan )
August 29, 2026, 1:59pm
43
@gilles I’ve now implemented the follow-up I mentioned above:
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.
It adds a generic Event → Set attendance operation, with:
attendee
attendance state: Going / Interested / Not going / Remove attendance
topic ID
optional actor
So your original use case can be built as:
Post created → If first post → Event / Set attendance
using the event author as the attendee and setting them to Going .
I tested that exact pattern locally in the Workflows GUI, stacked on #42932 , and confirmed the user is automatically registered as Going on the event.
The PR is currently a draft only because it depends on #42932 . Once #42932 merges I’ll rebase it onto main, which will leave the attendance-only diff.
2 Likes
gilles
August 29, 2026, 2:11pm
44
@Ethsim2 Thanks, you’re the best
1 Like
putty
(putty)
August 31, 2026, 5:44pm
45
Is there a way to retry a workflow (with the same event), similar to how, with a webhook, you can resend a payload?
j.jaffeux
(Joffrey Jaffeux)
August 31, 2026, 7:51pm
46
No sorry we don’t support this atm
2 Likes
joo
(slower)
September 1, 2026, 6:04am
47
Is there a trigger/event that fires when a NEW tag is created?
When a new tag is created by a user, is there a way to automatically
add it to a specific tag group? If not, what’s the recommended approach?
1 Like
j.jaffeux
(Joffrey Jaffeux)
September 1, 2026, 12:23pm
48
No we don’t have any of this. Can you expand your use case please?
RGJ
(Richard - Communiteq)
September 1, 2026, 3:06pm
50
There is “Topic Tag Changed”. You could then call the Discourse API and see how many times the tag is used. If it’s one / if it’s on that specific topic, you know the tag is new.
Alternatively and maybe easier: you could setup a webhook for “tag is created” and point it to a workflow webhook trigger.
1 Like
joo
(slower)
September 2, 2026, 2:57am
51
Use case: I have an “artist” tag group. New artists debut all the time, so
new artist tags keep appearing when users create them. I want those new
tags to be automatically added to the “artist” tag group, instead of me
having to manually add them. Is there a good way to get
this result with Workflows?
j.jaffeux
(Joffrey Jaffeux)
September 2, 2026, 6:47am
52
how do you know it’s an artist tag and not another random tag?
joo
(slower)
September 2, 2026, 7:35am
53
That’s exactly what the AI step handles. The AI agent first determines whether a new tag belongs to any of the defined groups (artist / member / region / event-type / release-type); if it matches none, it’s skipped and never filed into a group. So random tags are filtered out, and only correctly classified tags get auto-added to a tag group.
1 Like
j.jaffeux
(Joffrey Jaffeux)
September 2, 2026, 8:58am
54
ok will add some trigger for tag created and a node for add tag to tag group
4 Likes
j.jaffeux
(Joffrey Jaffeux)
September 2, 2026, 2:41pm
55
We have added the following to workflows:
committed 02:40PM - 02 Sep 26 UTC
Add the `action:tag_group` workflow node for adding and removing tags.
committed 01:19PM - 02 Sep 26 UTC
Add a `tag_created` workflow trigger with serialized tag payloads.
committed 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
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
4 Likes