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.
This ensures that the patch is reloaded automatically during development, and should stop the random `NoMethodError (undefined method `group_timezones' for #<Post>` errors in development
Custom fields are create in the site settings of the event plugin. Once at least one custom field is created, a new form will appear in each event UI. These custom fields are passed when DIscourseEvent triggers of the plugin are called, allowing you to pass custom data of the even to other plugins.