This makes the backtrace for a deprecated icon name error clearer in
terms of pointing out which plugin the icon is being registered from.
The error will only be raised in the test environment.
This PR also extracts out to a separate module the hashmaps & logic for
converting FA4 era icons to discourse FA6 compatible icons. This
isolates that logic for reuse in DiscoursePluginRegistry - otherwise
pulling in the whole SvgSprite resulted in errors.
This was intended to provide a better UX for interactive elements in the
composer preview. However, the morphing strategy has irreconcilable
conflicts with our `decorateCooked` API, and so we have been unable to
enable this by default.
Going forward, we're focussing efforts on the WYSIWYG composer to
provide this kind of smooth UX, so we're dropping the
`enable_diffhtml_preview` approach.
A previous refactor of the `Service::Base::Step` class introduced a
non thread-safe behavior. `#call` mutates instance variables at runtime,
and since a step instance is the same for any given service class, this
can sometimes lead to `context` being the wrong one for the running
service.
This patch makes use of `Concurrent::ThreadLocalVar` to fix the issue.
While it is possible derive a topic published event from category id
changes in a `post_edited` or `before_post_publish_changes` event, there
are use cases when a dedicated event is more apposite.
This repo was archived in March 2024 and is no longer supported.
Commit also fixes up the plugin-gem-symlinking logic to support removing
plugins from the list
[Security
patch](5558e72f22)
(for this [CVE](https://nvd.nist.gov/vuln/detail/CVE-2024-54133)) from
rails actionpack was backported from [Rails
8.0.0.1](https://github.com/rails/rails/blob/v8.0.1/actionpack/CHANGELOG.md#rails-8001-december-10-2024)
to previous stable versions including `7-1-stable` / `7-2-stable`.
Any previous version of Discourse upgrading to v3.4.0.beta3 and above
would have observed their sites crashing if they had invalid sources in
their CSP directive extensions.
This fix removes such invalid sources during our build of the CSP, and
logs these at a warning level so devs are able to find out why their CSP
sources were filtered out of the extendable directives.
This commit contains a couple of improvements for this
rake task.
* We no longer limit the uploads to only ones with Post
upload references, it doesn't matter what the secure uploads
are linked to, they should all be un-secured
* We now only get distinct uploads from the initial query,
multiple upload references on the same upload caused
double ups and confusing counts for the task
* We now also disable the secure_uploads_pm_only site
setting at the same time
This fixes an issue where the topic invitation rate limiter
for invites for the 1 minute period was incorrectly using
1 day as the length of time the limit should be applied over.
The default for `max_topic_invitations_per_minute` is 5,
so this would be very easy to exceed, then the user gets
a very confusing warning message saying they have to wait
23 hours to send more invites.
This commit also makes other `RateLimiter` period parameters
more consistent by always using the form `N.PERIOD` instead
of things like `86_400` hardcoded seconds per day.
By default, when multiple login providers are enabled, Discourse
requires user interaction before triggering an external auth flow. This
is defense-in-depth against "Login CSRF" attacks.
This commit introduces a setting to control this behavior, so that it
can be disabled when admins fully trust the downstream systems, and need
an interaction-free login flow on a site with multiple login providers.
Default behavior remains unchanged.
When `suppress_secured_categories_from_admin` SiteSetting is enabled, it
is expected that the admin will not be notified about PMs in which they
are not participating - even when they watch the attributed tag.
Before it was only checking if the admin had access to a secured
category assigned to a regular topic. PMs do not have categories so we
need to ensure that admin in participating in that conversation.
Followup 503f9b6f02ac5c4918d41611848c886b8755e5a0
This previous commit introduced an autogenerated
settings route for every plugin with more than one
setting defined. Plugins with only one setting
only have enabled_site_settings defined, which are
handled using the toggle in the admin plugin list,
so we don't need a dedicated setting page for them.
However in production this introduced a performance
issue, since we were looking through SiteSetting.all_settings
for every plugin, which could be quite slow in some
cases especially on our hosting.
Instead, we already have all the plugin settings cached
inside `SiteSetting.plugins`. We can instead use this to
count how many settings the plugin has, then if there is > 1
for a plugin we use the settings route. This is a much faster lookup
than
searching through SiteSetting.all_settings.
This commit makes the
[color-scheme-toggle](https://github.com/discourse/discourse-color-scheme-toggle)
theme component a core feature with improvements and bug fixes. The
theme component will be updated to become a no-op if the core feature is
enabled.
Noteworthy changes:
* the color mode selector has a new "Auto" option that makes the site
render in the same color mode as the user's system preference
* the splash screen respects the color mode selected by the user
* dark/light variants of category logos and background images are now
picked correctly based on the selected color mode
* a new `interface_color_selector` site setting to disable the selector
or choose its location between the sidebar footer or header
Internal topic: t/139465.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
This patch adds two things:
1. An outcome matcher (`on_lock_not_acquired`), allowing to react when
there was a problem with the lock.
2. Compatibility with the steps inspector, allowing to display properly
the steps of a service containing locks.
Currently, the markdown for uploads is counted towards post minimum length requirements. This change introduces a site setting `prevent_uploads_only_posts` which can be flipped to exclude upload segments from the calculation.
Previously, were always forcing the page to reload
for the wizard after pressing Next for the styling step,
with the logic that if style changes are being made,
the admin needs to see them straight away.
However this doesn't make sense if nothing changes on
that step. This commit makes the change to only refresh
the page if any of the settings on the step changed,
bringing it in line with other steps.
In the current admin index page, all plugins show up as tabs. This includes plugins with auto-generated config routes.
This changes the tabs to include only plugins with custom UIs.
This is the first in a series of PRs to introduce a
ProseMirror-based
WYSIWYM editor experience
alongside our current textarea Markdown editor.
Behind a hidden site setting, this PR adds a toggle to the composer
toolbar, allowing users to switch between the two options.
Our implementation builds upon the excellent ProseMirror and its
non-core Markdown
module, using the
module's schema, parsing, and serialization definitions as the base for
further Discourse-specific features.
An extension API is included to enable further customizations.
The necessary extensions to support all Discourse's core and core
plugins features **will be implemented in subsequent PRs**.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
This commit drops the `before_action :preload_json` callback in `ApplicationController` as it adds unnecessary complexity to `ApplicationController` as well as other controllers which has to skip this callback. The source of the complexity comes mainly from the following two conditionals in the `preload_json` method:
```
# We don't preload JSON on xhr or JSON request
return if request.xhr? || request.format.json?
# if we are posting in makes no sense to preload
return if request.method != "GET"
```
Basically, the conditionals solely exists for optimization purposes to ensure that we don't run the preloading code when the request is not a GET request and the response is not expected to be HTML. The key problem here is that the conditionals are trying to expect what the content type of the response will be and this has proven to be hard to get right. Instead, we can simplify this problem by running the preloading code in a more deterministic way which is to preload only when the `application` layout is being rendered and this is main change that this commit introduces.
This PR raises an error on any deprecated icon names being converted by
svg_sprite.rb, which will result in any deprecated icons being processed
by the ruby lib to fail tests.
This change adds a sidebar link for each plugin that fulfils the following criteria:
- Does not have an explicit admin route defined in the plugin.
- Has at least one site setting (not including enabled/disabled.)
That sidebar link leads to the automatically generated plugin show settings page.
Rake allows env variables to specified in arguments, so we need to use
the list of top_level_tasks which excludes those env
Followup to c8718a64dd7a26165efe91706ce5507e6999044a.
By design, db:create initializes the Rails app with SKIP_DB=true. That
means that SiteSettings get set up with the LocalProcessProvider instead
of the DBProvider. In other words: any calls to site settings will
return the default, rather then the actual value in the database.
Running db:migrate in the same rake invocation means that rails will not
be re-initialized, and so skip_db will remain true. Site settings
accessed during migrations and fixtures will therefore return incorrect
values.
One example of this is that running bin/rake db:create db:migrate
repeatedly in a development environment will cause the FAQ topic to be
seeded repeatedly, because the seed logic does not have access to the
site setting which stores the already-seeded topic id.
This commit will automatically re-exec the Rake command if any tasks are
specified after `db:create`
This commit updates the `uploads:sync_s3_acls` rake task to accept a
`sync` argument that would run the rake task in a synchronous manner
so that the outcome of running the rake task can easily be determined.
The optimization is not required because `find_each` fetches records in
batches of 1000 and no upload record will have more than 1000 optimized
images.
This change ensures we use the base62 sha1 for videos when quoting
because this is what the composer is used to using. With a valid base62
sha1 the composer already knows how to fetch the placeholder image for
it.
Fallbacks have been created to continue to support the old way as well
as a fix for the old way so that the thumbnail continues to display when
quoting. These fallbacks are in place so that we don't have to rebake
all posts that contain videos. If we ever do that we may remove these
fallbacks.
Followup 23edfe7cc27cd56d5806c965ac52ed2b0394e8b8
When working on changes to any of the lib/stylesheet/*.rb
files, the color_definitions.scss and other stylesheet
caches can be annoyingly persistent.
This commit adds all of these lib files to the `max_file_mtime`
part of the `fs_asset_cachebuster` cache key, so if any of
them are changed then the cache will break, making development
a lot easier.
The group has `grant_trust_level` setting which automatically updates
the trust level when the user is added to the group.
Similarly, when the user is removed from the group, the trust level is
recalculated.
There was a bug that when the trust level was downgraded, the user was
not removed from automatic groups like for example `trust_level_3`.
This reverts commit b9f8a77d9ba5222bbf55172092f0b235b92d1c85.
Reverting while we work on adding error handling. At the moment,
failures are logged, but the process still exits with status=0.
This commit converts the `AdminReport` component, which is quite
high complexity, to gjs. After this initial round, ideally this
component would be broken up into smaller components because it is
getting quite big now.
Also in this commit:
* Add an option to display the report description in a tooltip, which
was
the main way the description was shown until recently. We want to use
this on the dashboard view mostly.
* Move admin report "mode" definitions to the server-side Report model,
inside a `Report::MODES` constant, collecting the modes defined in
various
places in the UI into one place
* Refactor report code to refer to mode definitions
* Add a `REPORT_MODES` constant in JS via javascript.rake and refactor
JS to refer to the modes
* Delete old admin report components that are no longer used
(trust-level-counts, counts, per-day-counts) which were replaced
by admin-report-counters a while ago
* Add a new `registerReportModeComponent` plugin API, some plugins
introduce their own modes (like AI's `emotion`) and components and
we need a way to render them
Rename `min_first_post_typing_time` to `fast_typing_threshold` and
provide admin 4 options:
- disabled
- low - 1 second
- standard - 3 seconds
- high - 5 seconds
Related PRs:
- https://github.com/discourse/discourse-zoom/pull/112
This commit narrows down the list of fonts we offer
in our setup wizard and simplifies things to only
show a single font dropdown. This selection will then
set the `base_font` and `heading_font` site setting to
the same value.
For existing sites that may have set different values,
we will still show 2 dropdowns when visiting the wizard.
We are also changing our default font to the more modern
selection Inter, replacing Arial. Arial is very dependent
on system installed fonts, whereas Inter we can package
to everyone in Discourse.
Finally, for existing sites that have not changed their default
from Arial, we will keep that value via a migration so we do
not surprise site owners with a completely new font.
As we start to translate more pages, we'll need a way for other sites to
link back to our translated topics.
This commit gives us the ability to use the "lang" URL param to define what
language a site should be in.
Related: https://github.com/discourse/discourse-translator/pull/199
Follow-up to 7fc8d74f3eed52116add452b5321b41e02e04499.
This change moves the guardian check for whether an export has been generated too recently to the endpoint handler, since we only want this check to apply when generating an export.
