Many site settings can be distructive or have huge side-effects
for a site that the admin may not be aware of when changing it.
This commit introduces a `requires_confirmation` attribute that
can be added to any site setting. When it is true, a confirmation
dialog will open if that setting is changed in the admin UI,
optionally with a custom message that is defined in client.en.yml.
If the admin does not confirm, we reset the setting to its previous
clean value and do not save the new value.
Some tooling may rely on an unsafe-none cross origin opener policy to work. This change adds a hidden site setting that can be used to list referrers where we add this header instead of the default one configured in cross_origin_opener_policy_header.
For Topic Embeds, we would prefer <article> to be the main article in a topic, rather than a table cell <td> with potentially a lot of data. However, in an example URL like here, the table cell (the very large code snippet) is seen as the Topic Embed's article due to the determined content weight by the Readability library we use.
In the newly released 0.7.1 cantino/ruby-readability#94, the library has a new option to exclude the library's default <td> element into content weighting. This is more in line with the original library where they only weighted <p>. So this PR excludes the td, as seen in the tests, to allow the actual article to be seen as the article. This PR also adds the details tag into the allow-list.
Followup 6b872c4c53
Even though we were showing a validation error for a reject
reason that was too long, we were still sending an email and
doing other operations on the user which we are rejecting.
This commit fixes this by validating the reviewable model
before attempting to do anything else after the reason is set.
A new admin setting called `enforce_second_factor_on_external_auth`. It allows users to authenticate using external providers even when 2FA is forced with `enforce_second_factor` site setting.
* UX: Add new preview links to Popular Themes
Replace previews for 'Discourse' based ones
* prettier
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
* Revert "FIX: Set `override_level` on Logster loggers (#27519)"
This reverts commit c1b0488c54.
* Revert "DEV: Make parameters optional to all FakeLogger methods"
This reverts commit 3318dad7b4.
* Revert "FIX: Remove references to `Rails.logger.chained`"
This reverts commit f595d599dd.
* Revert "DEV: Upgrade Rails to 7.1"
This reverts commit 081b00391e.
There is currently only one scenario when both the composer and a user card would be present at the same time:
if you have the composer open and then you click on something outside it that triggers a card. Which implies intent to see the card (unobstructed by the composer 😉)
The reverse doesn't happen because opening the composer would close an existing user card.
In theory there's also displaying a user card by clicking on a mention in composer's preview but that functionality is currently broken (and this PR is a prerequisite 😉)
---
I changed `.user-card, .group-card` to `.fk-d-menu[data-identifier="card"]` because that regressed when we moved user cards to float-kit – they are nested inside `.fk-d-menu` so its `z-index` is now important (effectively the cards had `z-index: z("dropdown")` instead of `z("usercard")`)
Wasn't quite handling the cases where a closing bracket `]` was used in the value of one of the attributes.
```markdown
[chat quote=user channel="[broken]"]
```
Would not be correctly parsed because we would _greedily_ use the first `]` as the end of the tag even though it might be a valid character when inside proper quotes.
c39a4de139/app/assets/javascripts/discourse-markdown-it/src/features/bbcode-block.js (L62)
Re-wrote the `parseBBCodeTag` to properly handle the following cases
- A closing tag (aka `[/name]`) which are easy since they don't have any attributes
- An old `[quote=...]` format we used that doesn't uses quotes but still has various attributes of the form `key:value`
- All three valid BBCode opening tag formats we support
- `[name]` without any attributes
- `[name=foo]` with a default value
- `[name foo=bar]` with some attributes
Ended up having to fix/rewrite the few bbcode rules that were using the `parseBBCodeTag` function, namely `d-wrap` and `discourse-local-dates`.
While working on this, I think I also found a way to get rid the of shims we had in place so that plugins could use the `parseBBCodeTag` function.
Reference - https://meta.discourse.org/t/having-a-right-bracket-in-a-channel-name-breaks-all-quotes-from-that-channel/308439
* Load search results in displayed order so that when more categories are loaded on scroll, they appear at the end,
* Limit the number of subcategories that are shown per category and display 'show more' links,
This allows modifyClass to be used like this:
```
api.modifyClass(
"model:topic",
(Superclass) =>
class extends Superclass {
static someStaticMethod() {
return `${super.someStaticMethod()} modified`;
}
someFunction() {
return `${super.someFunction()} modified`;
}
get someGetter() {
return `${super.someGetter} modified`;
}
}
);
```
One limitation, which is the same as the old object-literal syntax, is that native class fields and constructors cannot be modified.
`@tracked` properties can be overriden, because the decorator turns them into getters/setters.
There is no need to pass a `pluginId` any more. Changes are automatically rolled back as part of test cleanup 🎉
This commit adds ability to fetch a subset of site settings from the `/admin/site_settings` endpoint so that it can be used in all places where the client app needs access to a subset of the site settings.
Additionally, this commit also introduces a new service class called `UpdateSiteSetting` that encapsulates all the logic that surrounds updating a site setting so that it can be used to update site setting(s) anywhere in the backend. This service comes in handy with, for example, the controller for the flags admin config area which may need to update some site settings related to flags.
Internal topic: t/130713.
* use `TrackedSet` instead of `@tracked []`
* correct return type annotations
* move code to outside Promise blocks where possible
* fix an outdated comment
When we turn on settings automatically for customers,
we sometimes use `.set_and_log` which will make a staff
action log for the site setting change. This is fine, but
there is no context for customers.
This change allows setting a message with `.set_and_log`, which
will be stored in the `details` column of the staff action log
created, which will show up on `/admin/logs/staff_action_logs`
---------
Co-authored-by: Kelv <kelv@discourse.org>
This commit introduces the `valueTransformer`API to safely override values defined in Discourse.
Two new plugin APIs are introduced:
- `addValueTransformerName` which allows plugins and theme-components to add a new valid transformer name if they want to provide overridable values;
- `registerValueTransformer` to register a transformer to override values.
It also introduces the function `applyValueTransformer` which can be imported from `discourse/lib/transformer`. This function marks the desired value as overridable and applies the transformer logic.
How does it work?
## Marking a value as overridable:
To mark a value as overridable, in Discourse core, first the transformer name must be added to `app/assets/javascripts/discourse/app/lib/transformer/registry.js`. For plugins and theme-components, use the plugin API `addValueTransformerName` instead.
Then, in your component or class, use the function `applyValueTransformer` to mark the value as overridable and handle the logic:
- example:
```js
export default class HomeLogo extends Component {
@service session;
@service site;
...
get href() {
return applyValueTransformer("home-logo-href", getURL("/"));
}
```
## Overriding a value in plugins or themes
To override a value in plugins, themes, or TCs use the plugin API `registerValueTransformer`:
- Example:
```js
withPluginApi("1.34.0", (api) => {
api.registerValueTransformer("example-transformer", ({ value }) => {
return "new-value";
});
});
```
Follow up to: #27444. In that PR we added a new integer column for UserField#field_type and populated the data based on the old text field.
In this PR we drop the old text column and swap in the new integer (enum) column.
Currently this column is a text column, but by right should only take on one of the values text, confirm, dropdown, multiselect. We can convert this to an ActiveRecord enum instead.
This PR adds a new integer column (field_type_enum) and populates it based on the existing text column (field_type) and adds an alias to replace the latter with the former.
After working on the Webhook events filter by Status, I noticed that the 'Delivered' and 'Failed' options do not take the status param when loading more than fifty Webhook events. It causes to load all Webhook events regardless of its status after the first load.
This PR is adding webhook events status for the filter to the param when loading more than fifty Webhook events.
Jarek Radosz
Ted Johansson
Martin Brennan
Natalie Tay
Krzysztof Kotlarek
JimmyJammyDodger
Kris
Penar Musaraj
Loïc Guitaut
Régis Hanol
Kelv
dependabot[bot]
Daniel Waterworth
David Taylor
Osama Sayegh
Mark Reeves
Jan Cernik
Joffrey JAFFEUX
Sérgio Saquetim
Guhyoun Nam