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.
Allow calendar to disrespect timezones and always display full day for standalone and group events.
Standalone events are saved in specific timezone: https://github.com/discourse/discourse-calendar/blob/main/app/models/calendar_event.rb#L62
However, we don't store information about timezone. It is essential to have that information to calculate date properly. Therefore, a new column was added.
All the preloaded custom fields are stored in `TopicView`'s post_custom_fields property. To prevent N+1 we should use that instead of `post.custom_fields` method.
If a user had two holidays in the same day, the calendar would show
only of them, but the username would be shown twice. This ensures the
calendar shows both holidays and the username only once.
The test is failing because of an incorrect order. I added an order by `created_by`.
Also, I needed to split create_invitess because it is using the same date for `created_at`
```ruby
def create_invitees(attrs)
timestamp = Time.now
attrs.map! do |attr|
{
post_id: self.id, created_at: timestamp, updated_at: timestamp
}.merge(attr)
end
self.invitees.insert_all!(attrs)
end
```
* FIX: correctly destroys standalone calendar events (#66)
Standalone events are mostly created for holidays where we create a calendar event not associated to any post of of the topic, before this change, the loop was exited before collecting the ID of the calendar event to be destroyed.
`find_each` gets the rows in batches, ordered by the primary key, so
ordering clauses are ignored. I assume this is fine, because If it is
not OK to fetch them all from postgres, then it is also not OK to send
them all to the client at once.
When in private event, we don't create invitees, although we know the list of people who can join, send an invite to this list.
Also fixes the total count of users on private events.
David Taylor
Régis Hanol
Shaun
Bianca Nenciu
Joffrey JAFFEUX
Loïc Guitaut
Jarek Radosz
Krzysztof Kotlarek
Roman Rizzi
Alan Guo Xiang Tan
Sam
Vinoth Kannan
Dan Ungureanu
Gerhard Schlager
Daniel Waterworth