This switches the signup/login UI to the full page experience by
default. This has been in use by many sites for multiple months and we
have ironed out many fixes in the meantime.
The `full_page_login` setting is also marked for removal in about
1.5mths, by the end of April 2025.
This commit unskips 3 flaky system tests and gives up on asserting that
redirecting is done correctly. This is because we have invested
considerable effort into this and cannot figure it out. The redirect is
tested by the client side anyway so there is still some test coverage.
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.
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.
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.
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.
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.
Commit f1700ca58929bcbfad23565861d1d3084ae1b3f8 ensures that categories
are loaded lazily, in pages, if the number of visible categories is over
1000. This affected the list of subcategories on the category page too.
The logic has been changed to only paginate if the number of categories
that would have been returned is grater than 1000. For example, if there
is a parent category filter, pagination will only be enforced if the
number of subcategories is over 1000.
Fixes an incorrect logic on `transformPasted` that was causing a
`TypeError: Cannot read properties of null (reading 'marks')` when only
part of a paragraph was selected.
Adds tests
Follow-up to https://github.com/discourse/discourse/pull/30953
This PR is a partial revert of the linked PR — it changes the "Themes
and components" link in the admin sidebar back to the legacy
`/admin/customize/themes` page and adds the themes list/sidebar back to
the left hand side of the page. The new `/admin/config/customize/` route
is still available, but it's not linked from anywhere. When accessing
the new page and then navigating to a theme, the old components (e.g.
the themes list) of the page are hidden. This allows us to iterate on
the new page and improve until we're more ready to make it available
more widely.
Both tests being unskipped here failed previosly with the following
error:
```
Failure/Error: expect(page).to have_current_path("/u/#{user.username}/preferences/account")
expected "/u/confirm-new-email/f42a416fcbca40d66788d65a8837ad49" to equal "/u/bruce306/preferences/account"
./spec/system/email_change_spec.rb:49:in `block (2 levels) in <main>'
```
The error indicates that the transition was not successful and I
suspect that it may be due to the use of the `/my` route prefix which
is just a nice to have and not necessary.
When hard deleting a first post by passing force_destroy: true as an option to PostDestroyer, the post/topic is correctly deleted, and the staff record is created, but the app then errors out.
This only happens on sites with a topic_destroyed webhook setup.
After deleting the record, we pass the topic's ID to TopicView, which then raises an error because it can not load it from the DB.
TopicView supports being initialized with either an ID or an already instantiated record. Since we still have the record in memory after deleting, we can pass that to TopicView.
We currently limit the number of characters in the bar-separated list of auto-membership e-mail domains. We want to make this configurable through site settings.
After this change, we limit the length of each individual domain, and enable the number of domains to be configured through a hidden site setting.
The original limit is there to prevent DoS, since a TEXT column can take up to 1Gb. With this new limit we're still at a maximum of around 10kb.
The change made in #31854 introduced a regression when editing groups, preventing saving when no auto membership e-mail domains are entered.
This change fixes that and adds a system test.
Before this commit,
`PageObjects::Components::SelectKit#expanded_component` might not expand
the component if `is_collapsed?` returns true which can return true if
the method was called before the select-kit component appears on the
screen. When that happens, we end up not expanding the `select-kit`
because we think it is collapsed when in fact the select-kit component
is not rendered yet. This lead to system test failures with errors like:
```
Capybara::ElementNotFound:
Unable to find css "#add-synonyms.is-expanded"
```
This commit updates `PageObjects::Components::SelectKit#is_collapsed?`
to check that the select-kit component has rendered first before
checking if the component is not expanded.
### Reviewer notes
Instances of test flakiness due to this bug:
1.
https://github.com/discourse/discourse/actions/runs/13905226478/job/38906569777
2.
https://github.com/discourse/discourse/actions/runs/13848357836/job/38751122333
Follow up to e4401e587e98ac4020c2c4fd965e227146cf33d4.
In the previous change, when serialising a Reviewable post, we were appending the title to the post content whilst checking for watched word matches. This append action was acting upon the object itself, rather than just a copy of the string, causing the UI to display the title appended twice to the content.
Fortunately, since it was only happening in the serialiser, the incorrect data was never stored in the database, it was only happening when viewing the review queue.
When performing an action in the review queue, this change makes two improvements:
- The buttons on the reviewable item are disabled, so you can't accidentally multi-click.
- A toast is displayed when the action is complete, as a success indication.
Fixes the custom homepage crawler output to include links to the site's
top menu.
This also provides a way to override that content via a plugin. Example
usage in a `plugin.rb` file:
```
register_html_builder("server:custom-homepage-crawler-view") do |c|
"<div>override</div>"
end
```
Currently we allow for 2 theme screenshots to be specified,
with a lightweight spec to allow both a light and dark
version of the screenshot. However, we were not storing this
screenshot name anywhere, so we would not be able to use it
for light/dark switching.
This commit fixes that issue, and also does some general refactoring
around theme screenshots, and adds more tests.
Test is flaking in CI with:
```
Failure/Error: expect(theme_translations_settings_editor.get_input_value).to have_content("Bonjour!")
expected to find text "Bonjour!" in "Hello there!"
[Screenshot Image]: /__w/discourse/discourse/tmp/capybara/failures_r_spec_example_groups_admin_customize_themes_when_editing_theme_translations_should_allow_admin_to_edit_and_save_the_theme_translations_from_other_languages_797.png
~~~~~~~ JS LOGS ~~~~~~~
(no logs)
~~~~~ END JS LOGS ~~~~~
./spec/system/admin_customize_themes_spec.rb:158:in `block (3 levels) in <main>'
```
This is a stripped-back version of the Search Banner
component https://meta.discourse.org/t/search-banner/122939,
which will be renamed to Advanced Search Banner,
see https://github.com/discourse/discourse-search-banner/pull/84.
This welcome banner interacts with the header search.
When `search_experience` is set to `search_field`, we only
show the header search after the welcome banner scrolls
out of view, and vice-versa.
Only new sites will get this feature turned on by default,
existing sites have a migration to disable it.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
This is a follow up to 6820622467ab3613e824f0cb6219def2a575bc1d.
This commit addresses migrations that uses `remove_index` with the
`if_exists: true` option to drop an existing index before creating an
index using the `concurrently` option.
This commit also reruns two migration which may have caused indexes to
be left in an `invalid` state.
### Reviewers Note
Plugin tests are failing due to
https://github.com/discourse/discourse-translator/pull/251
The "Tag synonyms when visiting edit tag page allows an admin to create
a new tag as synonym when tag does not exist" system
test was flaky with the following error:
```
Failure/Error: super
Capybara::ElementNotFound:
Unable to find css "#add-synonyms.is-expanded"
```
Backtrace points to the following location:
```
...
./spec/system/page_objects/components/select_kit.rb:30:in `expanded_component'
./spec/system/page_objects/components/select_kit.rb:88:in `search'
...
```
What I noticed is that
`PageObjects::Components::SelectKit#expanded_component` has already
found the expanded element when it calls `#expand`. Therefore, there is
no need for us to search for it again.
