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>
Now that `ServerSession` can store arbitrary data, we can move some more
data into it.
This patch moves some data related to authentication into it, as
sometimes that kind of data can be pretty big.
Context: The `btn` mixin is used for every functional button, but this
includes button elements that are not, or should not be, styled like our
default or primary buttons.
To change how this works this commit:
* stripped down the mixin to the bare essentials, mainly limiting to the
properties that use variables.
* moved most things into the `btn` class
* moved some things into specific descriptive classes (default, danger,
success) such as border-radius
Example of button that does not need a border-radius and would benefit
from this:
<img width="464" height="184" alt="CleanShot 2025-09-19 at 12 56 04@2x"
src="https://github.com/user-attachments/assets/e908b2cf-971f-4c1f-aade-7492bad2f89c"
/>
* Deprecated…
* FlatButton component
* btn-active: we should use the proper pseudoclass :active or a –-active
modifier in code if we need it
* btn-text: every button by default is a btn-text. We already have a
class to indicate when it isn’t (no-text)
* fixed btn-link property to make DButton component behave like an
inline link (no padding, link-styling)
* Since I moved styling from .btn, ths means every button now needs a
specific declaration. So I’ve added btn-default where necessary.
* Fixed btn-flat hover effect: The difference between btn-flat and
btn-transparent was getting very ambiguous. I’ve fixed the hover effect
for btn-flat so that the distinction is:
<img width="1094" height="408" alt="image"
src="https://github.com/user-attachments/assets/addf56a9-1f61-463d-abd9-5028a3b88fad"
/>
* Changed the custom icon colour from header icons so it follows the
normal btn-flat styling, the way the sidebar icon already was doing.
(Consistency)
**Other small button-related change along the way**
What | BC | AC |
|----| ----|--------|
Inconsistent save/cancel colours | <img width="1720" height="1084"
alt="CleanShot 2025-09-19 at 15 31 40@2x"
src="https://github.com/user-attachments/assets/227289c3-6ded-4633-868d-6e33c32d83c3"
/> | <img width="1720" height="1084" alt="CleanShot 2025-09-19 at 15 30
56@2x"
src="https://github.com/user-attachments/assets/b23f96c9-04f3-40ea-9fba-2be59eae8e64"
/> |
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
Now that `ServerSession` can store arbitrary data, we can move some more
data into it.
This PR moves some data related to authentication into it, as sometimes
that kind of data can be pretty big.
was showing up inconditionnaly even if you didn't have the permissions
to edit other people's comments.
This was only a UX issue as the server is doing the correct check.
The issue was the `hasPermission` method which wasn't a getter so it
wasn't checked for all the instances of the post comments but rather
once.
Also added some acceptance tests to ensure we don't regress.
Internal ref - t/163347
Replaces deprecated usage of the Ember's native array extension `.any()`
function with `.some()` across several JavaScript files in the project.
This is a purely refactoring change intended to modernize the codebase
to follow current JavaScript standards.
**Main Changes:**
* Replaced .any() with .some() for array handling in 25 instances across
various files.
* Updated deprecation workflow to handle the any() and related
deprecations explicitly.
We are not sure of the reasons but there are multiple similar (yet not
exactly the same) reports of resizing issues with calendar causing this
exact same `width: 0` state we have experienced.
When fetching voters from the `/polls/voters.json` API endpoint, each
page after the first has an extra voter (the last one from the previous
page). This causes duplicate voters to be returned if loading multiple
pages. This PR fixes the off-by-one error that causes this. (This fix
has initially been proposed by Rob Mackenzie.)
The PR also fixes an issue that could cause non-deterministic ordering
of results from that API; however, I have not been able to craft a test
to reproduce the issue, so the fix is theoretical.
Reported here:
https://meta.discourse.org/t/polls-voters-json-returning-duplicate-users-across-paged-requests/376636
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 Ember's deprecated `filterBy` with the native JavaScript method
`filter`. This aligns with modern JavaScript practices, improves code
clarity, and prepares for future deprecations.
Changes involve various components, controllers, and models across the
codebase.
Replace individual per-locale queries with a single query that
calculates completion progress for all locales at once.
This commit also removes methods off the `base_candidate` (used for
Categories and Topics as well) which are not used any more, as the
progress dashboard only shows progress for posts.
t/162846/4
---------
Co-authored-by: Nat <natalie.tay@discourse.org>
This Pull Request introduces changes that replace the use of .sortBy
with .sort combined with compare from @ember/utils. This update aims to
modernize and standardize sorting operations throughout the codebase.
**Main Changes:**
* Replaced .sortBy with .sort and compare in various components,
controllers, and services to improve sorting practices.
* Updated sorting logic to handle optional chaining (?.) for increased
robustness.
* Adjusted sorting logic, including reversing, in some cases for more
clarity and correctness.
* Added a new deprecation workflow entry to handle sortBy deprecation
logs (discourse.native-array-extensions.sortBy).
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>
Refactor all instances of `reject` and `rejectBy` across the codebase to
use the native `filter` method paired with appropriate logic. Updates
include changes in models, components, and services.
This ensures compatibility with modern JavaScript standards and reduces
reliance on deprecated array extension methods.
- Adds a transformer to allow subtitle addition to the user notes form
- Adds plugin outlet to allow customization of each note in the modal
form
- Rename a handler placement to place the avatar under the correct
outlet
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.
Jarek RadoszandLoïc Guitaut
Joffrey JAFFEUX
chapoiandMartin Brennan
Natalie Tay
Roman Rizzi
Kris
Yuriy Kurant
Régis Hanol
Discourse Translator Bot
David Taylor
Sérgio Saquetim
Charles Lechasseur
Rafael dos Santos SilvaandNat
Amanda Alves Branquinho