This pull request introduces two major new features to the calendar plugin: the ability to add a location/description to an event, and a new "My Events" view on the upcoming events page.
### Event Location
You can now add a `location` to an event. This is a free-text field that can be used for a physical address, a URL, or any other location details.
* A `location` field has been added to the event builder modal.
* The location is displayed in the event details in the post, complete with a new "location-pin" icon. URLs within the location field are automatically linked.
* This is supported by a database migration to add the `location` column, and updates to the event model, serializer, and parser.
### Event description
You can now add a `description ` to an event. This is a free-text field that can be used to describe your event.
* A `description` field has been added to the event builder modal.
* The description is displayed in the event details in the post, complete with a new "circle-info" icon. URLs within the location field are automatically linked. It supports linebreaks.
* This is supported by a database migration to add the `description` column, and updates to the event model, serializer, and parser.
### "My Events" Filter
The `/upcoming-events` page now includes tabs to switch between "All events" and "My events".
* The "My events" tab shows all upcoming events that the current user is "Going" to.
* This creates a personalized calendar for users to easily see their own upcoming schedule.
* A new `/upcoming-events/mine` route has been added, and the backend event finder now supports filtering by an `attending_user`.
### Other Improvements
* The calendar view on the `/upcoming-events` page now defaults to a "list" view on mobile for a better experience.
* The "Open Event" and "Close Event" actions now have a disabled/saving state to provide better feedback during the operation.
* System tests have been added to cover the new functionality.
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 🚀
The post_serializer_spec was calling Group.refresh_automatic_groups!(:admins), relying on that call booting system users from the group.
This change makes it so the implementation excludes any system users instead.
We must include the year identifier since now we can use same topic to track holidays for multiple years. Also, we don't need to load old public holiday events for more than 6 months.
When a public holiday is created, it is created in a specific user time zone.
https://github.com/discourse/discourse-calendar/blob/main/jobs/scheduled/create_holiday_events.rb#L71
When calendar is set as fullDay, we would like to display Christmas always 25th of December.
To achieve that, we need to have information about timezone, parse date in that timezone, and leave only year, month and day.
I added a test case to cover one bug scenario. User from Los Angeles have seen that user from Italy was celebrating Christmas Day on 24th of December instead of 25th.
Adds the option to enable a timezone adjustment for calendar events.
This will make it so events render offset from the grid to reflect the
appropriate start and end moments according to the viewer's timezone.
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, 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.
This was causing an error on topic lists after a zeitwerk reload. Using the official plugin API takes care of reloading correctly.
Followup to 139fdd9cc3
FEATURE:
- Added custom fields `sort_topics_by_event_start_date` and `disable_topic_resorting`
- Sort topics of event categories by event start date. Event categories have custom field `sort_topics_by_event_start_date` set to true.
- Disable re-sorting of categories with custom field `disable_topic_resorting`
- Event date displayed beside the Topic title can optionally be set to show the local date-time, instead of relative date-time.
-
Renamed the 'DestroyPastEvents' job to 'DeleteExpiredPostEvents' and changed its behavior
to only delete posts (and their replies) that have an expired event.
Previously it would also delete expired 'CalendarEvents' but that was messing with our automated
holidays tracking.
Used 'post.reply_ids' to retrieve all the replies to a post, and not only the direct replies.
This helps keep the topic cleaner by removing the whole reply chain.
* DEV: Add backend functionality to enable/disable holidays
This will add two backend endpoints, one to disable holidays and
another to enable holidays.
I also introduced a new `Holiday` service that is responsible for
getting the holidays and attaching a new `disabled` attribute to the
holidays. The `#index` action has been updated to use this new service,
so it will return this new `disabled` attribute.
* DEV: Only add enabled holidays to the calendar
I updated this job so that it will use the new `Holiday` service, which
will return the holidays like before but with a new `disabled` field,
which this job will use to only add enabled holidays to the calendar.
* FEATURE: Allow admins to disable/enable holidays
The main thing I added here is a new component `admin-holiday-list-item`
that is responsible for displaying a holiday, and an enable or disable
button and the corresponding functionality.
Adds two new endpoints available to admins:
* `/admin/discourse-calendar/holiday-regions` - this will return a list of holiday regions (as defined by the Holidays gem)
* `/admin/discourse-calendar/holiday-regions/:id/holidays` - this will return all of the holidays for a given region
The 'holidays-region' custom field used to be visible only to staff
members, but editable by the current user. This meant that the user
could edit the value, but could not see the value after it was set.
This caused the input field from their user preferences page to be
always blank for regular users.
Sam