When converting widgets to Glimmer and modernizing the plugin, there were some small leftovers.
status wasn’t tracked, so the UI didn’t update
raw_invitees should be camelCase now
custom_fields should be camelCase, and setting it was not working
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.
Following the key change in d31933bf49 this has been broken.
This commit also hides the section if `sort_categories_by_event_start_date_enabled` AND `disable_resorting_on_categories_enabled` are not enabled, prior to this change we would just show the title, with no checkbox to check.
This commit has 3 parts:
- Ensuring than when attempting to join a event we return an invitee even if the user was already part of the event, before we would return null which would have required a special handling. In this case we were just adding a null invitee.
- Ensures invitees/suggestedUsers/sampleInvitees use tracked properties correctly. And do not require to manually create a TrackedArray, the model should always handle this implementation detail.
- When joining an event we were pushing the watchingInvitee to the sampleInvitees even when the watchingInvitee was null, which would create an error.
This could happen during a server error for example. Ideally we should ensure the post event doesn't disappear on such error, but at least for now we avoid the crash.
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.
Interested and not going are generally not used.
To avoid adding this clutter to the UI we now suppress this.
Sites wishing to have these buttons can amend the `event_participation_buttons` site setting
Also:
- Add a show participants button even if there are no participants (so admins can populate events)
- Fix localization for event participation
- Allow toggling attendance by pressing the same button
- Removes leave event button from the dropdown menu
- Refactors outlets to allow maximum flexibility
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
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>
Previously event editors could remove people from an event but had no way
of acting on behalf of users in the event and adding them.
That meant that for events to properly show up in agenda and so on a user
must actively click a button.
In some cases (company ran events) the event manager may prefer controlling
attendance.
* FIX: shows category calendar on hot/latest
The previous URL parsing code was not resilient to these paths, we now use the router to recognize these paths and extract the params we need.
* linting
* Update category_calendar_spec.rb
This codepath was buggy when the title was ending with digits and moreover it's usefulness was debatable given post events support showing the date in the topic list; you shouldn't need to have the date in the title itself.
WE "recently" did a few changes in the way we use the availability topic
- We used to have 1 topic per year, but have now moved to just using one topic and deleted past posts
- We used to delete past automatic holidays, but we don't anymore since we use them to keep track of #leave days used
- There are more employees covering more regions
All three changes made the query that list all the events to be displayed in the availability topic go 💥
It used to be
- 1 query to list all events from 6 months ago up to 6 months in the future
- 1 query for every events to load the associated user
- 1 query for every events to load the associated's user timezone
So basically, a N*2 + 1 😅
This commit fixes the issue by doing
- 1 query to get all "standalone" events (those associated to a post)
- 1 query to get all the users timezones (just the ones who have an holiday in the current period).
- 1 query to get all the "automatic" events (aka. holidays that are comming from the holidays gem).
So we went from N*2 + 1 down to 3 🚀
David Taylor