- Migrated from annotate to annotaterb as the former is not maintained
anymore.
- Dropped our `fast_pluck` patch as the default `pluck` implementation
seems now faster.
Previously, running qunit tests for a plugin would load the JS of all
installed plugins. This can be problematic because, depending on the
plugins installed in the current environment, there can be unexpected
interactions between the plugins.
This commit updates our qunit system to check the
`tests.requiredPlugins` list from the theme/plugin `about.json` file,
and only loads the listed plugins. This means that the environment is
much more consistent across CI and different development environments.
Alongside that change, this commit also:
- Starts storing the original `about.json` for themes in the database
- Improves qunit error handling when the test environment fails to boot
(e.g. there's a bad import in a plugin)
- Restores plugin CSS in theme qunit tests
A while back we replaced hard-coded #is_staff? checks with group based permissions.
The edit_post_allowed_groups setting has admins and moderators (i.e. staff) as mandatory values, and so we no longer need the explicit staff check.
A while back we replaced hard-coded #is_staff? checks with group based permissions.
The edit_post_allowed_groups setting has admins and moderators (i.e. staff) as mandatory values, and so we no longer need the explicit staff check.
In #33587 we moved PostGuardian related tests from guardian_spec to post_guardian_spec. When doing so we also added stubs for missing tests.
This PR implements those missing tests.
The educational posts site setting (`educate_until_posts`) feels buggy,
this is because the logic for showing these messages treats topics and
replies (posts) as a separate count.
If `SiteSetting.educate_until_posts` has a value of 2, the user can
write multiple replies to existing topics and see the "Welcome to our
community! You are brand new here..." message for the first 2 times then
it will not show again.
However, once they decide to create a topic they will see the message
again which doesn't feel right.
The solution is to use a combined count (`user.topic_count` and
`user.post_count`) and check against the site setting value. That way we
don't double up educational messages for both topics and replies when
using composer.
When the reply_by_email_enabled setting is set to false, we no longer include a reply link in e-mail notifications. However, we do not prevent actual e-mails to a configured email_in address associated with a category.
This change into consideration the setting in Email::Receiver#check_address.
Previously, all script tags in a theme field would be combined into a
single `.js` bundle along with the `text/discourse-plugin` modules. This
led to some unexpected run order, and also makes it hard to implement
the `type=module` change being developed in #33103.
This commit refactors things so that each raw script gets extracted into
its own `.js` bundle, which is then placed in exactly the same place in
the HTML.
Followup 19af83d39e
There was another edge case here, where this scenario happened:
* A site setting is deprecated _without_ an override
* This site setting is being shadowed by a global setting
* This would cause an argument error when getting the deprecated
setting value in SiteSetting.client_settings_json_uncached
An example of this setting was `external_system_avatars_enabled`.
The shadowed setting was blowing up because it was missing the
`scoped_to` argument that was added for themeable site settings
in the referenced commit.
This commit fixes the issue and adds a spec to cover this scenario,
followup commit will add stronger handling of shadowed global
settings for theme site settings...this is not allowed.
Followup 19af83d39e
In some scenarios, the client_settings_json_uncached
was silently failing and returning "", which caused
problems down the line in mini_racer when this code
was produced:
```
__optInput = {};
__optInput.siteSettings = ;
```
The problem was only happening in rare cases with interaction
between core and other plugins, because the length of the
array we were trying to make a Hash with wasn't an even length.
To address this, we can use filter_map to ensure correct behavior,
and add some specs and also raise errors when parsing client settings
JSON
in specs, so we don't miss this in the future.
This commit introduces the concept of themeable site settings,
which is a new tool for theme authors that lives alongside theme
modifiers and theme settings. Here is a quick summary:
* Theme settings - These are custom settings used to control UI and functionality within your theme or component and provide configuration options. These cannot change core Discourse functionality.
* Theme modifiers - Allows a theme or a component to modify selected server-side functionality of core Discourse as an alternative to building a plugin.
* Themeable site settings (new) - Allows a theme (not components) to override a small subset of core site settings, which generally control parts of the UI and other minor functionality. This allows themes to have a greater control over the full site experience.
Themeable site settings will be shown for all themes, whether the theme
changes
the value or not, and have a similar UI to custom theme settings.
We are also introducing a new page at
`/admin/config/theme-site-settings` that
allows admins to see all possible themeable site settings, and which
themes
are changing the value from the default.
### Configuration
Theme authors can configure initial values themeable site settings using
a section in the `about.json` file like so:
```json
"theme_site_settings": {
"search_experience": "search_field"
}
```
These values will not change when the theme updates, because we cannot
know if admins have manually changed them.
### Limitations
Themeable site settings are only really intended to control elements of
the UI, and when retrieving their value we require a theme ID, so these
limitations apply:
- Themeable site settings cannot be used in Sidekiq jobs
- Themeable site settings cannot be used in markdown rules
- Themeable site settings will be cached separately to client site
settings using theme ID as a key
- Themeable site settings will override keys on the `siteSettings`
service on the client using the application preloader
- `SiteSetting.client_settings_json` will not include themeable site
settings, instead you can call `SiteSetting.theme_site_settings_json`
with a theme ID
### Initial settings
There are only two site settings that will be themeable to begin with:
* `enable_welcome_banner`
* `search_experience`
And our new Horizon theme will take advantage of both. Over time, more
settings that control elements of the UI will be exposed this way.
And forward them in "discourse id" so we can pre-fill the email field on
the signup page.
Also added `PreloadStore.has("key")` so we can quickly check a key is
present in the "preload store" without actually retrieving it.
Internal ref - t/154880
We want to add an option for admins to carry out the operation silently
when they are updating the category for the selected topics. When the
“Perform this action silently” checkbox has been checked, the
`:notify_category_change sidekiq` job should not be enqueued.
When we are tracking requests in the `Middleware::RequestTracker`, we
have historically added an `X-Discourse-TrackView` response header
for implicitly tracked requests HTML requests, and also explicitly
tracked page view requests when navigating the Ember app.
Within the past couple of years, we introduced the concept of
Browser Page Views (BPVs), which are recorded when requests are made
via AJAX when navigating the app with Ember, and also piggybacked
onto the first MessageBus request on page load. The former is known
as an explicitly tracked request, the latter is a deferred tracked request.
The explicitly tracked browser page views also add the `X-Discourse-TrackView`
header to the response, so it is hard to differentiate which requests are purely
browser page view requests in the logs.
This commit adds a new response header, `X-Discourse-BrowserPageView`,
that acts in a similar way to the existing `X-Discourse-TrackView`
header, but is specifically for requests that are tracked as BPVs (both explicit
and deferred).
This commit make it easier for staff to see if a profile is silenced by
aligning it with how suspended notices are shown.
- The number of times a profile has been silenced is shown in the staff
counters banner at the top of the public user profiles.
- Clicking on the silenced note in the staff counters banner goes to a
filtered view of the staff action logs for the user and the silenced
action.
- The profile indicates if a user is silenced and shows the date they
are silenced until. This looks exactly the same as how it currently
displays for suspended users, with the added info of the date. This is
also displayed on the user card, the same as suspended notices currently
are.
## Screenshots
Adding `alt=""` to tell screenreaders to skip these, we don't reliably
have alt content available for onebox images and they tend to be
decorative, so better to omit.
<img width="738" height="151" alt="learn.microsoft.com onebox with the
link whats new in C# 11, there's a purple C# badge to the left of the
link"
src="https://github.com/user-attachments/assets/15bdc830-683f-4c69-a11b-9d54c66fa627"
/>
We already do this in some oneboxes, so this covers some more cases
including the generic.
This PR introduces a heading/paragraph dropdown menu for the
composer toolbar, that works for both the new rich text editor, and
the old markdown editor.
Features include:
* Dynamically changing the icon based on the heading level
* Checking the current heading level in the dropdown list
* Applying the same heading level to multiple selections
---------
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Renato Atilio <renatoat@gmail.com>
The reasons for these changes is https://meta.discourse.org/t/-/89605
broke and admins were not able to log back in if they had previously
enabled the "read only" mode.
Thus ensued a deep dive into how all the "read only" modes worked, which
was made difficult due to the lack of tests.
The "cornerstone" of this PR is the `read_only_mixin.rb` file which was
improved to be able to differentiate between the "readonly" mode and the
"staff writes only" mode.
I then made use of the `allow_in_readonly_mode` and
`allow_in_staff_writes_only_mode` method to **explicitely** list all the
actions that should work in those modes.
I also added the "readonly" mixin to the `WebhooksController` since it
doesn't inherit from the `ApplicationController`.
I improved the security of the `/u/admin-login` endpoint by always
sending the same message no matter if we found or not an admin account
with the provided email address.
I added two system specs:
1. for ensuring that admins can log in via /u/admin-lgoin and then
clicking the link in the email they received while the site is in
readonly mode.
2. for ensuring the "staff writes only mode" is _actually_ tested by
ensuring a moderator can log in and create a topic while the site is in
that mode.
Plenty of specs were updated to ensure 100% converage of the various
"read only" modes.
JS assets defined under `admin/` in plugins are compiled into a separate
bundle that should be loaded for staff users only, but we currently load
it for all users including normal users and anons. This is wasteful and
unexpected since it could cause errors if an asset in the admin bundle
of a plugin imports a module from the admin bundle in core (which
doesn't get loaded for non-staff users).
We want to deprecate the enabled/disabled toggle for this setting and rely entirely on the presence of a URL.
This change:
- Deprecates and hides the enabled/disabled setting.
- Updates all code paths and tests that rely on the old setting.
- Adds a migration that clears the URL if the enabled/disabled setting is set to false.
This is the start of the review queue redesign. Due to the rapidly
growing size of this redesign, this PR is being merged in a
semi-functional state: large chunks of it have the new design, but there
are substantial sections that may not function at all.
This PR is focussed on the variations of reviewable posts, other
reviewables (eg, users, chat messages) will continue to use the old UI.
Co-authored-by: Gary Pendergast <gary@pento.net>
The site setting hide_new_user_profiles states:
> Hide trust level 1 or lower user profiles from the public and trust level 1 users until they post for the first time.
This implies that TL2 and above should be visible.
However, the actual logic encodes the assumption that TL2 have posted at some point. This fails to account for the fact that admins can manually upgrade a user without posts to a higher TL. This PR covers for that scenario.
Improvements:
- When import Horizon theme, ensure that default color scheme is marked
as `user_selectable`
- Dark version of the theme is `user_selectable` as well
- When merge remote Horizon into system Horizon, also ensure that
default color scheme is marked as `user_selectable`
This commit introduces an experimental `reviewable_ui_refresh` site
setting of `group_list` type. When a user is part of any group
configured in the site setting, the new reviewable UI will be shown to
the user.
Co-authored-by: Gary <gary@pento.net>
We want to add a hidden limit to the number of locales an admin can set
for localization. This is a safe limit to prevent excessive localization
(if each post can be localized to 10 locales, that's 10x the amount of
storage and tokens needed).
t/157677
Rake task to merge a single installation of Horizon into the system
Horizon.
What task do:
- Set Horizon as `experimental_system_themes` if not yet included;
- Set system Horizon as the default if manual Horizon was the default;
- Set the system Horizon as selectable if the manual Horizon was
selectable;
- Link components from the manual Horizon to the system Horizon;
- Update UserOptions `theme_id`, `color_scheme_id` and `dark_scheme_id`;
- Update the system Horizon color palette to match the manual Horizon
color palette;
- Move ThemeSettings from manual Horizon to system Horizon;
- Move ThemeTranslations from manual Horizon to system Horizon;
- Delete manual Horizon color schemes;
- Delete the manual Horizon.
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
This commit adds a new modifier that plugins can hook into to add further
restriction to who can install themes and components via the admin UI. It
isn't possible to use this modifier to open up the theme installation
permissions to more than core allows, e.g. this modifier can't be used
to allow moderators to install themes on the site.
Internal topic: t/156924.
There exists a hidden `search_recent_regular_posts_offset_post_id` site
setting which is used to optimize the searching of recent posts through
the use of a partial index. However, we do not want this optimization to
apply when the `before` and `after` advanced search filters are used
since the partial index only contains the most recent posts 1 million
posts and the `before`/`after` filter may be searching for posts that
falls outside of the
most recent posts range.
The `uploads:sync_access_control` rake task should reset the access
control
of all s3 objects linked to an upload record. This means that if the
`s3_use_acls` site setting has been disabled, the rake task should
remove the existing ACL that has been set previously.
Before this change, users were able to see their own whispers even if
they are no longer in the groups specified by the `whispers_allowed_groups` site setting.
This commit fixes that by disallowing users to see their own whispers if
they are no longer part of any `whispers_allowed_groups`.
This commit moves the humanization of site setting names from the client
side to the server side, since this is becoming more widely used and
will be useful for specs to be able to access the same humanized name
formatting without duplicating the logic on the server.
There are only a couple of places in the admin UI that we send this
down in the JSON, the `site.sitSettings` object does not include these
humanized names as they are not needed.
- improve the contract a little
- use `model` where possible
- extract message existence logic to a dedicated policy, allowing easier
testing.
- remove unused code
- refactor specs to follow current guidelines/best practices
