Are there any plans to allow multiple events per thread or per post?
The use cases off the top of my head are:
I’ve run into this limitation while experimenting with a calendar-driven discussion workflow on a student forum.
My use case is that each calendar event becomes the anchor for a discussion topic, rather than the event being the only thing in the topic.
For example, if I’m trying to schedule a meeting with someone, I might offer several possible time slots in the same discussion topic:
• Tue 31 Mar — 12–1pm
• Wed 1 Apr — 10–11am
• Fri 3 Apr — 3–4pm
Ideally I’d like to include multiple [event] blocks in the same topic so that:
• each proposed time appears on the site calendar
• participants can mark themselves as attending a specific slot
• once a time is chosen, the other events can simply be removed or edited
This becomes even more useful when the event topic doubles as a discussion thread before and after the event (agenda, notes, follow-up questions).
Another example from my forum is academic discussions where:
• a lecture
• an office hour
• and a revision session
might all be related to the same topic thread, but are still distinct events on the calendar.
At the moment the workflow tends to push people toward one event per topic, which fragments the discussion. Allowing multiple events per topic would make it easier to keep related conversations in one place while still benefiting from the calendar integration.
May I propose an alternative workflow to achieve what you are after?
What do you think?
That workflow makes sense if the goal is simply to choose one time via a poll.
In the situation I’m thinking about, the candidate times behave more like tentative events that need to appear on the calendar while scheduling is being worked out.
For example, imagine a business where customer bookings automatically create events on the calendar. At the same time we’re trying to arrange an employee social and propose several possible time slots.
Those employee slots might initially look viable, but if a higher-priority customer event appears and conflicts with one of them, that slot may need to be dropped or moved. In that sense the calendar is acting as a global scheduling view, not just a way to pick the most popular time.
So the candidate times themselves need to appear on the calendar while the discussion is still deciding between them. Once a final time is approved, the other [event] blocks could simply be removed or edited.
One way this could work is if a topic could contain multiple [event] blocks, with one designated as the main event and the rest treated as tentative or secondary events. The main event would be the canonical one for the topic, while the others would simply appear on the calendar as candidate slots during scheduling.
The main event could either be:
• manually approved (for example after checking conflicts with higher-priority events), or
• derived dynamically from a poll if the discussion is using voting to choose a time.
From looking at how the plugin works, events are already parsed from [event] blocks inside posts and stored as separate records for the calendar. That suggests the “one event per topic” rule may be mostly a UI constraint rather than a structural one.
Allowing [event] blocks in multiple posts (with one optionally marked as the main event) could preserve the current mental model while enabling scheduling workflows where several tentative events need to exist in the same discussion topic.