We need to reuse some of the groups UI in the admin dashboard. This is currently a bit hairy because it's using the old controller + routes + template style design.
This PR extracts to components, GroupCard, and GroupList, and shifts the logic in there.
This change does two things:
Modernizes the admin badges UI implementation. (Routes + controllers → components + services.)
Adds a Settings tab to the new badges page.
For all intents and purposes, this change is a lift-and-shift modernization. The addition of the settings tab is trivial once that is covered.
This was refactored from an actual Mixin some time back. This PR moves
the function to the lib folder and keeps the same logic/interface
otherwise.
We'll remove the mixin file once all non-core repos change to use the
new file.
This is to try fix this error by sending the keys
on the element itself:
```
Failure/Error: page.send_keys([PLATFORM_KEY_MODIFIER, "v"])
Selenium::WebDriver::Error::StaleElementReferenceError:
stale element reference: stale element not found in the current frame
(Session info: chrome=135.0.7049.84); For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors#stale-element-reference-exception
```
Avoid auto-linking URLs within code marks
Avoid auto-linking URLs when there's a `` ` `` just before the matched
URL, assuming the user is about to type a closing `` ` `` to create a
code mark instead.
This PR allows for other code to force the sidebar, but making the
language not admin-specific. There is a general problem to solve of "how
can I force the sidebar to appear, while keeping the hamburger menu in
the header as-is". This problem is solved for admin interface, but the
variable naming made it seem like the logic was directly tied to the
admin UI.
It is easy with this change, to have another sidebar manager force the
sidebar to be open for a route. Technically it was easy before, but it
would look like you were doing awful hacks.
---------
Co-authored-by: Isaac Janzen <isaac.janzen@discourse.org>
We don't want "ghost" `content` within mention/hashtag, as they're
already rendering their non-editable content on `toDOM`.
`atom: true` is not necessary for content-less nodes
Re-use existing heading node spec instead of re-creating.
A UX improvement from these changes is a better Cmd-Left/Home navigation
when these nodes begin a paragraph and the caret is after them.
Without the `useCapture` as `true` on this `ComposerUpload`'s
`addEventListener`, if the clipboard contained both a Files array and a
`text/html` item, the paste event would be captured by ProseMirror
before being captured by the `ComposerUpload` setup and its
`preventDefault` call.
* Hides the welcome banner search in mobile, it's not necessary
since there is the header search
* Fix an issue where the positioning of the search input for
the header on mobile was affecting welcome banner search
* Make the welcome font a bit smaller and with less padding so
it takes up less room on mobile
---------
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
This eliminates the `/mobile` and `/desktop` `header.scss` files and
moves the relevant CSS under `common/header.scss` using `.mobile-view`
and breakpoints.
I was also able to eliminate some redundant and unused styles in the
process and move a couple more general styles to `discourse.scss`
Adds support for a tag-chooser in form templates. It supports single tag
and multi tags. The source of the displayed tags has to be a tag_group
name.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
### Changes made
#### Styling
1. added `4px` spacing between search input and cancel button
2. increased cancel button size (with padding) to match input height
3. decreased search panel padding by 1/2 from 16px to 8px
4. animation show/hide changed (from vertical to horizontal) and made it
quicker (300ms->200ms)
5. set html unscrollable when search panel is open
#### Dev
1. changed `data-test-` value to be consistent with other element's
attrs values
2. clear search action tag changed from `<a>` to `<DButton>`
This commit adds a `:sidekiq_job_error` event which is
triggered when an error is encountered while running a Sidekiq job. The
intent of this change is to complement the `:sidekq_job_ran` event which
can be used with the `:sidekiq_job_error` event to calculate the error
rate for each job.
When a reviewable is auto-claimed, this actually claims all reviewables in a given topic, rather than just the specific post that the reviewable is about. Particularly for sites that require all posts to be reviewed, this can quickly result in many reviewables being unintentionally claimed by the first moderator to review a post in a given topic.
Unfortunately, due to `ReviewableClaimedTopic` being originally built to claim by topic, we can't fully fix this without significant re-architecture. In the mean time, however, we can ensure that reviewables are unclaimed once they've been handled, so that the next reviewable from a topic won't be automatically claimed.
When a flagged chat message has already been deleted, we offer an option
in the review queue to agree with the flag and keep the message deleted.
However, this option is currently broken due to a missing implementation
for the option.
Internal topic: t/152203.
Allow admins to edit user custom flags. Because changing
name/description will update name/description for old reviewables,
warning has to be displayed.
Still, system flags can never be edited or deleted (only disabled).
The test being fixed in this commit was flaking with the following
error:
```
Capybara::Ambiguous:
Ambiguous match, found 2 elements matching visible css ".stream-topic-title .title a[href*='/2']"
```
The regexp match on the `href` attribute has the potential to match
multiple elements if both urls contain the `/#{topic.id}` substring. For
example, both `/t/-/2/2` and `/t/-/1/2` will satisfy the regexp.
Followup 735bef9ea0d497ae7e04bd4a104bd86e928fc472
Remove the tip in search for users to press Ctrl+F
again to do browser search, as this is no longer relevant
This update adds randomized SVG placeholder designs for themes without
screenshots. Each placeholder pulls from the theme’s color palette to
give a better visual hint of what the theme might feel like.
There are a few different styles:
1. Envelope-style gradient – uses `tertiary`, `quaternary`, and
`highlight`
2. Soft blur gradient – uses `tertiary`, `quaternary`, and `highlight`
3. Mesh – uses `tertiary` and `secondary`
4. Layered waves – uses `tertiary`, `quaternary`, `highlight`, `danger`,
and `success`
The style is randomly picked per theme, so the grid looks more varied by
default.
<img width="1109" alt="image"
src="https://github.com/user-attachments/assets/5ede0ecf-a1e4-46c0-9fd2-bee4b6c672c2"
/>
Internal: /t/149935
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
This is already included in nginx's default set, and is currently
causing this message to be printed:
> nginx: [warn] duplicate extension "wasm", content type:
"application/wasm", previous content type: "application/wasm" in
/etc/nginx/conf.d/discourse.conf:4
It was using `<<` that caused the SiteSetting to get modified
Updated the spec to use the same pattern as other modifiers and used
`next` to return the correct value of the modifer
State seems to be leaking into other specs. Minimal repro:
```
bin/rspec --order defined spec/helpers/application_helper_spec.rb:783 spec/lib/wizard/wizard_builder_spec.rb:38
```
```
Failures:
1) Wizard::Builder introduction should not prefill default site setting values
Failure/Error: expect(description_field.value).to eq("")
expected: ""
got: " - modified by plugin"
```
Don't require password to create users with previous authentication in
the session, regardless of email/email verification during user creation
Before my changes we were calling `user.password_required!` in
`UserAuthenticator.authenticated?` based on whether authentication
session data contained a matching email address and email verified
externally. I believe `authenticated?` is intended for our own email
validation during the activation process, but shouldn't be a gate for
password requirement.
Even when we were setting `user.password_required`, then during user
creation we were creating random passwords to get around the blank
password restriction when creating accounts with external auth.
After my change we can remove the random password creation because we no
longer require a password when the session has previous authentication
info at all.
Looks like this extra password requirement may have been introduced as a
side effect during a previous refactor of `UserController` here:
51eff92170
Before that change, password requirement was simply based on whether
session[:authentication] existed, but after that change it was based on
the email/email_valid fields as well.
Building the Discourse JS app is very resource-intensive. This commit
introduces an `assemble_ember_build` script which will check the
existing content of the `dist/` directory and re-use the core build if
possible. Plugins will always be rebuilt.
For now, this functionality is only useful for multi-stage (i.e.
non-standard) Discourse deployments. But in future, this script may be
extended to pull the contents of the `dist/` directory from a remote
location.
This commits changes the language for components that aren't used on any themes to be "used/unused" instead of "active/inactive" throughout the new components listing page.
