And forward them in "discourse id" so we can pre-fill the email field on
the signup page.
Also added `PreloadStore.has("key")` so we can quickly check a key is
present in the "preload store" without actually retrieving it.
Internal ref - t/154880
We're moving the `_destroy` logic for localizations to the backend. The
`updateCategory` API should look something like this:
```
# Scenario: edit italian, add japanese, delete spanish (just exclude from list)
# PUT /categories/4
{
"name": "General",
"slug": "general",
"color": "25AAE2",
# ...
"category_localizations": [
{
"id": 102
"locale": "it",
"name": "generale",
"description": "Si prega di creare qui argomenti che non rientrano in altre categorie esistenti."
}
{
"locale": "ja",
"name": "一般",
"description": "他の既存のカテゴリに該当しないトピックをここに作成してください。"
}
]
}
```
Currently visible on
<https://meta.discourse.org/tag/chinese-translation> for `Developers`,
we see an N+1 when loading /latest or any other topic lists due to
`topic_localizations.find_by` which will hit the db.
This PR switches us to use `find` instead as the associations have been
loaded already, and includes a test.
In the past we have always relied on automatically opening the composer
and auto loading the existing draft when visiting a topic that has a
draft post reply. This is fine to auto load the draft, but when the
composer is closed and reopened on the same page then we have an issue.
The result is that the draft is then deleted because the draft key is
set and the composer body is blank, since it has never been populated
when clicking the reply to post button.
To solve this we can check for existing drafts when clicking the reply
to post button, then load the draft into the composer.
_The challenging part of this change is that we have a number of tests
that were relying on a false positive. Hence in the specs I have
switched some tests to use a fixture that does not have drafts and in
some cases kept the same fixture but mocked the response as having no
drafts returned._
This changes allows the `/my/` prefix redirect to work when the name
param contains uppercase letters.
#### For example:
`/my/messages/group/MyGroup` now redirects to
`/u/username/messages/group/MyGroup`
We want to add an option for admins to carry out the operation silently
when they are updating the category for the selected topics. When the
“Perform this action silently” checkbox has been checked, the
`:notify_category_change sidekiq` job should not be enqueued.
When we are tracking requests in the `Middleware::RequestTracker`, we
have historically added an `X-Discourse-TrackView` response header
for implicitly tracked requests HTML requests, and also explicitly
tracked page view requests when navigating the Ember app.
Within the past couple of years, we introduced the concept of
Browser Page Views (BPVs), which are recorded when requests are made
via AJAX when navigating the app with Ember, and also piggybacked
onto the first MessageBus request on page load. The former is known
as an explicitly tracked request, the latter is a deferred tracked request.
The explicitly tracked browser page views also add the `X-Discourse-TrackView`
header to the response, so it is hard to differentiate which requests are purely
browser page view requests in the logs.
This commit adds a new response header, `X-Discourse-BrowserPageView`,
that acts in a similar way to the existing `X-Discourse-TrackView`
header, but is specifically for requests that are tracked as BPVs (both explicit
and deferred).
**Description**
Changes introduced previously on this
[PR](https://github.com/discourse/discourse/pull/33055) are reverted in
order to improve code and add flexibility to the user notifications
emails pipeline
It's possible for different source files to generate the same compiled
output (e.g. if only a comment changes), so we should include the
sourcemap content when calculating a digest.
Extracted from #33103
1. Use separate caches for plugins and core
2. Don't load plugins in non-plugin jobs
3. Propagate LOAD_PLUGINS to all steps
4. Check annotations of plugin models
5. Update outdated annotations
The Content section in particular has four tabs which are all site setting pages. It does not have one under /settings, like other sections.
The admin search functionality will automatically use /settings for multi-tabbed sections. This results in a 404 when searching for Content site settings.
This PR adds a front-end redirect (replaceWith) for /content/settings to fix the immediate issue.
This is the first in a series of PRs aimed at organizing the guardians and their tests a bit better to make them more discoverable and reduce the amount of "pinballing" around looking for the relevant methods.
There is no change to any functionality, and the tests have been copied over as-is, except where fixture variables needed renaming to fit in the new spec file.
Uses the following shortcuts for the editor heading toolbar:
* Ctrl + Alt + 1: Heading 1
* Ctrl + Alt + 2: Heading 2
* Ctrl + Alt + 3: Heading 3
* Ctrl + Alt + 4: Heading 4
* Ctrl + Alt + 0: Paragraph
On macOS, substitute `Ctrl` with `Cmd` and `Alt` with `Option`.
Also adds composer shortcuts to keyboard shortcut help modal (?)
This commit make it easier for staff to see if a profile is silenced by
aligning it with how suspended notices are shown.
- The number of times a profile has been silenced is shown in the staff
counters banner at the top of the public user profiles.
- Clicking on the silenced note in the staff counters banner goes to a
filtered view of the staff action logs for the user and the silenced
action.
- The profile indicates if a user is silenced and shows the date they
are silenced until. This looks exactly the same as how it currently
displays for suspended users, with the added info of the date. This is
also displayed on the user card, the same as suspended notices currently
are.
## Screenshots
We don't really want to encourage HTML in the RTE,
and BBCode is pretty technical too, so this commit
simplifies the copy of the placeholder for the RTE
The date control here doesn't have a label:
<img width="608" height="170" alt="image"
src="https://github.com/user-attachments/assets/5517d5d2-f64b-4cf9-aad0-f14152a85ffd"
/>
This adds the label, and also removes the headerAriaLabel from the
before/after dropdown — the dropdown has a label applied elsewhere so
this wasn't doing anything (tested with NVDA)
Adding `alt=""` to tell screenreaders to skip these, we don't reliably
have alt content available for onebox images and they tend to be
decorative, so better to omit.
<img width="738" height="151" alt="learn.microsoft.com onebox with the
link whats new in C# 11, there's a purple C# badge to the left of the
link"
src="https://github.com/user-attachments/assets/15bdc830-683f-4c69-a11b-9d54c66fa627"
/>
We already do this in some oneboxes, so this covers some more cases
including the generic.
