For these steps:
* In Horizon, create a topic.
* You’ll notice that the topic card has the OP name.
* Make an edit to the OP after the edit grace period.
You would see no username under the topic title. This is because
we were saying that if the topic bump date was after the last post
date, then we should never show any edit details.
However this didn't handle the common case of posting then editing
soon after.
Now in this commit, if the difference is < 1 day, we still show
the same username.
A proper fix would be to know the bumped_at_user then we can tell
if the user is the same as the last poster, but that is more complex
to do.
### What is this change?
When visiting a restricted category or tag where the current user does
not have permission to create a topic, we should still allow the user to
write a new topic under a different category or tag. This is especially
important when using the new topic button from the sidebar.
#### When the user does not have permission, the composer category
defaults to:
1) Subcategory (if SiteSetting.default_subcategory_on_read_only_category
is true and subcategory exists)
2) Default category chooser value of Category... prompting the user to
select a category from the dropdown
This PR is a follow up to #33495 which was reverted previously due to a
couple of issues which are now corrected:
- we no longer set a default category based on
`default_composer_category` (previously was step 2 above)
- category banner text when a user cannot create a topic is now showing
up correctly
- added a title attribute with more info for the disabled category in
the category dropdown in composer
- for staff only tags, when creating a topic from the tag page as a non
staff member we now automatically remove the restricted tag from the
tags field in composer (as the user cannot use this tag)
The Horizon theme was overriding `btn-default` styles for the new topic
button in the sidebar with custom CSS to achieve `btn-primary` styles.
Ideally we should be able to swap out the class and rely on that!
<img width="299" height="258" alt="image"
src="https://github.com/user-attachments/assets/3485fb0b-4714-49ce-9ac4-7e1ac6fb358b"
/>
So here I
1. Convert CreateTopicButton to Glimmer component
2. Add `@btnTypeClass` param - Allows parent components to specify the
button type
(`btn-primary`, `btn-default`, etc.)
3. Separate concerns:
* `@btnClass` handles general class name needs (and existing use)
* `@btnTypeClass` handles core visual style
This upgrade does not include any breaking changes for Discourse
themes/plugins. Two of the three deprecations in Ember 6 (array
prototype extensions, component-template resolution) have already been
polyfilled in Discourse. The third (action helper/modifier) is
polyfilled in this commit.
Performance testing shows a 2-3% improvement in Discourse rendering
time, thanks to upstream performance fixes in the glimmer-vm since the
regressions in the Ember 5.x series.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
This commit modifies the composer buttons along the bottom,
removing the old "Close" button in favour of a distinct "Discard"
and a persistent "X" button.
For **Discard**:
* When there is any user-input content in the composer, clicking this
button will bring up the draft confirmation modal. Users can then
confirm the discard, decide to save their draft, or return to the
editor.
* When there is no user-input content in the composer, clicking this
button will close the composer.
* In this case, we should not prompt users with the draft confirmation
modal.
For the **"X"** button in the top-right of the composer on desktop and
mobile:
* When there is any user-input content in the composer, this should save
the content as a draft and close the composer. We don’t need to bring up
the draft confirmation in this case.
* When there is no user-input content in the composer, this should close
the composer without saving.
Remove the Close button from the composer on desktop.
This commit adds a new `auxclick` event handler to the topic list item,
which calls the same `click` handler.
The `auxclick` event is triggered by auxiliary mouse buttons, such as
the middle mouse button. This fixes an issue where using the middle
mouse button
on a topic card in Horizon anywhere but the topic title would not open
the topic
in a new tab.
Normal topic list click functionality remains unchanged.
c.f.
https://developer.mozilla.org/en-US/docs/Web/API/Element/auxclick_event
- Increases Safari version in `targets.js` to Safari 16.4. This removes
the Safari-15-specific babel transforms for `static` blocks, and the
class-field scope bug
- Moves modern feature detections from a warning banner to our main
'unsupported browser' system
- Adds more informative logging to that 'unsupported browser' system
- Updates Readme with new minimum Safari version
- Removes Horizon-specific browser compat message, since it now matches
core
https://meta.discourse.org/t/358131
Fixes some small inconsistencies between light and dark modes and small
tidyups:
1) hover effect in dark mode is different for button and dropdown
(matches correctly on light mode)
2) split button divider line disappears when hovering button but not
dropdown arrow (we do remove border opacity for regular buttons for
split buttons we should probably keep it)
3) divider line color could be better on dark mode
Most of this feature was already approved in #33495 but it was reverted
temporarily due to users accidentally posting in the wrong category (due
to the default composer category site setting).
This PR removes the default category from composer when the user doesn't
have permission to post in the category (preventing accidental posts in
the wrong category), and also inserts the read-only category into the
category chooser with a read only badge, this way providing some
information to the user when they find it in the dropdown.
The read only category in the drop down can't be selected via clicking
or keyboard selection.
<img width="1336" height="854" alt="Screenshot 2025-08-12 at 6 33 34 PM"
src="https://github.com/user-attachments/assets/a1640f5d-2c73-4c37-8f6a-e284982a8c12"
/>
Before the "theme default" option appeared conditionally, which caused
confusion. For example, it was shown when the theme was using a color
scheme that was not user-selectable. If the scheme was selectable, then
a specific scheme like "Merigold" was preselected. If the theme changed
default schemes, that change was not reflected on the user interface.
Therefore, it would be better to always have the "Theme default" option,
which would have `-1` id. It means that the user's color scheme will
always follow theme defaults.
<img width="400" height="221" alt="Screenshot 2025-08-06 at 10 07 40 am"
src="https://github.com/user-attachments/assets/e3d3588d-1d4a-4e95-9c10-925e48c4a58b"
/>
Before the "theme default" option appeared conditionally, which caused
confusion. For example, it was shown when the theme was using a color
scheme that was not user-selectable. If the scheme was selectable, then
a specific scheme like "Merigold" was preselected. If the theme changed
default schemes, that change was not reflected on the user interface.
Therefore, it would be better to always have the "Theme default" option,
which would have `-1` id. It means that the user's color scheme will
always follow theme defaults.
<img width="400" height="221" alt="Screenshot 2025-08-06 at 10 07 40 am"
src="https://github.com/user-attachments/assets/e3d3588d-1d4a-4e95-9c10-925e48c4a58b"
/>
Because Horizon has a different drawer-composer interaction as default
(#33677) this means that certain floating elements such as the
`fk-d-menu[data-identifier="usercard"]` and the
`chat-message-actions-container` need an adjusted z-index to remain
visible.
Scoped to chat-drawer for safety.
When visiting a restricted category or tag where the current user does
not have permission to create a topic, we should still allow the user to
write a new topic under a different category or tag. This is especially
important when using the **new topic** button from the sidebar.
When clicking the **new topic** button when the user does not have
permission, the composer category defaults to:
1) Subcategory (if
`SiteSetting.default_subcategory_on_read_only_category` is `true` and
subcategory exists)
2) Default site category (if `SiteSetting.default_composer_category` has
a category id value)
3) Default category chooser value of `Category...` prompting the user to
select a category from the dropdown
chapoi
Jordan Vidrine
Martin Brennan
Penar Musaraj
David Battersby
Kris
Ted Johansson
Discourse Translator Bot
Yuriy Kurantandchapoi
Jarek RadoszandDavid Taylor
Derek Rushforth
Krzysztof Kotlarek
