This component can be used for any code to be input by the end user.
Example usage:
```gjs
<DOTP @onFill={{this.onFill}} @onChange={{this.onChange}} @slots={{4}} />
```
It supports:
- variable number of slots
- `@onFill` callback, fired when all the slots are filled
- `@onChange` callback, fired on every change
- pasting
- cleaning input data (eg: when pasting 1 2 3 4 5 6 it will be set as
123456)
- look and feel of digicode
A styleguide has been added to try this component:
`/styleguide/atoms/otp`
The UI wasn't "synced" with the backend and showed the wrong error
message when trying to delete a moderator.
In the back-end, only admins can't be deleted.
In the front-end, it was tied to a "staff" check.
Ref - https://meta.discourse.org/t/-/386013
1. Changes translation to a more meaningful: `welcome_banner.search` =>
`welcome_banner.search_placeholder`.
* and passes along translation key, rather then `i18n` helper in
`<SearchMenu>` - to make translation handling more consistent
2. Transitions communities from the **Advanced Search Banner** (ASB)
theme component to the **core welcome banner** (CWB). It handles the
transition in three major steps:
* migrates site settings: task
"themes:advanced_search_banner:migrate_settings_to_welcome_banner"
* migrates translations: task
"themes:advanced_search_banner:migrate_translations_to_welcome_banner"
* excludes ASB from themes using it, enables CWB, disables ASB: task
"themes:advanced_search_banner:exclude_and_disable"
### Settings migration
1. Happy path
<img width="1029" height="192" alt="Screenshot 2025-10-29 at 12 40 51"
src="https://github.com/user-attachments/assets/5d29ef48-ce60-4222-b32a-217390967b8d"
/>
### Translations migration
1. Migrates overridden and default texts
<img width="1062" height="291" alt="Screenshot 2025-10-29 at 12 44 26"
src="https://github.com/user-attachments/assets/c43d51a4-59f8-4751-8abb-ae8824a7100f"
/>
### Exclude ASB, enable CWB, disable ASB
2. When ASB is not included in any of themes, all migrations are
skipped, except for disabling ASB
<img width="807" height="458" alt="Screenshot 2025-10-30 at 11 48 43"
src="https://github.com/user-attachments/assets/34e7bd5f-b334-4833-89a1-00d02faac23b"
/>
This PR introduces part one of the "Upcoming changes" interface for
Discourse admins.
The upcoming changes feature is an enhancement around our existing
site-setting based feature flagging and experiments system. With some
light metadata, we can give admins a much better overview of the current
work we are doing, with ways for them to opt-out in early stages and
opt-in to things that we haven’t yet turned on by default for them.
This system, along with encouraging a more liberal use of site setting
flags for features, experiments, and refactors in the app, should
minimise the problem of breakages and disruptions for all Discourse
users. It is also our intent with this system for it to be easier for
designers to add and remove these changes.
Finally, it also gives us a kind of running changelog that we can use to
communicate with site owners before releases and “What’s new?” updates.
### FOR REVIEWERS
This initial PR is gated behind a hidden `enable_upcoming_changes` site
setting, because there is still more work to do before we reveal this to
admins.
To test the UI, you can add this metadata under any boolean-based site
setting, though upcoming change settings will specifically be hidden:
```
upcoming_change:
status: "alpha" (see UpcomingChanges.statuses.keys)
impact: "feature,staff" (feature|other for the first part, staff|admins|moderators|all_members|developers for the second part)
learn_more_url: "https://some.url"
```
To test the images, add an image under `public/images/upcoming_changes`
with the file name as `SITE_SETTING_NAME.png`
### Interface
Admins can see the following in the interface for upcoming changes:
* The status of the change. Changes can progress along these statuses:
* Pre-Alpha
* Alpha
* Beta
* Stable
* Permanent
* The impact of the change. This is split into Type and Role. Type can
be "Feature" or "Other" for now. Changes may affect the following roles:
* Admins
* Moderators
* Staff
* All members
* The plugin that is making the change
* The groups that are opted-in to the change. Admins can control these
groups for a gradual rollout. If a change is enabled, it is limited to
these groups.
* In some cases, an image related to the change, behind the "Preview"
link
* A link to learn more about the change
Admins can filter the changes by name, description, plugin, status,
impact type, and whether the change is enabled.
### Promotion system
For our hosted customers, we intend to have a status-based
auto-promotion system as changes progress.
For all sites, once a change reaches the Stable status, if an admin
opts-out of that change it will generate an admin problem message that
will be shown on the dashboard.
For self-hosted Discourse admins, changes will only be forcibly enabled
when they reach the Permanent state.
### Notification system
A notification system for upcoming changes so admins can stay informed
will be added in a followup PR.
---------
Co-authored-by: awesomerobot <kris.aubuchon@discourse.org>
We have a setting and a user option called watched_precedence_over_muted
. This is supposed to allow members to see/be notified of topics in
categories they are watching even if those topics also include a tag the
user has muted, or vice-versa if they disable this option.
However, this setting and user option combination doesn't follow our
existing default_ user preference site setting system, where admins can
set a default for all users, but users can change the preference for
themselves. This is leading to a bug in the topic feed logic.
If the site setting watched_precedence_over_muted is set to true, and
the user preference is set to false, the user preference is essentially
ignored. This will lead to users seeing topics with muted tags inside a
watched category feed.
This commit converts watched_precedence_over_muted to a proper default
user preference site setting, which admins can set for all users at
once, then users can override individually.
Modernizes the user notifications controller/template to native Ember
patterns and corrects infinite scrolling behavior.
* Convert legacy computed properties to getters; rely on model.content
and model.loading
* Fix memory leak build notification items with
curryComponent(RelativeDate) instead of `<template>`
* Remove listContainerClassNames; compose classes in template with
concatClass and avatar toggle
* Update markRead to set read on model.content; simplify updateFilter
* Adjust unit tests to use ResultSet and updated access patterns
* Add system spec validating progressive loading on scroll (infinite
scrolling)
We recently hid multiple very technical site settings related to image quality. In this PR we add a unified image_quality setting.
Power users can still configure the individual settings (now defaulting to 0) and they will take precedence.
Refactors ResultSet handling to use tracked arrays and native array
APIs, removing ArrayProxy semantics.
- Access items via .content across controllers, routes, components, and
templates (conditionals, #each, find, map)
- Replace Ember array mutators on ResultSets:
* removeObject → removeValueFromArray
* addObjects → addUniqueValuesToArray
* setObjects → content.splice(...)
* unshiftObjects → content.unshift(...)
- Use modern native APIs on ResultSets:
* toSorted for non-mutating sort
* .at(-1) for last element access
- Update adapter/util logic to iterate results.content (e.g., theme
afterFindAll, default theme lookup)
- Initialize tracked collections where needed (e.g., themes list via
TrackedArray) to maintain reactivity
Exclusively on Mac Safari, dragging and dropping an image from another
window to the composer is processing the image twice, one as an HTML
paste, another as an upload.
This `drop` handler is intended to delegate the processing so Uppy's
`DropTarget` can handle the upload.
This is very hard to add a test for, unfortunately.
This was required in older versions of Ember. But now, bare template
tags can access `this.`. This commit was created by upgrading lint-configs, and then running
`pnpm lint:js:fix && pnpm lint:prettier:fix`
Rule development: https://github.com/discourse/lint-configs/pull/154
Ember now has native support for route components, so we don't need the wrapper. This commit was generated automatically using `pnpm lint:js:fix && pnpm lint:prettier:fix`.
Replaces resolver-based template lookups with simple components.
Added a value transformer for plugins to modify the components if
needed. This does not appear to be a common or documented pattern, so
this change does not include backwards-compatibility for plugins which
may have been adding their own messages in the `templates` directory
The `toggleFastEdit` has an async function in the middle of it and we
were using a global post object which can take time and things can
happen to our post object (most likely be nulled) which can lead to
unexpected behavior. The edited post is now saved at the beginning of
the toggling preventing this issue.
There are already specs for this behavior, but this specific case is
hard to test.
Since iOS 26 it seems the callout from iOS is following this heuristic:
position the callout where there's the most space. When it used to
favour positioning it above the selection.
This commit removes various hacks and replace them by using the new
modifier: `{{preventScrollOnFocus}}`.
Applied this fix to:
- emoji picker modal
- fast edit modal
- add post notice
We might have other modals to fix in the future. Generally the fix
should be the same, order matters though, and the modifier has to be
before any `{{autoFocus}}` or similar behavior.
Following 37648149c4, it became impossible
to resolve some deprecations with plugin admin templates. This commit
fixes that problem, and also resolves the deprecation for the
chat-integration plugin.
Allows closing of lightbox by tapping outside of the image on mobile,
while retaining the toggle UI functionality when single tapping an image
on mobile lightbox.
This change also adds a useful system helper for `tap_screen_at(x, y)`
when working with mobile specs. To use it just set `mobile: true` on the
test or surrounding context block.
Extracts the help resources section from the reviewable item template
into a separate `ReviewableHelpResources` component.
The help resources are now conditionally rendered based on a `@showHelp`
parameter, allowing them to be shown only when viewing a single
reviewable item (review/show route) and hidden in the queue list view.
Also removes unused "Copy Link" and "View Source" buttons from the
moderator actions section, and adjusts the claimed topic section to only
render when claim functionality is enabled.
This commit also updates the rejected email logs tab to show the details
of the rejected email when the error message is clicked instead of the
subject.
This commit handles an issue some customers are having with
the media optimization worker when uploading images.
1. Sometimes the `new Worker()` call hangs indefinitely. To handle
this, we can check if it installed within 3 seconds, and if not
we fail and reject the promise.
2. We also add a `try...catch` around the `new Worker()` call to
catch any CSP issues or exceptions that may occur during worker
instantiation.
David Battersby
Joffrey JAFFEUX
Régis Hanol
Isaac Janzen
Yuriy Kurant
Sam
Martin Brennanandawesomerobot
dependabot[bot]anddependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sérgio Saquetim
Ted Johansson
Gary PendergastandKrzysztof Kotlarek
Renato Atilio
Juan David Martínez Cubillos
Alan Guo Xiang Tan
David Taylor
Jarek Radosz
chapoi
Yan