I miss the function for repetitive events which in the rhythm “every 1. Monday of the month” take place.
What can I do? Would there be another plugin that works better?
Is there any way to manually force “Monday”, as the first day of the week, on our instance, for now?
4 Likes
Does anyone know of a way for URL of the event to only show up when they click “going”? especially for Private events.
1 Like
No, but you can vote for it.
3 Likes
I have a problem. With recurring events, participants remain listed even after the event has ended. This makes it unclear whether they signed up for the past event or the next one.
It’s possible to remove participants manually, but only if you have moderation rights.
Is there a solution for this?
The other problem: In the calendar, for recurring events, only the next upcoming event is displayed.
This is also inconvenient—if I want to check which events are scheduled in May, I can’t see them.
1 Like
Have you considered using Events Plugin 📆 instead? It handles that particular issue nicely!
1 Like
What Calendar are you seeing this behavior: the one within a category or the /upcoming-events calendar?
Is your plugin up-to-date? We had a fix on early January for the /upcoming-events calendar.
1 Like
I’ve enabled a calendar in a category. When I filter the category on a tag, the topics listed in the category are filtered. But the topics showing in the calendar for the category are not. I can’t see anything in the settings but maybe I’ve missed something. Or is this functionality not available?
Not sure if this is connected to the plugin or an issue with the greater Discourse translations at-large, but a user reported this missing variable for the Dutch translation in the events area.
This is a plugin I definitely needed! Thanks for the good work 
A post was split to a new topic: Calendar feature
A post was split to a new topic: Creating events doesn’t respect user’s 12 hour time locale
As an FYI to everyone using this plugin: If you want to give all logged in members access to this feature DO NOT use the everyone group, use trust_level_0. It was non obvious to me until I read that the everyone group actually includes even non-logged in users and that it’s generally not appropriate to attach permissions to this. (In practice, associating the calendar permissions with everyone does nothing at all - new users will be unable to access the feature.)
The plugin might do a better job of 1) eliminating everyone from the selection, 2) having some note to the admin to use trust_level_0 if that is their intention.
Or Discourse could change their APIs to remove the everyone selection to make it more natural for plugin developers to offer the right options.
Cheers and thanks for the plugin. Very useful in my community!
It’s a mistake in the Dutch translation. In this case, the placeholder %{duration} was translated to %{duur}.
Crowdin
It seems this has also happened on some other strings:
I have tried to fix the placeholders, but because the old ones have already been approved, a new translation no longer overwrites the existing one. Someone with permission to approve the new translations is needed to get the changes to GitHub.