We currently have `user_color_schemes` serialized on the preloaded
`Site` object, but it's very lightweight, only having an ID and name.
It would be useful for some themes and also the user Interface
preferences tab to be able to access the colors for the color scheme,
as well as the theme it belongs to.
This commit expands the serializer to include these extra attributes.
This `user_color_schemes` key is already cached as a fragment, so this
shouldn't be too much extra burden to send to the client.
Tight lists are lists that look like this:
* Item 1
* Item 2
* Item 3
Loose lists look like this:
* Item 1
* Item 2
* Item 3
There is a place for the latter, but the former is more
common default behaviour for writing apps and widgets, so
we are overriding the prosemirror default to use tight lists.
Eventually we will have a shortcut or other special behaviour
to switch between the list styles.
When editing a color palette via the new page introduced in
https://github.com/discourse/discourse/pull/31742, it should apply the
color changes for the admin making the change automatically upon save.
Internal topic: t/148628/12.
We intend to replace this JQuery autocomplete implementation soon. But
before that, we'd like to drop the raw-hbs compilation/runtime system.
Therefore, this commit does a 1:1 conversion of the autocomplete
templates to vanilla JS. They're fairly small/simple, so they're still
fairly readable.
Concerns this little fading scroll affordance in the horizontal overflow
nav:
The parent container of the user nav has an optional
`--d-content-background` variable applied, and adding this for the nav
means that if a theme author uses `--d-content-background` the nav will
match automatically. When `--d-content-background` is not set, we fall
back to `--secondary` which is the default background.
I also realized that we don't need RGB values here since we're simply
fading from a solid color to transparent.
The URLs returned by DiscourseConnect for the user's avatar, profile and
card backgrounds were not always correctly handling CDN.
This make use of the `GlobalPath.full_cdn_url` helper method which has
been battle-tested.
Ref - https://meta.discourse.org/t/-/356599
`/categories` sometimes returns accompanying topics under certain site
settings. The `CategoryList` currently allows preloading for topic
custom fields via `preloaded_topic_custom_fields`, but not for topics
themselves.
This addition is required for
https://github.com/discourse/discourse-solved/pull/342.
When multiple admins are working in the review queue, it's quite easy for two people to try and handle the same reviewable at the same time. This change addresses the two major situations where this can occur.
The `ReviewableClaimedTopic` model has been extended to allow the system to mark a reviewable as claimed as soon as the first moderator starts handling the reviewable, even when the `reviewable_claiming` setting is disabled. This ensures that reviewable actions with client-site activity (for example, `agree_and_suspend`) will lock the reviewable before another moderator starts working on it.
When someone handles handles a reviewable, we now use `MessageBus` to inform other moderators that it's changed. If any of the other moderator have that reviewable open (either individually, or on the list screen), it will automatically refresh that data.
The tests being fixed in this commit are not waiting for the
asynchronous behaviour of bulk closing topic to complete before running
some of the assertions. This commit updates the tests to check for the
asynchronous behaviour to complete so that the following assertions will
pass with more reliability.
We didn't have support in the #problem constructor for multiple targets, forcing developers to manually construct a Problem instance. This involves a lot of details and is error prone.
This PR supports passing an optional target argument to the constructor. This will be passed on to the translation_data method to generate the correct message as well.
Currently, the light version of mobile logo falls back to the desktop
version if the mobile version isn't set. It makes sense to have the same
fallback rule for the dark version as well, i.e. if there's no dark
mobile logo, use the dark desktop logo.
Internal topic: t/150316.
When logged in and visiting another user's drafts page, we should
redirect back to the current user drafts page.
For non auth users, we can redirect back to the forum `/latest` page.
Currently, anonymous/shadow users go through the same permission checks
for chat as normal users do. This means that if a site has chat enabled
for all users, anonymous users also get access to chat. This may be
undesirable for some communities, so we're adding a new site setting
`allow_chat_in_anonymous_mode` to block access to chat for anonymous
users.
Internal topic: t/148088.
This change allows more flexibility when starting a 1-1 direct message
with another user. If there are no messages in the new DM channel then
we should still allow them to add additional users.
This commit removes an assertion for the redirect after 2FA
authentication is success message because the message is flashed briefly
before a route transition happens. A proper fix would require us to
redesign when/how the flash message which we can address in the future.
This PR renames a couple of settings related to anonymous mode:
1. `allow_anonymous_posting` → `allow_anonymous_mode`. This setting is
used as a switch for the entire anonymous mode feature, so it makes
sense to give it a generic name that better reflects what the setting
does.
2. `allow_anonymous_likes` → `allow_likes_in_anonymous_mode`. The new
name is clearer and will match a new setting that we'll add to allow
anonymous users to post in chat.
Internal topic: t/148088.
introduces comprehensive statistics tracking for the Discourse
Automation plugin, allowing users to monitor the performance and
execution patterns of their automations:
- Add `discourse_automation_stats` table to track execution metrics
including run counts, execution times, and performance data
- Create a new `Stat` model to handle tracking and retrieving automation
statistics
- Update the admin UI to display automation stats (runs today/this
week/month and last run time)
- Modernize the automation list interface using Glimmer components
- Replace the older enable/disable icon with a toggle switch for better
UX
- Add schema annotations to existing models for better code
documentation
- Include extensive test coverage for the new statistics functionality
This helps administrators understand how their automations are
performing and identify potential bottlenecks or optimization
opportunities.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Ted Johansson <ted@discourse.org>
Meta:
https://meta.discourse.org/t/cant-erase-the-bookmark-search-input/357861/4
> When we fill in the bookmark search input and send the request, then
we can’t delete the input’s content.
After removing the last character, the `searchTerm` getter is called. At
this point, `_searchTerm` is empty.
However, `this._searchTerm || this.q` will treat the empty string as
_falsy_, and the `q` value is displayed instead.
It makes it impossible to clear the input.
To fix this, we check specifically on the initial state of
`_searchTerm,` which is _undefined_, to include an empty string as a
valid value.
Note: because of `@computed`, the issue is not triggered when the
content is selected and deleted.
Refactors the use of the buffered-content mixin to native getters on the
dependent classes.
This mixin previously provided a cached wrapper around an instance of
BufferedProxy and added 2 convenience methods aliasing BufferedProxy
methods.
### Main changes:
* Use of the`@cached` decorator to maintain parity with the previous
version of `this.buffered` to make sure we only refresh the buffered
proxy if the dependent property changes.
* _Not entirely sure if @cached + @dependentCompat is more performant
than just using `@computed`_
* Use of the`@dependentCompat` decorator to ensure backwards
compatibility of the getter with computed properties - we will leave
refactoring of those somewhere down the road as that would greatly
increase the scope of this PR
* `applyChanges` / `discardChanges` are the same as
`applyBufferedChanges` / `discardBufferedChanges` for BufferedProxy
Accessing a component-rendered DOM element from a service is not ideal,
and can lead to timing issues. We've attempted to work around this using
`afterRender`, but it's still not ideal.
This commit moves the `A11YDialog` setup into a modifier. Now the
service only stores state, and the component renders things based on
that state. This is much more in line with Ember norms, and should be
much more robust.
Test adjustments are because the dialog element is now only rendered
on-demand, rather than being present in the DOM all the time. This
brings dialog inline with our Modal system.
This commit updates the 2FA token submission page to disable the submit
button when the 2FA token is not valid and to also set the submit button
to be in the loading state after the submit button has been clicked.
The UX issues were discovered while I was investigating a flaky test
which has been unskipped in this commit as well. I am not sure if this
will completely resolve the flakiness but we have to unskip it to know
if it continues to be flaky.
Setting Rails.logger after the application has been initialized does not
seem to be safe anymore and can lead to flaky tests. This commit
disallows the reassignment of `Rails.logger` going forward and updates
the affected test.
### Reviewer notes
Reassigning `Rails.logger` from within RSpec tests is causing tests
which uses `Rails.logger.broadcast_to(FakeLogger.new)` to flake.
Example:
https://github.com/discourse/discourse/actions/runs/13951116847/job/39050616967
```
1) invalid requests handles NotFound with invalid json body
Failure/Error: expect(fake_logger.errors).to have_attributes(size: 1)
expected [] to have attributes {:size => 1} but had attributes {:size => 0}
Diff:
@@ -1 +1 @@
-:size => 1,
+:size => 0,
# ./spec/integration/invalid_request_spec.rb:18:in `block (2 levels) in <main>'
# ./spec/rails_helper.rb:619:in `block (3 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/benchmark-0.4.0/lib/benchmark.rb:304:in `measure'
# ./spec/rails_helper.rb:619:in `block (2 levels) in <top (required)>'
# ./spec/rails_helper.rb:580:in `block (3 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
# /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
# ./spec/rails_helper.rb:570:in `block (2 levels) in <top (required)>'
# ./spec/rails_helper.rb:527:in `block (2 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/webmock-3.25.1/lib/webmock/rspec.rb:39:in `block (2 levels) in <top (required)>'
```
Now we have the search input showing in a few
different configurations:
* Welcome banner
* Header field
* Header icon
And we can get to the search with both `/` and
`Ctrl+F` shortcuts. These configurations can
be used together, and we need to focus on the right
search input at the right time.
This commit fixes the shortcuts not working
or showing the wrong thing in some cases,
and adds a comprehensive system spec for all
the variants.
We often need to be able to change the format of a container and to
change the flex-direction, this is now possible through two properties:
`<form.Container @format="large">`
`<form.Container @direction="column">`
On top of this `Object` has now a similar behavior to `Collection`. It
will be displayed as flex, add gap between children and accepts
`...attributes`.
Ideally we would add support for color spaces like okclh to the app, or
have some method for converting them to rgb automatically. But for now,
this will stop the app crashing completely.
We want to give some themes more control over
the default experience in core. To this end, this
commit adds value transformers for these
site settings:
* enable_welcome_banner
* search_experience
This way, themes can give a different value to
what has been set in core.
This can be potentially confusing, a follow up PR
may refactor this a bit so there is a more direct
correlation between the setting and the transformer
so we could show a warning in the site setting page
for example.
