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.
Continues the work done on
https://github.com/discourse/discourse/pull/30815.
Adds `spoiler` and `inline_spoiler` nodes, parsers, and serializers, and
a click handler to toggle its blurriness in the editor.
Continues the work done on
https://github.com/discourse/discourse/pull/30815.
Adds a `onebox` and an `onebox_inline` node spec, their serializers, and
a plugin that automatically converts links to oneboxes.
This might not reduce the failures to zero but some screenshots of the
failures clearly show we were still on the success message page.
Same fix than: https://github.com/discourse/discourse/pull/31750
I suspect that sometimes the button was still not disabled yet when we
where checking for it. Checking for saved confirmation should be more
resilient.
- Remove `wait: 0` and base flow on site setting instead
- Ensure full-page-login has actually opened before running `go_back` -
otherwise we'll end up going back to `about:blank`
