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.
The GDPR requires all users to be able to export their data, or request an export of their data. This is fine for active users as we have a data export button on user profiles, but suspended users have no way of accessing the data export function, and the workaround for admins to export data for suspended users involves temporarily unsuspending them, then impersonating the user to export the data as them.
Since suspended users no longer have access to their account, we can safely assume that the export request will be coming via a medium outside of Discourse (eg, email). This change is built with this workflow in mind.
This change adds a new "User exports" section to the admin user page, allowing admins to start a new export, and to download the latest export file.
We're embarking on a project for overhauling the color palette and theme
systems in Discourse. As part of this project, we're making each color
palette include light and dark modes instead of the status quo of
requiring 2 separate color palettes to implement light and dark modes.
This commit is a first step towards that goal; it adds a code path for
generating and serving `color_definitions` stylesheets using the
built-in dark variant of a color palette. All of this code path is
behind a default-off site setting `use_overhauled_theme_color_palette`,
so there's no change in behavior unless the setting is enabled.
Internal topic: t/141467.
In https://github.com/discourse/discourse-fonts/pull/15 we are
introducing special font properties for certain fonts,
specifically the `font-variation-settings` and `font-feature-settings`.
For now this will only apply to Inter, but we may do it for other
fonts in future.
This commit makes it so the color_definitions.css file includes
these special properties for each font, either defined on the
root `html` element for the body font or on the `h1-h6` elements
for the heading font. This is done in this way because defining
them on `@font-face` is ignored by the browser.
This also ensures special CSS classes for the wizard container
e.g. wizard-container-font-FONTID are defined, this is so we can
use these special properties scoped to the font selected in the
wizard, which will affect the way the canvas preview is rendered.
Here is an example of before/after with special properties applied to
Inter,
in this case:
```css
font-variation-settings: 'opsz' 28;
font-feature-settings: 'calt' 0, 'ccmp' 0, 'ss02' 1;
```
Previously this setting would only control values received in an 'email'
field from an identity provider. This commit extends it, so that it also
applies to email-like content in other fields. This provides improved
protections against partial email addresses being leaked
In a PM, if a user has made a post, and is later removed from the PM, they can still edit their own post. This can be done either if they happen to have a composer open in an active tab, or by just manually sending an HTTP request.
The post guardian is missing a basic check, can_see_post_topic? when we determine whether a user can edit a post or not. This basic check is already in place when we determine whether a user can see the post in the first place.
This PR adds in the missing check, so that if the user tries to edit their post after being removed, they'll receive a 403.
It also adds a MessageBus message scoped to the affected user and topic when they are removed from the PM, which will redirect them to their inbox. This helps avoid a stale tab where they are still in the PM which they by right can now no longer see.
When secure uploads are enabled, we have to attach the images in the
digest so they can show up in the email.
However, we send attaching all the attachments, including "files" and
"media".
This ensures we only attach images when sending a digest.
Internal t/144542
The new site setting `allow_anonymous_and_tl0_to_flag_illegal` allows
tl0 users to flag illegal content. In addition, anonymous users are
instructed on how to flag illegal content by sending emails.
Also `email_address_to_report_illegal_content` setting is added. If not
provided, then the site contact email is used.
Followup 72c4709a5ab26f00e32b65d874b3a206d679181e
Previously we made a fix to allow skip validations when tagging
a topic via TopicCreator. However, this flow also skips a lot of
the more in-depth work on tags we do when creating a topic, like
processing tag synonyms. When approving reviewable queued posts,
we skip validations, so this would cause an issue where a topic
was approved and the tag synonyms weren't applied.
This commit changes the logic so we attempt the more complete
`DiscourseTagging.tag_topic_by_names` call first and if this fails
and skip validations is on, then we do
`DiscourseTagging.add_or_create_tags_by_name`.
This at least gives a chance for the full workflow to work first.
Related: https://github.com/discourse/discourse/pull/30535
In the PR above, the [content-disposition
header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
was removed for all non-svg files due to the "attachment" keyword added
to them, causing files to be downloaded instead of opening in a new tab
when requested. When removing that, it also removed the filename
attribute attached to s3 uploads.
After some testing, it turns out that `filename` is also respected when
next to `inline`, despite it not being obvious [in
docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#syntax).
This commit adds inline+filename so that users can still download files
and have filenames be respected instead of using the s3 hash.
```http
<!-- mdn docs -->
Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="file name.jpg"
Content-Disposition: attachment; filename*=UTF-8''file%20name.jpg
<!-- this actually works too -->
Content-Disposition: inline; filename="file name.jpg"
```
The `key` provided in the S3 inventory file will esacpe any special
characters in the filename of the key so we need to unescape. Otherwise,
uploads with extensions that conatins special characters will fail to
match records which we insert into the temporary table based off the
s3 inventory file.
* Do not offer "categories with latest" option anymore, it does
not look good with our default Sidebar selection
* Display a sensible item in the dropdown if the admin has not
chosen hot, latest, or category_boxes as the homepage style,
before it was broken. Now we show Custom with a little blurb
about whether topics or categories are shown, and what the landing
page is
Both heading_font and body_font should not allow
additional user-defined values, these are lists with
predefined choices. The UI already prevents this
because the font selector dropdown is unique, but
we want to make sure the setting definition reflects
this too.
This change allows controllers that construct TopicQuery parameters, to pass per_page into the TopicQuery constructor as an option. I can't see why this shouldn't be a public param, so long as we properly validate the value!
Internal discussion at t/145686.
This is a revert of 92793c5b73871ba84b024c2ce50055a0776f1ba6.
Following on from discussions after the previous commit, it became evident that it was only a small step towards solving the larger problem of finding site settings in a reliable fashion across multiple languages.
This is going to take more thought and discussion, and since the changes introduced in the previous commit are effectively non functional without additional work, I'm going to revert it for now.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/(lib|utils)/*` into
`discourse/lib/*`, adds shims for the imports, and updates existing
uses in core.
When we send an email notification to a user, we always include a link
that will allow them unsubscribe to these emails.
If the user reply to the email notification, the link to unsubscribe
might still be present in the final post (often in the elided part).
Since those links do not require authentication to unsubscribe a user
(this is a feature, not a bug), we would like to avoid showing them to
other users on Discourse.
(If such an email is forwarded elsewhere, then it's totally out of our
control.)
This commmit ensures we always strip those unsubscribe links from any
incoming email to avoid making it easier to unsubscribe another user.
Since the format we use for those links might be similar to the ones
used by other applications, the regular expression used to match those
links uses the absolute URL of the Discourse (aka.
`Discourse.base_url`).
This commit introduces a new rake task that can be used in situations where a community receives a large number of flags/reports and needs a quick way to handle all of those pending reports. Usage instructions are included in the rake task source code.
Internal topic: t/145475.
This removes some longstanding Safari iOS positioning hacks and refactors the mobile positioning strategy across Safari, Chrome and Firefox. See PR descriptions for more details.
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Follow-up to 5a55c9062a
There are many scenarios that can result in creating a `ReviewableQueuedPost` record, however in the original commit we only added once scenario to the populate rake task. This commit adds the remaining scenarios to the rake task.
Previously we would enqueue sidekiq jobs like `PostProcessCooked` **before** triggering the `topic_created` and `post_created` DiscourseEvents. That means that, depending on the speed/availability of Sidekiq, PostProcessCooked might start running on another host before the DiscourseEvents have been executed.
This commit moves the event triggers before enqueue_jobs, so that ordering is guaranteed to be consistent, regardless of Sidekiq performance.
Following on from f369db5ae9a29a23299dff5f14768167230b0b79, we need to apply a similar fix to inline oneboxes, since they use a different code path to retrieve the onebox provider data.
This change ensures the Accept-Language header is sent by inline onebox requests, too.
Following on from f369db5ae9a29a23299dff5f14768167230b0b79, this change adds the ability to choose a custom locale to send to onebox providers.
If this setting is left blank, it will fall back to using default_locale.
Onebox embeds currently default to accepting any language response from the destination, which can have some surprising behaviour. For example the `curl` equivalent of what Onebox does:
```
% curl -si -H "Accept-Language: *" 'https://developer.android.com/studio' | grep location:
location: /studio?hl=hi
```
This PR uses the value of `SiteSetting.default_locale` to populate the `Accept-Language` header, falling back to English if that isn't available, then finally accepting whatever language the destination makes available.
The chat emoji picker is renamed emoji-picker, and the old emoji-picker is removed.
This commit doesn't attempt to fully rework a new emoji-picker but instead tries to migrate everything to one picker (the chat one) and add small changes.
Other notable changes:
- all the favorite emojis code has been mixed into one service which is able to store one state per context, favorites emojis will be stored for all topics, and for each chat channel. Meaning that if you always use a specific emoji in a channel, it will only show as favorite emoji in this channel.
- a lot of static code has been removed which should improve initial load perf of discourse. Initially this code was around to improve the performance of the emoji picker rendering.
- the emojis are now stored, once the full list has been loaded, if you close and reopen the picker it won't have to load them again.
List of components:
- `<EmojiPicker />` will render a button which will open a dropdown
- `<EmojiPickerContent />` represents the content of the dropdown alone, it's useful when you want to render a picker from an action which is not the default picker button
- `<EmojiPickerDetached />` just a simple wrapper over `<EmojiPickerContent />` to make it easier to use it with `this.menu.show(...)`
---------
Co-authored-by: Renato Atilio <renatoat@gmail.com>
