Commit Graph

1539 Commits

Author SHA1 Message Date
Krzysztof Kotlarek 5551a71c55
FEATURE: increase tag description limit to 1000 (#24561)
Admin can add tag description up to 1000 characters.

Full description is displayed on tag page, however on topic list it is truncated to 80 characters.
2023-11-28 08:45:40 +11:00
Blake Erickson 52617e7425
DEV: Auto link video placeholder posts (#24576)
* DEV: Auto link video placeholder posts

Followup to 91232847e3

Adds a migration to auto-link any video placeholder posts so that upload
references will be created.

Co-authored-by: Jarek Radosz <jradosz@gmail.com>
2023-11-27 13:22:42 -07:00
Sam b3920e05e7
PERF: avoid table scan while performing a very large update (#24525)
We were seeing lots of deadlocks deploying this migration. This improves
the situation in 2 ways.

1. ddl transaction is avoided, so we hold locks for far shorter times
2. we operate in chunks of a maximum of 100_000 posts (though it is heavily filtered down)

* improve code so it is clearer
2023-11-23 18:15:40 +11:00
Blake Erickson c89edd9e86
DEV: Convert email_in_min_trust to groups (#24515)
This change converts the `email_in_min_trust` site setting to
`email_in_allowed_groups`.

See: https://meta.discourse.org/t/283408

- Hides the old setting
- Adds the new site setting
- Add a deprecation warning
- Updates to use the new setting
- Adds a migration to fill in the new setting if the old setting was
  changed
- Adds an entry to the site_setting.keywords section
- Updates tests to account for the new change

After a couple of months we will remove the
`email_in_min_trust` setting entirely.

Internal ref: /t/115696
2023-11-22 18:03:28 -07:00
Blake Erickson 8a45f84277
DEV: Convert approve_new_topics_unless_trust_level to groups (#24504)
* DEV: Convert approve_new_topics_unless_trust_level to groups

This change converts the `approve_new_topics_unless_trust_level` site
setting to `approve_new_topics_unless_allowed_groups`.

See: https://meta.discourse.org/t/283408

- Hides the old setting
- Adds the new site setting
- Add a deprecation warning
- Updates to use the new setting
- Adds a migration to fill in the new setting if the old setting was
  changed
- Adds an entry to the site_setting.keywords section
- Updates tests to account for the new change

After a couple of months we will remove the
`approve_new_topics_unless_trust_level` setting entirely.

Internal ref: /t/115696

* add missing translation

* Add keyword entry

* Add migration
2023-11-22 10:44:59 -07:00
Blake Erickson 447d9b2105
DEV: Convert approve_unless_trust_level to groups (#24357)
This change converts the `approve_unless_trust_level` site setting to
`approve_unless_allowed_groups`.

See: https://meta.discourse.org/t/283408

- Adds the new site setting
- Adds a deprecation warning
- Updates core to use the new settings.
- Adds a migration to fill in the new setting of the old setting was
  changed
- Adds an entry to the site_setting.keywords section
- Updates many tests to account for the new change

After a couple of months we will remove the `approve_unless_trust_level`
setting entirely.

Internal ref: /t/115696
2023-11-21 11:31:42 -07:00
Blake Erickson ef7e5ed9b4
DEV: Rebake posts w/ quotes to update category badge style (#24469)
Posts with quotes need to be rebaked to apply the new category badge
style css.

See: https://meta.discourse.org/t/285705
2023-11-20 14:17:44 -07:00
Penar Musaraj a814348176
DEV: Rename `experimental_passkeys` to `enable_passkeys` (#24349)
Also includes a migration.
2023-11-13 15:04:15 -05:00
Martin Brennan 67ac4c5616
DEV: Move min_trust_level_for_here_mention to group setting (#24263)
c.f. https://meta.discourse.org/t/-/283408
2023-11-09 12:07:01 +10:00
Martin Brennan b90b7ac705
DEV: Move shared_drafts_min_trust_level to group setting (#24257)
No plugins or themes rely on shared_drafts_min_trust_level so we
can just switch straight over to shared_drafts_allowed_groups

c.f. https://meta.discourse.org/t/changes-coming-to-settings-for-giving-access-to-features-from-trust-levels-to-groups/283408
2023-11-07 14:03:25 +10:00
Martin Brennan a86833fe91
FIX: Deleting/recovering a post in topics caused bookmark side effects (#24226)
This commit fixes an issue where when some actions were done
(deleting/recovering post, moving posts) we updated the
topic_users.bookmarked column to the wrong value. This was happening
because the SyncTopicUserBookmarked job was not taking into account
Topic level bookmarks, so if there was a Topic bookmark and no
Post bookmarks for a user in the topic, they would have
topic_users.bookmarked set to false, which meant the bookmark would
no longer show in the /bookmarks list.

To reproduce before the fix:

* Bookmark a topic and don’t bookmark any posts within
* Delete or recover any post in the topic

c.f. https://meta.discourse.org/t/disappearing-bookmarks-and-expected-behavior-of-bookmarks/264670/36
2023-11-07 12:54:05 +10:00
Osama Sayegh 3cadd6769e
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.

Example use cases for the theme settings migration system:

1. Renaming a theme setting.

2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).

3. Altering the format of data stored in a theme setting.

All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.

Usage:

1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.

2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.

3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).

4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.

5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.

6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.

Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:

```js
// File name: 0001-rename-setting.js

export default function migrate(settings) {
  if (settings.has("setting_with_old_name")) {
    settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
  }
  return settings;
}
```

Internal topic: t/109980
2023-11-02 08:10:15 +03:00
Martin Brennan 24e087e2ba
FIX: Typo in migration (#24089)
Should be DB.exec not just exec, silly typo fix for
9db4eaa870
2023-10-25 12:54:25 +10:00
Martin Brennan 9db4eaa870
DEV: Change anonymous_posting_min_trust_level to a group-based setting (#24072)
No plugins or themes rely on anonymous_posting_min_trust_level so we
can just switch straight over to anonymous_posting_allowed_groups

This also adds an AUTO_GROUPS const which can be imported in JS
tests which is analogous to the one defined in group.rb. This can be used
to set the current user's groups where JS tests call for checking these groups
against site settings.

Finally a AtLeastOneGroupValidator validator is added for group_list site
settings which ensures that at least one group is always selected, since if
you want to allow all users to use a feature in this way you can just use
the everyone group.
2023-10-25 11:45:10 +10:00
Sérgio Saquetim 0cfc42e0e6
FEATURE: Add dark mode option for category backgrounds (#24003)
Adds a new upload field for a dark mode category background that will be used as an alternative when Discourse is using a dark mode theme.
2023-10-20 12:48:06 +00:00
Martin Brennan 3cde7f125d
DEV: Remove hashtag autocomplete experimental setting (#23954)
Everything relying on this was removed in
09223e5ae7
2023-10-17 15:05:58 +10:00
Krzysztof Kotlarek c468110929
FEATURE: granular webhooks (#23070)
Before this change, webhooks could be only configured for specific groups like for example, all topic events.

We would like to have more granular control like for example topic_created or topic_destroyed.

Test are failing because plugins changed has to be merged as well:
discourse/discourse-assign#498
discourse/discourse-solved#248
discourse/discourse-topic-voting#159
2023-10-09 03:35:31 +00:00
Alan Guo Xiang Tan 832b3b9e60
FEATURE: Remove support for legacy navigation menu (#23752)
Why this change?

Back in May 17 2023 along with the release of Discourse 3.1, we announced
on meta that the legacy hamburger dropdown navigation menu is
deprecated and will be dropped in Discourse 3.2. This is the link to the announcement
on meta: https://meta.discourse.org/t/removing-the-legacy-hamburger-navigation-menu-option/265274

## What does this change do?

This change removes the `legacy` option from the `navigation_menu` site
setting and migrates existing sites on the `legacy` option to the
`header dropdown` option.

All references to the `legacy` option in code and tests have been
removed as well.
2023-10-09 07:24:10 +08:00
David Taylor fc2e92d423
DEV: Drop post_uploads table (#23673)
The post_uploads table has not been used since 9db8f00b3d
2023-09-27 12:43:19 +01:00
Renato Atilio d93c2cb3d2
FEATURE: site settings to revoke api keys older than a number of days (#23595)
* FEATURE: site settings to revoke api keys older than a number of days
2023-09-15 16:31:29 -03:00
Sérgio Saquetim e03dd76dc6
FEATURE: add outgoing web hooks for Chat messages 2023-09-13 17:31:42 -03:00
OsamaSayegh c1b5faa5fd
SECURITY: Limit name field length of TOTP authenticators and security keys 2023-09-12 15:31:17 -03:00
Ted Johansson f08c6d2756
DEV: Switch over category settings to new table - Part 3 (#20657)
In #20135 we prevented invalid inputs from being accepted in category setting form fields on the front-end. We didn't do anything on the back-end at that time, because we were still discussing which path we wanted to take. Eventually we decided we want to move this to a new CategorySetting model.

This PR moves the require_topic_approval and require_reply_approval from custom fields to the new CategorySetting model.

This PR is nearly identical to #20580, which migrated num_auto_bump_daily, but since these are slightly more sensitive, they are moved after the previous one is verified.
2023-09-12 09:51:49 +08:00
Alan Guo Xiang Tan 26dfb8a489
DEV: Remove chat related migration (#23449)
What motivated this change?

A core migration contains chat related code and this should not be the
case since chat related migration code should live in the chat plugin.

What does this change do?

This change removes the migration which was introduced to keep existing
sites on the legacy navigation menu as well as keep chat disabled when
the defaults for the `navigation_menu` and `chat_enabled` site settings
were flipped. Since this migration doesn't apply to new sites and
the migration has already been introduced for 9 months, it is safe for
us to remove it.
2023-09-08 12:41:56 +08:00
Ted Johansson ede73f923f
DEV: Change fast typer trust level setting to enum type (#23429)
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.
2023-09-06 17:35:11 +08:00
Blake Erickson be32f580ad
DEV: Delete unused site settings (#23353)
In a previous commit these site settings were removed from the codebase
because they were identified as unused settings. This commit removes
these settings from the db in case they existed in the site settings
table.

Follow up to: da389d7844
2023-08-31 18:19:55 -06:00
Daniel Waterworth 80a0d88e4c
FIX: Ensure javascript caches are unique per theme/theme_field (#23126)
We were assuming that this was the case before, but not enforcing it.
2023-08-17 13:57:04 -05:00
Krzysztof Kotlarek f8cd1da92a
FIX: increase sidebar URL limit to 1000 (#23120)
Before this change, sidebar URL had a limit of 200 characters. In some cases it is not enough, therefore it was increased to 1000.
2023-08-17 14:46:24 +10:00
Renato Atilio 840bea3c51
FEATURE: add topic voting webhook event type (#23072)
* FEATURE: add topic upvote webhook event type

* DEV: use a generic event type name for other actions in the same plugin
2023-08-11 13:42:28 -03:00
Ted Johansson 207d983809
FIX: Account for empty string setting values when migrating category settings (#22979)
This migration that populates category setting data from custom fields did not account for the fact that custom fields that expect an integer can still be an empty string. An empty string can't be inserted into the new integer type column.

If the setting is an empty string, cast it to NULL.
2023-08-04 20:57:48 +08:00
Ted Johansson 1f7e5e8e75
DEV: Switch over category settings to new table - Part 2 (#20580)
In #20135 we prevented invalid inputs from being accepted in category setting form fields on the front-end. We didn't do anything on the back-end at that time, because we were still discussing which path we wanted to take. Eventually we decided we want to move this to a new CategorySetting model.

This PR moves the num_auto_bump_daily from custom fields to the new CategorySetting model.

In addition it sets the default value to 0, which exhibits the same behaviour as when the value is NULL.
2023-08-04 10:53:22 +08:00
Ted Johansson c4d0bbce62
DEV: Delete upload references upon deleting draft (#22851)
We currently are accumulating orphaned upload references whenever drafts are deleted.

This change deals with future cases by adding a dependent strategy of delete_all on the Draft#upload_references association. (We don't really need destroy strategy here, since UploadReference is a simple data bag and there are no validations or callbacks on the model.)

It deals with existing cases through a migration that deletes all existing, orphaned draft upload references.
2023-07-31 10:16:23 +08:00
Alan Guo Xiang Tan fe5cd479eb
PERF: Add index on topic_id and created_at to posts table (#22818)
Why this change?

In `PostDestroyer#make_previous_post_the_last_one` and
`Topic.reset_highest`, we have a query that looks something like this:

```
SELECT user_id FROM posts
WHERE topic_id = :topic_id AND
      deleted_at IS NULL AND
      post_type <> 4
      #{post_type}
ORDER BY created_at desc
LIMIT 1
```

However, we currently don't have an index that caters directly to this
query. As a result, we have seen this query performing poorly on large
sites if the PG planner ends up using an index that is suboptimal for
the query.

This commit adds an index to the `posts` table on `topic_id` and then
`created_at`. For the query above, PG will be able to do a backwards
index scan efficiently.
2023-07-27 10:55:10 +08:00
Loïc Guitaut 25138db433 DEV: Promote historic post_deploy migrations
This commit promotes all post_deploy migrations which existed in
Discourse v3.0.0 (timestamp <= 20221212234948)
2023-07-26 10:36:37 +02:00
Ted Johansson 46f21104f4
FIX: Inline deprecated settings in migration file (#22737)
After deleting SiteSetting::ALLOWLIST_DEPRECATED_SITE_SETTINGS, we found out this was referenced in a migration file. This PR inlines the constant into the migration file to prevent it from erroring out.
2023-07-21 12:22:00 +08:00
Selase Krakani 3d554aa10e
FIX: Keep ReviewableQueuedPosts even with user delete reviewable actions (#22501)
Performing a `Delete User`/`Delete and Block User` reviewable actions for a
queued post reviewable from the `review.show` route results in an error
popup even if the action completes successfully.

This happens because unlike other reviewable types, a user delete action
on a queued post reviewable results in the deletion of the reviewable
itself. A subsequent attempt to reload the reviewable record results in
404. The deletion happens as part of the call to `UserDestroyer` which
includes a step for destroying reviewables created by the user being
destroyed. At the root of this is the creator of the queued post
being set as the creator of the reviewable as instead of the system
user.

This change assigns the creator of the reviewable to the system user and
uses the more approapriate `target_created_by` column for the creator of the
post being queued.
2023-07-18 11:50:31 +00:00
Krzysztof Kotlarek bdecd697b9
FIX: more performance improvement for PostAlert job (#22487)
Simplified query based on SiteSettings to join only relevant user_options rows.
In addition, index was added to 'watched_precedence_over_muted` column in `user_options` table to speed up query
2023-07-13 09:02:23 +10:00
Ted Johansson 9915236e42
FEATURE: Warn about outdated translation overrides in admin dashboard (#22384)
This PR adds a feature to help admins stay up-to-date with their translations. We already have protections preventing admins from problems when they update their overrides. This change adds some protection in the other direction (where translations change in core due to an upgrade) by creating a notice for admins when defaults have changed.

Terms:

- In the case where Discourse core changes the default translation, the translation override is considered "outdated".
- In the case above where interpolation keys were changed from the ones the override is using, it is considered "invalid".
- If none of the above applies, the override is considered "up to date".

How does it work?

There are a few pieces that makes this work:

- When an admin creates or updates a translation override, we store the original translation at the time of write. (This is used to detect changes later on.)
- There is a background job that runs once every day and checks for outdated and invalid overrides, and marks them as such.
- When there are any outdated or invalid overrides, a notice is shown in admin dashboard with a link to the text customization page.

Known limitations

The link from the dashboard links to the default locale text customization page. Given there might be invalid overrides in multiple languages, I'm not sure what we could do here. Consideration for future improvement.
2023-07-10 10:06:40 +08:00
Guhyoun Nam b70bd4366b
FEATURE: Separated 'trusted users can edit others' setting for trust level 3 & 4 (#21493) 2023-07-07 10:48:14 -05:00
Krzysztof Kotlarek 134dcdd63a
FEATURE: allow user to override watched_precedence_over_muted setting (#22340)
Recently, site setting watched_precedence_over_muted was introduced - https://github.com/discourse/discourse/pull/22252

In this PR, we are allowing users to override it. The option is only displayed when the user has watched categories and muted tags, or vice versa.
2023-07-04 15:08:29 +10:00
Alan Guo Xiang Tan aef7c2fe8f
UX: Use modals to edit categories and tags that appear in sidebar (#22295)
Why this change?

We are currently not fully satisfied with the current way to edit the
categories and tags that appears in the sidebar where the user is
redirected to the tracking preferences tab in the user's profile causing
the user to lose context of the current page. In addition, the dropdown
to select categories or tags limits the amount of information we can
display.

Since editing or adding a custom categories section is already using a
modal, we have decided to switch editing the categories and tags that
appear in the sidebar to use a modal as well.

This commit removes the `new_edit_sidebar_categories_tags_interface_groups` site setting and
make the modals the default for all users.
2023-06-28 07:20:31 +08:00
Jarek Radosz 1027a8a2d7
DEV: Move migration to the correct directory (#22309)
db/migrate/db/migrate ain't it :P
2023-06-27 23:01:39 +02:00
Roman Rizzi f4e7a80600
DEV: Cache summarization strategy results. (#22230)
Updates the interface for implementing summarization strategies and adds a cache layer to summarize topics once.

The cache stores the final summary and each chunk used to build it, which will be useful when we have to extend or rebuild it.
2023-06-27 11:44:34 -03:00
Osama Sayegh b27e12445d
FEATURE: Split navigation preference for count and behavior of sidebar links (#22203)
This PR splits up the preference that controls the count vs dot and destination of sidebar links, which is really hard to understand, into 2 simpler checkboxes:

The new preferences/checkboxes are off by default, but there are database migrations to switch the old preference to the new ones so that existing users don't have to update their preferences to keep their preferred behavior of sidebar links when this changed is rolled out.

Internal topic: t/103529.
2023-06-22 19:04:13 +03:00
Krzysztof Kotlarek 959c50001d
FIX: rename everything link to topics (#22076)
Rename everything link in community sidebar section to topics, which is
a bit more descriptive.
2023-06-15 11:36:38 +10:00
Krzysztof Kotlarek 2effcaa0f9
FIX: Update sidebar to be navigation menu (#22101)
Communities can use sidebar or header dropdown, therefore navigation menu is a better name settings in 2 places:

- Old user sidebar preferences;
- Site setting about default tags and categories.
2023-06-15 09:31:28 +10:00
Martin Brennan 44446afe58
FEATURE: Use new hashtag autocomplete system on all sites (#21788)
Followup to:

* 7c97548159
* 0b3cf83e3c
* eae47d82e2

This commit enables the no-longer-experimental hashtag autocomplete changes
for all sites. It is now at a point where it is ready to be promoted
to the only way, and following this commit all old hashtag code
will be deleted

c.f. https://meta.discourse.org/t/hashtags-are-getting-a-makeover/248866
2023-06-07 11:11:39 +10:00
Martin Brennan 54db01d156
DEV: Delete old personal message settings (#21381)
Followup to e62e93f

Both enable_personal_messages and min_trust_to_send_messages
have been deprecated for a long time now, they can be deleted.
2023-05-23 09:58:58 +02:00
Bianca Nenciu 899eb96798
FEATURE: Enable user tips by default (#21341) 2023-05-08 20:33:08 +03:00
Krzysztof Kotlarek 709fa24558
DEV: move sidebar community section to database (#21166)
* DEV: move sidebar community section to database

Before, community section was hard-coded. In the future, we are planning to allow admins to edit it. Therefore, it has to be moved to database to `custom_sections` table.

Few steps and simplifications has to be made:
- custom section was hidden behind `enable_custom_sidebar_sections` feature flag. It has to be deleted so all forums, see community section;
- migration to add `section_type` column to sidebar section to show it is a special type;
- migration to add `segment` column to sidebar links to determine if link should be displayed in primary section or in more section;
- simplify more section to have one level only (secondary section links are merged);
- ensure that links like `everything` are correctly tracking state;
- make user an anonymous links position consistence. For example, from now on `faq` link for user and anonymous is visible in more tab;
- delete old community-section template.
2023-05-04 12:14:09 +10:00