Prior to this fix when computing the next event date we were resetting the status of every invitees. The status will now only be reset for non going users.
Various events in the life of this plugin have caused an over complicated key and duplicated keys. This commits attempts to regroup everything related to discourse_post_event under a top level `discourse_post_event` key, removes the `event_ui` level as it's not very clear, technically everything is UI. And finally attempts to remove the duplicates.
This commit is making two major changes:
- Move all the post event widgets code to glimmer
- Implement tracked models to ensure reactivity, many paths didn't have real reactivity atm and were mostly working by luck or the fact that widgets re-render a lot
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
In https://github.com/discourse/discourse/pull/24740, `min_trust_to_create_topic` site setting was replaced by `create_topic_allowed_groups`. This PR replaces the former, deprecated one, with the latter.
Before, site settings were divided into `discourse calendar` and `discourse events`.
This PR is merging them. Also, translation were moved under `discourse_calendar` key.
The #queue_jobs= method on site settings has been deprecated and replaced by Jobs.run_later! and Jobs.run_immediately!. This PR replaces usages in this plugin so we can remove the fallback in core.
Return an empty array instead of nil when the plugin store has not yet
been populated with `users_on_holiday`.
At the moment, the `currently_away` report fails if the
`UpdateHolidayUsernames` never gets the chance to update `users_on_holiday`.
Before this, it took up to 10 minutes for status to update after posting on the calendar topic or editing an existing calendar topic post. Now status will be updating immediately.
Before, the calendar plugin was setting this custom holiday flair in many places in Discourse. Starting from this PR, the calendar plugin will be setting user status in core instead.
Note that from now we start to show holiday's end date. If a user has several holiday events simultaneously (this can happen easily, for example, if a user is on vacation and today is a public holiday in their country), the date will be taken from the longest event.
Note also that there is an edge case that's not handled in this PR - if a user has several holidays one after another (let's say they are sick this week and has a vacation on the next week), it would be nice to show as the end date of the holiday the ending date of the second holiday. For now, the plugin uses the end date of the current holiday in such cases, but I'll improve it in one of the next PRs.
Also, in this PR, I directly use methods of the user model from Core. We definitely need API calls instead. This fix is also coming soon.
Alan Guo Xiang Tan
Joffrey JAFFEUX
Régis Hanol
Jarek Radosz
Krzysztof Kotlarek
Ted Johansson
Sam
Jan Cernik
Selase Krakani
David Taylor
Angus McLeod
Andrei Prigorshnev