FWIW (and it may not be worth much!), this was the necessary feature that led to my organization deciding not to use the plugin. Without this ability, it was too much work to maintain the schedule in creating the same event over and over and over again. I have no idea how hard it is to do something like this and it is an absolutely brilliant plugin as is, so please hear how appreciative and impressed I am that this is even a thing in the first place.
Thank you for this feedback @carson, it’s actually quite valuable!
I hope to actually get this done soon, but I’ve been very busy with paid work and some of my other plugins.
We have recurring events as well and would find this useful, though it’s a bit further down our own priority list.
I’ve started to think about recurring events.
This is how it’ll work.
Event type. Normal/Recurring.
For recurring, there will be an option, Happens Every in the composer.
We’ll limit the number of times the recurring event happens for the first version.
We can have a DiscourseEvent fire every time a new event post is created which allows other plugins to use that to extend functionality.
Every time an event post is created, and if its a recurring event type, then a sidekiq job will be scheduled accoring to the Happens Every field set in the composer. We’ll maintain a custom field
parent_eventfor the events created by the sidekiq jobs.
The parent event will have two custom fields
recurring_number_remaining. Every time a sidekiq job tries to create a recurring event, it’ll check with the
recurring_number_remainingis nonzero, and will decrement it by one.
Also, the recurring event will be on the same category and will have the same author as its parent event.
Yet to figure out
- How to stop the recurring event chain before all the chain events have actually occured.
@angus, I would like to hear your thoughts on this.
I am also thinking about places where we can allow extension of events plugin by other plugins.
So you’re thinking that a “Recurring” event will automatically create new topics for each event?
p.s. Before we move onto this properly, let’s review and (if appropriate) merge that outstanding PR, as that work is already completed. Still happy to think it through now though.
Sure. I’ll test that PR and will get back to you on it.
I’ve updated my review here.
Great that we’re thinking about this, because handling logistics before, during and after recurring events is a common need in my community and we struggle to do it well. Not everything can be handled by discourse, but the more we can pack in here the better!
I also have been expanding the use of my personal forum and have seen it would be interesting and valuable to be able to have recurring events in there as well, most immediately for a family video conference call that takes place on Sundays. We often need to coordinate ahead of time to determine if enough people are available to have the actual call and if so who should start it using the GoToMeeting platform. Sometimes comedy ensues. Often I am sitting in front of my computer by myself when I would rather be out doing something else.
I know setting up automated recurring events is notoriously complex, and it may not really be worth it to try to bring it into discourse instead of just using google calendar, outlook or some other “best of breed” calendar software. But it’s worth brainstorming and seeing if some MVP is possible that will not just create more frustration because we get close but not close enough to what most people will be satisfied with.
Likely overkill and maybe too hard, but what if recurring events lived inside a single topic instead of in a topic that spawns more topics? So the OP would have event settings including recurrence, the currently posted event and when the next event will be posted. Replies would automatically be added to the OP on the scheduled day, and each would have its own date/time, RSVP and ADD TO CALENDAR settings. The topic and reply event details can be gardened, to remove any events that did not take place and to update dates of events. As usual, post content can also be updated with event details before/during the event. Afterwards they can be edited to make them “evergreen” with a summary etc.
I can relate! Do you find GoToMeeting the best for group video chats? We have tried a few different platforms, but I’m still unsatisfied…
Yes, I think recurring events have to be in a single topic. I can see arguments in favour either way, but I can’t see a way to overcome both the dev and UX issues with auto-creating new (empty) topics for every single event in a series.
The question then becomes how to handle it within a single topic. I think the way to do this is to have a concept of a “Primary” event and two seperate lists of “Upcoming” and “Past” events. The primary event is the event functionality as it currently exists and is always the next event in the series. The “Upcoming Events” is a list of the upcoming events, and the Past events are those that have past.
In the UI it would look something like this, i.e. dropdowns with lists of the upcoming and past events.
Yes, I am finding GoToMeeting to be my preference over other options. The cost is within the realm of the reasonable (though not free) and it provides phone numbers in many countries for people to call in to join by phone, for free. (I just checked and Australia happens to be one of them. ) I am finding that whatever happens with the video, the audio seems to just keep on chugging, which is the highest priority for conference calls. Also, I can get up to go to the bathroom (mic muted!) or take a walk around the block to stretch my legs during calls! What’s not to like?!
I like your idea for “upcoming” and “past” events. The only thing I am not sure about is how people are going to RSVP for the upcoming events? Can we keep track of who attended past events, and maybe update it for future reference? I guess you could have a pulldown and then have buttons to select to indicate if you are planning to come. Staff could have additional buttons to add/remove people on their behalf. This may get unwieldy.
Also, each event in a series tends to have notes and its own conversations associated. Where does that live? In the OP, maintained by staff? that might work.
In my idea, each event would get a post in the topic where that stuff could live. Not sure how to make that easily navigable, or if that would be needed. E.g. there could just be a link to the next event at the top and you click and are taken down to the post to RSVP etc.
I can totally see that this will take time to articulate and think through. It’s worthwhile though!
I just had an interesting experience I’d like to relate, to hopefully help with the design of recurring events. If others can share stories of their cases that would also be helpful, to triangulate what is needed.
As I wrote above, my family meets on Sundays for a video conference call. A few weeks ago I created a google calendar event for Fridays to remind us all to RSVP. This has improved things immensely! One of us responds to the calendar event to start an email thread that everyone else then replies to. I like it because it also has turned into an opportunity to share a few lines about the week, which takes some pressure off everyone to actually make it to every call.
I created a topic on my personal discourse for the event, with instructions for joining in the OP. This week, I wrote my RSVP as a reply to that topic. Amazingly, my family replied to my post and all their replies landed in the topic without any issue, including some photos from my sister of a road trip she is taking up the US west coast. Neat! My brother also indicated he’s in Bangkok so too many time zones away to make the meeting, and my father wrote with an update on his week and plans for the month and that he plans to attend. A healthy back and forth ensued, talking about the cool stuff everyone is doing.
My father also wrote to clarify if replying to the discourse email is enough to reach everyone, which was also great - it gave me an opportunity to explain to all three of them a bit how discourse works. All of this without really doing too much onboarding to the forum for my family while beginning to move the logistics for planning these weekly calls into the forum. Going forward I am hopeful that I’ll be able to get these folks contributing to other topics, e.g. to share stories about photos from our childhood etc.
One gap I am noticing is that, with the current functioning of discourse, to make this setup work properly on an ongoing basis I’d have to create a specific category just for planning these conference calls and make sure that everyone in my family is watching the category. I can’t count on them logging in or adding their reply to RSVP to ensure they get notified of the next replies. I was hoping not to create this level of structure in my forum which makes it harder for people to understand/use and harder for me to maintain. I also don’t necessarily want to burden everyone who RSVPs with all the replies from everyone, because some day I’d like to encourage guest appearances from other family and friends in these calls.
Given this experience, it seems to me that the functionality Angus proposes can work extremely well. Staff can manage events and users can join future events and catch up on past events. The gap in your explanation so far, methinks, is with how users interact with and RSVP to specific upcoming events, and how they are informed.
The “primary event” could have notification settings inspired by GoToWebinar. GoToWebinar can be configured to send customizable reminder emails a week, a day and an hour before the event. I have found these to work well for making sure people show up for events in my (work) community and I always use all three of them. For my weekly family calls, I might like to just remind a day (or two days) and an hour before. In discourse, it seems suitable to have these reminders posted automatically to the bottom of the topic itself. People can then reply to informally RSVP and start to get a conversation going in the topic and deal with any last minute logistics.
The UI and granularity of user event options is an open question. I’d suggest keeping this interface as simple as possible, and just allow users to RSVP/unRSVP to be notified about any upcoming events and not to worry about who actually attends each specific event in the series. How the notification is handled I do not know - my instinct tells me you would probably want to stay away from the notification levels which I think newbies don’t always understand anyway and might add too much complexity, but maybe there is an easy way to leverage that functionality. If you do want to use it, you could try to add an additional notification level to choose from for event topics to let people set it to be notified when event reminders are posted. RSVP/unRSVP button within the topic itself could also be provided.
How to manage what to display in the “past events” and “upcoming events” pulldowns is also an open question. I’d suggest having staff settings to specify how many past and upcoming events to display. Once a reminder has been posted, a link could be provided to the reminder so users can jump down to the specific event. Each upcoming event might have an “add to calendar” option so users can decide for themselves which they want to put in their own calendars. (I would not even try to provide the ability to add the event as a recurring event in calendars - that is fraught with peril as it will involve having to notify them they need to update their calendar when an event is cancelled or when the event schedule is changed etc, which I think we’ll never be able to do as well as google!)
For recurring events organized in my (work) community, I’d likely want to regularly update the OP after each event takes place to add a summary of each event and with invitation to contribute to agenda for upcoming events. This might get long so I’d use DiscoTOC to create a table of contents along the right side that provides direct links to info about the recurring event (how to join, purpose, how to get topics on the agenda etc) and summaries for each past event in the series.
This is extremely useful. Thanks @tobiaseigen!
Yes, I think this is a great point.
What we’ll need to do is think about both multiple events and rsvp’s for multiple events at the same time. We may not launch everything in one go, but we’ll definitely need to accomodate it in our technical thinking for this.
I seem to recall that the technical difficulty of this was one of the things that stopped me doing it in the past, so I both want to think through how it will work with RSVP, but not overcomplicate the first version of recurring events at the same time.
@fzngagan Have a think about who else, like @tobiaseigen, we can get feedback from on how they might envisage multiple events working for them. Particularly the people who have specifically requested it. Ask them to post in this topic. If you’re not sure about this, let me know and I’ll help out with this piece.
We can share a link to this topic on meta and on the github issue and request people to respond? What do you think?
One more thing we can do is, refer to plugins of other forums working similarly. Haven’t checked out yet but I’ll take a look.
Also, @tobiaseigen. Thanks so much for your valuable input.
The question which comes to my mind is, should I create a new meta topic or post in our plugin topic and ask people to respond here.
In my opinion, people will be favour of discussing it on meta itself. I suggest we post a new meta topic and link it to this one and see where the discussion builds up and take it from there.
Also, I would love if (at all) any of the core members(pavilion and discourse ) has some idea/suggestion on this.
Sorry I haven’t given you a product description of this feature yet. I’ve been flat tack with other stuff. I’ll give you a product description tomorrow.
@tobiaseigen Thanks for your input on this.
@fzngagan The way I’d like to do v0.1 of this is as follows:
Add a new boolean topic_custom_field: “event_series”.
Add a new string topic_custom_field: “event_series_period”.
Add a new JSON topic_custom_field: “event_series_past”.
- Add a new section in the “Add Event” modal below the RSVP section called “Series”. Give both RSVP and Series a title to clearly identify them
Have a single setting under the series heading, a checkbox with a dropdown: Repeat every [week / month].
If the “Repeat every” checkbox relates to the “event_series” field.
The dropdown relates to the “event_series_period” field.
When event data is saved we need to check if the event_series has been enabled or disabled, then enqueue (or cancel if event_series is disabled) a background job called “update_event” for the event_end time, or event_start time, if there is no event_end.
There is similar logic to this in the Custom Wizard plugin admin controller which you can use for reference:
if wizard['after_time'] && new_time Jobs.cancel_scheduled_job(:set_after_time_wizard, wizard_id: wizard['id']) Jobs.enqueue_at(after_time_scheduled, :set_after_time_wizard, wizard_id: wizard['id']) end if existing['after_time'] && !wizard['after_time'] Jobs.cancel_scheduled_job(:set_after_time_wizard, wizard_id: wizard['id']) Jobs.enqueue(:clear_after_time_wizard, wizard_id: wizard['id']) end
update_event background job, which should run after the current event if event_series is enabled should:
Save the all current topic event fields to “event_series_past” (including RSVP etc).
Update the topic event fields:
- event_start: current event_start plus the period.
- event_end (if exists): current event_end plus the period.
- RSVP list should be cleared
Just to this and only this for now. Don’t add anything to the topic title area yet. I want to do the most minimal version possible that we can test.
After we’ve done this we’ll
Add a UI to the topic header
Add upcoming events into the calendar and .ics feed.
Add custom upcoming events (i.e. not just according to a set period), through a “event_series_upcoming” field.
But don’t do this yet.
Thanks a lot for the spec. I’ll get back with any doubts along the way. Also, lets decide a timeline for this.
I’ve added a deadline for this v0.1 spec.