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 were not applying the timezone for the list of upcoming events
- we would return the first event + the upcoming events, we now get all the events generate by RRule if this is a recurring event, and if it's not a recurring event we just return the event, instead of doing a dance where we would remove the first event from RRule but prepend the initial event on the frontend
This defines a feature where event creators can opt for an associated chat channel
creation.
This is a staff only feature for now.
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Playwright will not accept this kind of specs as it's not reliable. You would potentially get this error:
```
Playwright::Error:
Element is not attached to the DOM
Call log:
- attempting click action
- - waiting for element to be visible, enabled and stable
```
What happens is that the ".nav-item_latest" would be present before navigation, and playwright would find it just before the page has loaded, the click though might happen right after page transition and the initial element wouldn't be attached to the dom anymore.
* DEV: Allow the 'UpcomingEventsCalendar' Component to be used outside of the 'PostEventUpcomingEventsIndexRoute' route
* add system test to upcoming events
* improved addRecurrentEvents function
* fixed flaky test
`DiscourseCalendar::CreateHolidayEvents` periodically deletes holiday
events to recreate updated ones. If one of the events belonged to a user
that has been destroyed and if `enable_user_status` was enabled, the
`after_destroy` hook would raise an exception.
There was two bugs:
- naming of properties were incorrect s/is_private/isPrivate and s/is_public/isPublic
- a previous refactoring has used `=` for setter when it's an `EmberObject` and `set` should be used
This commit also adds a spec and page objects to ensure this modal is working as expected.
This PR restyles the current events post UI:
Minimize size of invitee avatars
move CTA buttons to bottom
remove invitee header & show more button (show more is in ellipses drop down)
restyle border
restyle month & date size & spacing
increase font size for title
add "0 going" placeholder to prevent jumpiness when invitees are rendered
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
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.
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>
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
When a user changes their holiday region in their profile, we will automatically compute upcoming (6 months) holidays for their new regions. If the events are similar between the two regions, we automatically fix the region. But when they're drastically different, we just leaves the old holiday events be...
It's a somewhat rare event but is annoying enough that it warranted a proper fix.
This ensures we removes any "pre-loaded" holiday events that aren't in the regions the users have selected. That way, no more "fanthom" holidays from the previous region.
Internal ref - t/64785
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.
Adds a before parameter to the events endpoint and uses it through a upcomingDays parameter to the upcoming events list component – which can be used when adding it to the right sidebar blocks theme component.