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.
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.
Joffrey JAFFEUX