When a calendar has enough entries that it needs to scroll within its container, it can't quite scroll far enough, causing the last row to be slightly cut off.
This fix tweaks the size of the scroll container to ensure the last row is fully visible.
There are three places in this plugin where FullCalendar is set up.
In one of these three the parameter firstDay: 1 is passed, in the other two it's not.
This leads to an inconsistency where the Upcoming Events calendar begins on Sunday, whereas the topic calendars start on Monday.
(See https://meta.discourse.org/t/choose-first-day-of-the-week-on-upcoming-events-calendar/307785/5)
Ideally this would be taken from the users (browser) preferences, but since
[all other places in core](https://github.com/search?q=repo%3Adiscourse%2Fdiscourse%20firstDay&type=code)
hard code it to firstDay: 1 as well, this small patch at least adds some consistency.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
* FEATURE: Add value transformer for showing participants in the event more menu
Plugins can add a value transformer to show participants in the event more menu. This is useful for plugins that want to show participants in the event more menu.
* DEV: Add testing to the more-menu value transformer
lint more-menu-test.gjs
* DEV: lint
* DEV: move to `withPluginApi`
* DEV: removed unnecessary variables from test
* DEV: lint
* Update test/javascripts/integration/components/more-menu-test.gjs
Co-authored-by: Sérgio Saquetim <1108771+megothss@users.noreply.github.com>
* Update assets/javascripts/discourse/components/discourse-post-event/more-menu.gjs
Co-authored-by: Sérgio Saquetim <1108771+megothss@users.noreply.github.com>
* Update assets/javascripts/discourse/pre-initializers/transformers.js
Co-authored-by: Sérgio Saquetim <1108771+megothss@users.noreply.github.com>
* DEV: update test to use mocked users
---------
Co-authored-by: Sérgio Saquetim <1108771+megothss@users.noreply.github.com>
`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.
When we introduced the DiscoursePostEventEvent model and the API service, the recurrent events stopped working as their logic still relied on the old naming convention, upcoming_dates.
This PR changes the addRecurrentEvents logic to work with and to create DiscoursePostEventEvents for each of the upcomingDates, and changes the logic on the Category calendar to also work with the DiscoursePostEventEvent instance instead of the plain object, as well as re-using the API service to fetch the events.
The function passed to onPageChange was also changed to async/await with some minor changes for clarity.
The next ensures `this.htmlDates` has correctly been set and a render is on going which is going to be awaited by the schedule render. Before this fix `querySelectorAll` could return an empty nodes list as the dates were not rendered yet.
Note next shouldn't have this effect here, so it's either a false positive or another side effect we were not expecting.
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>