Due to server upload limits backups may receive a 413 error so we need
to display a different error message than the default one we have set
for attachments.
We have one site setting, `auto_silence_fast_typers_max_trust_level`, which expects a trust level. However, the type is set to integer, which makes it very hard for a layman to enter the correct thing.
This PR changes the type of the site setting to the `TrustLevelSetting` enum.
The use of these are interchangeable in the back-end, since `SiteSetting.auto_silence_fast_typers_max_trust_level` still returns the integer value with the enum.
This adds a new secure_uploads_pm_only site setting. When secure_uploads
is true with this setting, only uploads created in PMs will be marked
secure; no uploads in secure categories will be marked as secure, and
the login_required site setting has no bearing on upload security
either.
This is meant to be a stopgap solution to prevent secure uploads
in a single place (private messages) for sensitive admin data exports.
Ideally we would want a more comprehensive way of saying that certain
upload types get secured which is a hybrid/mixed mode secure uploads,
but for now this will do the trick.
Chat review queue flags were missing the context message above the actions.
This is probably because the (reasonably complex) logic was somewhat hard-coded to posts. After some investigation I concluded we can reuse this logic with some small amendments.
Why this change?
As part of our ongoing efforts to security harden the Discourse
application, we are adding the `cross_origin_opener_policy_header` site setting
which allows the `Cross-Origin-Opener-Policy` response header to be set on requests
that preloads the Discourse application. In more technical terms, only
GET requests that are not json or xhr will have the response header set.
The `cross_origin_opener_policy_header` site setting is hidden for now
for testing purposes and will either be released as a public site
setting or be remove if we decide to be opinionated and ship a default
for the `Cross-Origin-Opener-Policy` response header.
When an upload fails and we don't have a specific error, we
show a generic one. But it's a little too generic -- it doesn't
even include the file name.
This commit shows the file name so you at least know which of your
uploads failed.
This tab doesn't really provide anything useful, and can be quite
confusing in some cases. Each plugin is already listed below, and
you can navigate to their settings from there. We want to move away
from the catch-all Plugins category for site settings. Core plugins are
not shown in this list as at 97a812f022f3e7baa51f354e8f632bec0683fb6d.
According to the output of this rake task:
`LOAD_PLUGINS=0 bin/rails "site_settings:find_dead"`
which searches for unused site settings, these settings:
```
rate_limit_new_user_create_topic
enable_system_avatars
check_for_new_features
allow_user_api_keys
```
are unused.
Follow-up to #23199 in which we moved the "delete user" options under the relevant action menu for flagged post. This change does the same, but to queued posts.
In an effort to aid in the searchability of Content-Security-Policy related
site settings this commit is appending "CSP" to several
`content_security_policy_` site setting descriptions.
This PR adds a new toggle to switch the (new) /new list between showing topics with new replies (a.k.a unread topics), new topics, or everything mixed together.
Why this change?
This is a follow up to e8f7b62752a65e33aa1cee748fc966c4ad14b1ee.
Tracking of GC stats didn't really belong in the `MethodProfiler` class
so we want to extract that concern into its own class.
As part of this PR, the `track_gc_stat_per_request` site setting has
also been renamed to `instrument_gc_stat_per_request`.
What does this change do?
This change adds a hidden `track_gc_stat_per_request` site setting which
when enabled will track the time spent in GC, major GC count and minor
GC count during a request.
Why is this change needed?
We have plans to tune our GC in production but without any
instrumentation, we will not be able to know if our tuning is effective
or not. This commit takes the first step at instrumenting some basic GC
stats in core during a request which can then be consumed by the discourse-prometheus plugin.
Linking to the #feedback category can break if the category gets renamed or a different site locale is used. By using the correct hashtag (at the time of seeding) this issues can be avoided.
This PR updates how we display related and suggested topics on mobile and desktop. It adds a new `PluginOutlet` specifically designed for adding new topic lists, which automatically work if following the same conventions as the ones inside `<MoreTopics />`.
While we display lists side by side on desktop, we only display one in mobile. You can switch to another one by clicking on the nav pills, and we'll automatically save your preference for next time.
Toggling these settings will prevent 'published' topics (e.g. from shared drafts) from creating notifications for people watching the relevant category/tag.
provide the ability to edit theme settings in the json editor, and also copy them as a text file so they can be pasted into another instance.
Reference: /t/65023
Followup to f5e8e73.
This switches the placeholder label to the existing string "optional
tags" and only shows it if there are no items picked.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
