šŸ“… New Calendar Feature: End Date for Recurring Events

You can now set an end date for recurring events in Discourse Calendar! :sparkles:

This much-requested feature allows you to specify when a recurring event series should stop, giving you more control over your event scheduling.

Create events that repeat daily, weekly, or monthly - and now determine exactly when they should end.

For more details on the Calendar plugin and its features, visit the official Calendar topic.

In the future, we might add the possibility to exclude specific weekdays.

22 Likes

A tricky thing with the work ā€œUntilā€ is that it is not totally obvious if it is included or excluded? Is there anything we can do here to give better clarity?

2 Likes

Yeah, Google Calendar has the same issue! They use On, but it suffers from the same ambiguity:

However, I think that most users would safely assume that Until includes that date.

3 Likes

Until (included):

?

edit: I did this for now UX: better copy by jjaffeux Ā· Pull Request #737 Ā· discourse/discourse-calendar Ā· GitHub seems like a good simple change.


An alternative solution would be to display the actual date/time next to the date input, but probably overkill?

3 Likes

You might want to borrow some ideas from my impementation of the Voucher Start/End dates in the New Voucher dialog in an e-commerce I’m working on:


Another example to demonstrate the flexibility and how we avoid ambiguity in date ranges in the UI:


Technical detail: In our application, we always save dates as ā€œtimestamp with timezoneā€ (postgres), so no database setting, nor connection setting, can affect the actual timestamp stored. Even though Postgres does not recommend it, we do it because it gives 100% guarantees of the date correctness in any situation and in any SQL query. You can operate with date timezones right in postgres using their date/time/timezone functions and be certain that it will work 100% correct always. We rely on it.

And then we have a timezone setting for all types of entities that need it: user profiles, markets, vouchers, reporting for accountants, and so on - so that we can translate any dates to any timezones on the fly without hesitation.

The main takeaways here are:

  1. Always store date and time with timezone.
  2. Always store timezone preference.
  3. Be very explicit about dates in the UI, don’t do any magic.
  4. Let the user see the actual dates in the choosen timezone before they click ā€œSaveā€.
1 Like

Hello,

On my self-hosted instance (just generated a month ago), I do not see any end date option.

Am I doing something wrong ?

I think the screenshot shows the Insert date / time dialog rather than the Create event dialog.

Those are two different workflows in Discourse Calendar:

  • Insert date / time is used for replies in a topic whose OP contains a [calendar] block.
  • Create event creates an actual Event ([event ...][/event]) and is where the recurring Event settings, including the recurrence end date, are available.

So for the feature announced in this topic, try opening the composer + menu and choosing Create event, rather than Insert date / time.

I was testing that recurring Event flow recently and also found an edge case after a bounded recurrence has completely expired, which I’ve opened a fix for here:

1 Like

Indeed it was to maintain a calendar (collecting events) in a topic.

Sorry for the misunderstanding, I’m new to this.

Indeed when creating an event, it seems to work.

A pity that it does not work for Insert date / time.

Thanks for your help !

1 Like

No problem :slightly_smiling_face:

Just to clarify, I don’t think this is really a case of the feature not working for Insert date / time - it is a different workflow.

Insert date / time is used when you have a [calendar] block in the opening post of a topic and want dated replies to appear on that particular topic’s calendar.

Create event, on the other hand, creates an actual Discourse Event ([event ...][/event]). The recurring-event end date discussed in this topic applies to that Event recurrence system.

So if your aim is to maintain a calendar local to one topic, the workflow shown in your original screenshot is the appropriate one; it just doesn’t use the same bounded-recurrence feature as Events.

Yes I understand.

The use case is to maintain a calendar for my school. There are always appointments to be entered and so any parent can reply to the topic to add a new appointment.

But just yesterday, I needed to enter a recurring appointment and unfortunately we don’t have this option in this workflow. So I have to do it manually by replying many times to the topic with a new date (don’t know if there is a clever way…).

There may be a way to automate the manual replies while keeping your existing topic-local [calendar] workflow.

One possibility would be to use a dedicated Discourse user with reply-by-email enabled, then have something such as Power Automate or an Azure Logic App generate the individual dated replies and send them into the calendar topic by email.

For example, a weekly appointment with an end date could be expanded by the automation into the required individual replies, so parents would still see one normal topic calendar rather than separate Event topics.

There are a few details around Discourse’s per-user reply-by-email keys that would need to be set up carefully, so this topic probably isn’t the best place to go through the configuration.

If that approach would be useful to you, I’m happy to help work through it in a separate Meta topic.

It only happened once at the moment, so I’ll wait until next time (and hope that it won’t happen again).

I’ll keep the reply-by-email trick, thanks. But does that mean that for an event every week for a whole year, we’ll have to generate 52 replies ? It will make the topic difficult to read…

Otherwise I suppose, as I have admin rights, that I can also use the API to add manually the appointments.

Thanks for the insights !

Yes - unfortunately the API would automate creating the replies, but it wouldn’t really solve the clutter problem: for a topic calendar the individual calendar entries are still represented by individual replies.

I’ve just found an existing feature request which is almost exactly your use case:

Their example is a course occurring on twelve consecutive Wednesdays, and they make the same point: creating every occurrence individually is tedious and clutters the topic.

They suggest allowing recurrence in Insert date / time together with an end date for the final occurrence, which sounds very close to what you need.

So rather than building an API/Power Automate workaround that generates 52 posts, that feature request is probably the better place to add your school-calendar use case.

1 Like

Thanks, I’ll do that !