When creating a DM to a group in chat, we show
a count of users for that group if the number of
users exceeds SiteSetting.chat_max_direct_message_users.
However, we were also counting bot users here, we should
only be counting human users, this led to confusion because
the chat group count was different from the one on
e.g. /g/:group_name
When a user typed `:emoji` using the autocomplete on the rich editor,
but then used the "more" option to open the emoji picker and picked an
emoji from there, we were leaving the dangling `:emoji` there and just
added the emoji node after it.
We now check if there's a partial emoji exactly at the caret position,
and replace it too.
When copying images from cooked, we have a `data-base62-sha1` attribute
instead of a `data-orig-src` that we were expecting.
This PR fixes it and adds a system test.
At the moment, every call to `Category.subcategories` causes an
iteration through every single category. For sites with thousands of
categories, this is incredibly expensive, and makes things like the
category dropdown & sidebar rendering very slow.
To improve things, we can create a map of parent_category => [child
categories] in a single iteration, cache it, and then use that when
finding subcategories.
The `@computed` decorator ensures that this cache will be recalculated
whenever the list of categories changes (e.g. when sideloading new
categories in the experimental lazy-loaded-categories mode)
When opening the sidebar on a site with thousands of categories,
`getSubCategoryIds` is called repeatedly and the nested loops burn a lot
of CPU time.
The `Category.descendants` logic is similar in efficiency, but crucially
it is cached so it only needs to be calculated once per category. So
this change should make a big difference to sidebar performance on sites
with lots of categories.
We already support `/apple-app-site-association` at the root. Apple also
accepts `.well-known/apple-app-site-association` as a valid path so this
adds that as well, just in case.
Previously, I was getting this error in the JS console:
```
livereload.js:2232 Mixed Content: The page at 'https://DOMAIN/' was
loaded over HTTPS, but attempted to connect to the insecure WebSocket
endpoint 'ws://DOMAIN:443/_lr/livereload'. This request has been blocked;
this endpoint must be available over WSS.
````
Adding a `https: true` option seems to fix the problem when running the
local server over an https proxy. (It'll be marked as `false` when the
protocol isn't https.)
This isn't just a warning, opening `/tests` is delayed about 10-20
seconds.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
The service worker isn't served via normal asset paths or the CDN.
Instead, the ERB was being compiled by sprockets, fished out of the
`public/` directory by the static_controller, and then the
sprockets-specific stuff like `sourceMappingUrl` was being removed.
Instead, we can put the ERB under `views/static/`, and have it evaluate
at runtime. There are only a couple of super-cheap interpolations, plus
the route is cached in nginx, so there is no performance concern.
This takes us one step closer to removing sprockets.
There are a number of minor changes in this commit :
1. Combine the "Themes" and "Components" links in the admin sidebar into
a single tab labelled "Themes and components"
2. The combined tab links to the `/admin/config/customize/themes` page
(titled as "Themes and components")
3. Add a new "Components" tab to the "Themes and components" page.
There's already an existing "Themes" tab
4. Add a "back to" link at the top of individual theme/component page to
navigate back to the respective tab in the "Themes and components" page
5. Remove the themes/components list/sidebar that currently serves for
navigating between themes/components
6. Remove the header in the theme/component page
Changes 4–6 apply only if the admin sidebar is enabled; they have no
effect otherwise.
Internal topic: t/146006.
Follow up to: https://github.com/discourse/discourse/pull/31670
This deletes the mixin.
Did a search across our repos with `/mixins\/user-field/`, only still
used in `plugin-api`.gjs which is being deleted in this PR.
This was preventing favorites emojis to work correctly as it was using
topic context. No tests for now as it's a very specific behavior hard to
test with acceptance test and a system spec seems heavy for this.
We made some changes to the SmallUserList widget in #31549. This accidentally broke at least one plugin (discourse-topic-voting) which uses it.
This fixes that by defaulting isVisible to true (old behaviour) when the argument is missing.
When you are uploading, it just causes weird problems
when you switch between markdown/rich editors, and it's
not something we really want to support. This commit
disables the Composer::ToggleSwitch while uploading.
Redis / Valkey over TLS requires authentication involving both a
username and a password.
On most instances, the default username is `default`, but this allows
Discourse to provide its own.
Adds support to typing `---`, `___` or `***` to create a horizontal
rule.
Converting when typing `---` is actually written here as an en-dash +
`-`, because the typographer replacements extension turns `--` into an
en-dash first.
`___` and `***` are only triggered after a whitespace, because they
could also mean bold+italic.
This commit updates `Migration::SafeMigrate` to protect against unsafe
ways of adding a Postgres index concurrently.
Per postgres documentation:
If a problem arises while scanning the table, such as a deadlock or a
uniqueness violation in a unique index,
the CREATE INDEX command will fail but leave behind an "invalid" index.
This index will be ignored for querying
purposes because it might be incomplete; however it will still consume
update overhead. The recommended recovery
method in such cases is to drop the index and try again to perform
CREATE INDEX CONCURRENTLY .
Therefore, the simplest way for us to ensure that migrations that create
indexes concurrently are idempotent is to follow postgres'
recommendation of dropping the index first before trying to create the
index concurrently.
There's no `textarea` with the rich editor, so being `undefined` it
fails with a `TypeError: Cannot read properties of undefined (reading
'id')`.
This has the same behavior with the textarea editor but works much
better (positioning closer to the caret) with the rich editor.
These specs are causing far more flakes and trouble than they are worth,
I think it's just the killer
combination of relying on messagebus and background jobs along with the
specs being quite big. Let's just get rid of them...
This was causing some confusion and now that we have the chat preference
to send with enter or metakey+enter it's even more confusing.
If your setting is send on enter, you need to use shift+enter for a new
line, even in codeblocks. If your setting is meta+enter you need to use
enter in the codeblock for a new line, meta+enter will send as expected.
A new user joining a community via DiscourseHub and logging in via oauth
goes through this process. This would break down for two reasons.
Reason 1: in some cases, especially on Safari mobile, the redirect in
the omniauth callback was happening too early. A new user may not be
signed in yet by that point, which means the redirect to
`/user-api-key/new` triggers a redirect to `/login` which ends up in a
bit of an infinite loop. Not all browsers exhibited this behaviour, but
Safari definitely did.
Reason 2: `/user-api-key/new` is gated via group membership using the
`user_api_key_allowed_groups` site setting. By default that is set to
include `trust_level_0`, however, auto group assignment wasn't taking
place for all user `create` events (only some that go through staged
users).
This PR refactors the UserFieldsValidation mixin into a helper class.
### Key Changes
* moved this.userFields to a tracked collection of TrackedUserFields
stored on the helper class itself
* introduced `validationVisible` property to explicitly control when to
display the validation result, we expect the helper to not display
validation until form submission in the `SignupController` and
`CreateAccount` components.
* added backward compatibility to the plugin API
`addCustomUserFieldValidationCallback` to ensure ex-Core instances of
the mixin continues working till we remove them
The previous version of the migration is not idempotent and can result
in indexes created but marked as "invalid" by Postgres.
Per postgres documentation:
If a problem arises while scanning the table, such as a deadlock or a
uniqueness violation in a unique index,
the CREATE INDEX command will fail but leave behind an "invalid" index.
This index will be ignored for querying
purposes because it might be incomplete; however it will still consume
update overhead. The recommended recovery
method in such cases is to drop the index and try again to perform
CREATE INDEX CONCURRENTLY.
Followup https://github.com/discourse/discourse/pull/31505/
When sending notification emails for system user responses for PMs,
we removed the part of the CTA where it says "to respond to xyz" in a
previous commit.
This commit takes it slightly further -- we now only show a "Visit
Topic"
or "Visit Message" button if the PM notification is from a system user,
it's a bit cleaner.
This commit also adds more in-depth tests, and refactors the message
builder a little.
