This commit replaces several instances of `.uniq`, `.uniqBy`, and related
array deduplication methods with a new utility function
`uniqueItemsFromArray`. This change ensures proper deduplication logic
across the codebase while addressing the deprecation issues.
**Main Changes:**
* Created new utility function `uniqueItemsFromArray`: Located in a new
file, `array-tools.js`, this function provides a reusable and
configurable alternative for deduplication.
* Replaced old methods: Updated multiple files to use the new utility
function instead of deprecated or custom implementations for
deduplication.
* Replaced manual deduplication: Replace uses of `[...new Set(array)]`
to standardize the deduplication logic across the codebase.
* Added unit tests: Introduced thorough test coverage
(`array-tools-test.js`) to validate functionality and edge cases for the
utility function.
* Updated deprecation workflow: Added logging for deprecated uniq and
uniqBy methods to the `deprecation-workflow.js`.
This change is primarily focused on code quality improvements, ensuring
future-proof deduplication, and maintaining alignment with deprecation
guidelines.
We can't enable `Rails/WhereNot` lint/autofix, because it would break
code that uses mini_sql instead of AR (which rubocop, and tbh also we,
can't easily differentiate)
Those are safe because they either:
* are executed in AR model scope definitions
* are clearly chained starting from a AR model
* are less-clearly chained, but still can be traced to a AR model/scope
---------
Co-authored-by: Loïc Guitaut <loic@discourse.org>
Covers default reactions,
`discourse_reactions_experimental_allow_any_emoji`,
`discourse_reactions_enabled_reactions`, and interaction with the
`emoji_deny_list` setting from core.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Replaces usages of `mapBy` across the codebase with JavaScript's native
`.map`. This resolves deprecation warnings related to Ember's array
extensions and ensures compatibility with future Ember versions.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
For historical reasons, Discourse has a customized Ember resolver. This
had a much more fuzzy implementation of 'normalize' and 'findTemplate'
functions. This leniency meant that our file naming hasn't always
matched Ember conventions.
Standardizing our naming will make things easier to understand for
developers, and will make adoption of newer ecosystem tooling easier
(e.g. route-based bundle splitting in Embroider/vite)
This commit adds deprecations to the resolver when this leniency is
used, and uses a fully bespoke codemod to rename all of the affected
routes/controllers/templates in the Discourse core repository.
Backwards-compatibility is maintained for anyone looking up the old
names in the resolver.
This commit introduces deprecation warnings for accessing Site.mobileView or
Site.desktopView during application initialization to prevent
layout-related errors and improve code reliability.
The changes include:
* Added deprecation warnings for Site.mobileView and Site.desktopView
access during the initialization phase.
* Updated multiple plugins and components to avoid these deprecated
calls during startup.
* Refactored initialization logic across discourse-ai, discourse-chat,
discourse-calendar, discourse-reactions, discourse-assign,
discourse-subscriptions, and discourse-user-notes plugins
* Improved error prevention by discouraging early access to
view-dependent properties before the application is fully initialized
* Enhanced code maintainability by establishing clearer boundaries
between initialization and runtime phases
This deprecation helps prevent subtle bugs that can occur when
components try to determine the view type before the application context
is properly established, leading to more robust plugin initialization
patterns.
This PR allows user to choose any emoji in reaction, like the old retort plugin.
* Add a `discourse_reactions_experimental_allow_any_emoji` option, if enabled, will add a button of EmojiPicker in the ReactionsPicker
* When the EmojiPicker is shown, will prevent ReactionsPicker from collapse when clicking at outside(necessary on mobile device) / moving mouse outside of ReactionsPicker
* This is considered a disabled by default experimental feature for now, admins can enable
at their own discretion, as there is not currently a way to limit which reactions can be used here
This pull request improves how user properties are managed and accessed
in post-related components and models. Notable improvements include:
- The `Post` model now provides a cached `user` property, ensuring a
consistent and up-to-date user object using relevant post fields,
instead of relying on `user` being set directly or via the `PostStream`.
- Components such as `PostAvatar` and `PostMetaDataPosterName` now
consistently reference the `user` property, improving reliability and
reducing the risk of missing or inconsistent user data.
- User context is more accurately passed to value transformers and
plugin outlets, ensuring that avatar and name rendering logic always
receives the correct user information.
- The `GroupPostSerializer` now includes the `user_id` attribute,
improving API consistency.
- Test cases have been updated to work with the new user property
approach, removing direct creation of user objects on posts and instead
relying on post fields.
- The `discourse-reactions` plugin was updated to align with the new
user property logic, ensuring reaction-related user data is accessed
consistently.
Overall, these changes improve data integrity, reduce the risk of
rendering errors due to user data inconsistencies, and streamline how
user information is passed through Discourse post-related features.
Since the introduction of dedicated login and signup pages (as opposed
to modals), we've been seeing reports of issues where visitors aren't
redirected back to the "page" they were at when they initiated the
_authentication_ process.
Since we have a bazillion of ways a user might authenticate
(credentials, social logins, SSO, passkeys, discourse connect, etc...),
it's really hard to know what a change will impact.
The goal of this PR is to "simplify" the way we handle this "redirection
back to origin" by leveraging the use of a single `destination_url`
cookie set on the client-side.
The changes remove scattered cookie-setting code and consolidate the redirection logic to ensure users are properly redirected back to their original page after authentication.
- Centralized destination URL cookie management in routes and authentication flows
- Removed manual cookie setting from various components in favor of automatic handling
- Updated test scenarios to properly test the new redirection behavior
Sérgio Saquetim
Jarek Radosz
Martin BrennanandJarek Radosz
David Taylor
Discourse Translator Bot
fokx
Jordan Vidrine
Régis Hanol
