This babel plugin is intended to supress the deprecation warnings
from building plugins, however, discourse-plugins does not actually
consume this plugin at all. Currently this happens to work due to
how the babel worker processes are shared and the timing/ordering
of the build, but it will stop working with the embroider build.
This commit extracts the plugin the a shared package so that it
can be properly consumed by discourse-plugins as well as core.
Performing a `Delete User`/`Delete and Block User` reviewable actions for a
queued post reviewable from the `review.show` route results in an error
popup even if the action completes successfully.
This happens because unlike other reviewable types, a user delete action
on a queued post reviewable results in the deletion of the reviewable
itself. A subsequent attempt to reload the reviewable record results in
404. The deletion happens as part of the call to `UserDestroyer` which
includes a step for destroying reviewables created by the user being
destroyed. At the root of this is the creator of the queued post
being set as the creator of the reviewable as instead of the system
user.
This change assigns the creator of the reviewable to the system user and
uses the more approapriate `target_created_by` column for the creator of the
post being queued.
- explicitly enables the jquery-integration. This was previously enabled by default, so no change in behavior for us
- enable template-only-glimmer-components. In core, we don't have any component templates under `templates/components`, so this flag has no effect. A shim, with associated tests, is introduced to preserve the old template-only 'classic component' behavior for themes and plugins.
We'd like to get this deprecation unsilenced before the 3.1 release so that theme/plugin developers see the messages and can make the necessary changes during the 3.2 release cycle. To avoid the remaining legacy core modals from creating overwhelming noise in the logs, deprecation messages for them are skipped.
When the app boots, Ember fires a `routeWillChange` event. This was causing us to set the `_trackView` flag in our ajax library, which would cause the next request to have the `Discourse-Track-View` header, despite not being relevant to the page view. Depending on the plugins/themes installed, this could lead to 'double counting' of pageviews. (because the initial HTML request is also counted as a page view)
This commit updates the the logic to ignore the first transition (by checking `transition.from`), and also introduces an acceptance test for the behaviour.
Co-authored-by: Régis Hanol <regis@hanol.fr>
Currently the dominant color attribute is only set for post images (not chat).
As a result, clicking lightbox images in chat will load the image within lightbox but also shows a JS error.
This change ensures that the dominant color is set before attempting to update the site theme color.
What does this change do?
This commit removes the experimental label for a bunch of APIs that have
been used in production for quite some time at Discourse so that the
APIs can be released as part of Discourse 3.1
To decide to use flip behavior select-kit will check if it's located inside a modal as a modal will scroll if overflown, however, when locating the select-kit element in the footer or header this is not the case. This commit will deactivate `flip` modifier only when used inside modal body.
Fixes an issue where this.selector value was not binded at the time of adding the event listener. Therefore when someone opens a chat channel that has images, the value of selector would change. I also moved the callback to a named function (rather than the default handleEvent).
The Problem
Clicking on a large image opens lightbox, however the new lightbox currently waits for the first image to finish loading before it finishes loading the lightbox UI correctly (ie. background color). This makes the visual experience feel broken.
Because open() is waiting for the image to load, it doesn't trigger the onOpen callback, which appends a .has-lightbox class to the html tag. The lightbox background color requires that css class to be set for the styles to be applied correctly.
The Solution
This PR prevents blocking when loading loading the first image (image that was clicked) within the lightbox, and therefore allows the css class to be appended to the html tag correctly and as a result fixing the styling issues.
The #setCurrentItem function is async and awaits the loading of preloadItemImages already, so the image will load correctly when complete despite the rest of the UI loading in advance.
The primary motivation is to simplify `eagerLoadRawTemplateModules` which curently introspects the module dependencies (the `imports` at runtime). This is no longer supported in Embroider as the AMD shims do not have any dependencies (since it's managed internally with webpack).
Prior to this commit the `setSiteThemeColor` could mistakenly receive a color with a leading `#` which would cause an invalid color to be send to `postRNWebviewMessage` and would eventually cause a crash if we try to interpolate between this color and another.
Using the lastViewedTopicId indiscriminately can cause strange scrolling behavior when navigating to a **different** topic list after viewing a topic. We only want to refocus the topic when going 'back' to the same topic list which originally triggered the navigation.
Previously we had three query parameters to control which tests would be run. The default was to run all core/plugin tests together, which would almost always lead to errors and does not match the way we run tests in CI.
This commit removes the three old parameters (skip_core, skip_plugins and single_plugin), and introduces a new 'target' parameter. This can have a value of 'core', 'plugins', 'all', or a specific plugin name. The default is 'core'. Attempting to use the old parameters will raise an error.
Previously we were implementing scroll reset/memorization on a per-page basis. Many of these approaches relied on the `didInsertElement` hook, which is no longer appropriate since Discourse changed to use the 'loading slider' strategy for page transitions.
This commit rips out all of our custom scroll resetting/memorizing, and implements those things in a generic service. There are two features:
1. After every route transition, scroll to the top of the page
2. When using browser back/forward buttons, restore the last known scroll position for those routes
To opt-out of the behaviour, individual routes can add a scrollOnTransition boolean to their RouteInfo metadata using Ember's `buildRouteInfoMetadata` hook.
The new lightbox was missing the tracked property for items when it was launched earlier as experimental feature flag.
This PR should fix issues experienced when the user clicks between multiple galleries causing the carousel images not to be updated as they were previously not tracked.
Why this change?
Prior to this change, dismissing unreads posts did not publish the
changes across clients for the same user. As a result, users can end up
seeing an unread count being present but saw no topics being loaded when
visiting the `/unread` route.
Why this change?
Group mention notifications are currently placed in the "Others" tab
of the user menu which is odd considering that mentioned notifications
are in the reply tab. This commit changes it such that group mention
notifications are displayed in the reply tab as well.
