Commit Graph

400 Commits

Author SHA1 Message Date
Osama Sayegh
2ffe413b0b
FEATURE: Enable the new /about page for everyone ()
This commit removes the feature flag for the new /about page, enabling it for all sites, and removes the code for old the /about page.

Internal topic: t/140413.
2024-10-29 18:40:11 +03:00
Krzysztof Kotlarek
0839bce7b6
DEV: allow the plugin to register valid site setting areas ()
In this PR, we defined the ability to group site settings by area - https://github.com/discourse/discourse/pull/28570

Plugins should be able to register in their own areas.
2024-10-29 09:40:31 +11:00
David Taylor
7dc60d0c99
DEV: Remove discourse-encrypt from core CI suite ()
This plugin is prone to causing flaky test runs, and is in the process of being deprecated
2024-10-16 11:47:02 +01:00
Alan Guo Xiang Tan
322a3be2db
DEV: Remove logical OR assignment of constants ()
Constants should always be only assigned once. The logical OR assignment
of a constant is a relic of the past before we used zeitwerk for
autoloading and had bugs where a file could be loaded twice resulting in
constant redefinition warnings.
2024-10-16 10:09:07 +08:00
Juan David Martínez Cubillos
d3f09f8f61
DEV: Add discourse-hcaptcha plugin to the metadata list of official plugins () 2024-10-11 15:35:12 -05:00
Martin Brennan
2193667e1f
FIX: Plugin JS failing to load would break admin interface ()
If a plugin's JS fails to load for some reason, most commonly
ad blockers, the entire admin interface would break. This is because
we are adding links to the admin routes for plugins that define
them in the sidebar.

We have a fix for this already in the plugin list which shows a warning
to the admin. This fix just prevents the broken link from rendering
in the sidebar if the route is not valid.
2024-10-11 09:26:10 +10:00
Jarek Radosz
02f8396cfc
DEV: Remove register_color_scheme api ()
This was added 10 years ago, but currently there's not a single use in our public and private plugins and no reference in third-party plugins on github
2024-09-06 17:26:53 +02:00
Osama Sayegh
a23773f83d
DEV: Deprecate show_in_ui argument of the register_stat API ()
We need to start printing deprecation notices when the `show_in_ui` argument is used because it works only for the old about page which will be removed soon. For the new about page, we've introduced a new API `addAboutPageActivity` which is more flexible than a true/false argument on the server side.

Internal topic: t/136551.
2024-09-04 19:58:14 +03:00
Osama Sayegh
db6eff7be9
DEV: Allow custom site activity items in the new /about page ()
This commit introduces a new frontend API to add custom items to the "Site activity" section in the new /about page. The new API is called `addAboutPageActivity` and it works along side the `register_stat` serve-side API which serializes the data that the frontend API consumes. More details of how the two APIs work together is in the JSDoc comment above the API function definition.

Internal topic: t/128545/9.
2024-08-20 16:16:05 +03:00
Sérgio Saquetim
366dfec16c
DEV: Add plugin API to perform actions when the plugin is turned on/off ()
Co-authored-by: David Taylor <david@taylorhq.com>
2024-07-31 15:38:10 -03:00
Isaac Janzen
b3e0e920ed
DEV: Support adding a custom filter on /filter ()
# Context

Currently there is no way to add a custom filter to the experimental `/filter` endpoint. While you can implement a custom `status:` there is no way to include the user's input in a custom query. 

# PR

This PR adds the ability to implement a custom filter. eg. `CUSTOM_FILTER:foo`

- Add `add_filter_custom_filter` for extension
- Add specs
2024-07-17 11:36:38 -05:00
Loïc Guitaut
5ec227334a FIX: Don’t list values from disabled plugins
Currently, when a plugin registers a new reviewable type or extends a
list method (through `register_reviewble_type` and `extend_list_method`
respectively), the new array is statically computed and always returns
the same value. It will continue to return the same value even if the
plugin is disabled (it can be a problem in a multisite env too).

To address this issue, this patch changes how `extend_list_method`
works. It’s now using `DiscoursePluginRegistry.define_filtered_register`
to create a register on the fly and store the extra values from various
plugins. It then combines the original values with the ones from the
registry. The registry is already aware of disabled plugins, so when a
plugin is disabled, its registered values won’t be returned.
2024-07-11 10:51:48 +02:00
Loïc Guitaut
301713ef96 DEV: Upgrade the MessageFormat library (JS)
This patch upgrades the MessageFormat library to version 3.3.0 from
0.1.5.

Our `I18n.messageFormat` method signature is unchanged, and now uses the
new API under the hood.

We don’t need dedicated locale files for handling pluralization rules
anymore as everything is now included by the library itself.

The compilation of the messages now happens through our
`messageformat-wrapper` gem. It then outputs an ES module that includes
all its needed dependencies.

Most of the changes happen in `JsLocaleHelper` and in the `ExtraLocales`
controller.

A new method called `.output_MF` has been introduced in
`JsLocaleHelper`. It handles all the fetching, compiling and
transpiling to generate the proper MF messages in JS. Overrides and
fallbacks are also handled directly in this method.

The other main change is that now the MF translations are served through
the `ExtraLocales` controller instead of being statically compiled in a
JS file, then having to patch the messages using overrides and
fallbacks. Now the MF translations are just another bundle that is
created on the fly and cached by the client.
2024-07-10 09:51:25 +02:00
Natalie Tay
27eea3250c
DEV: Fix deprecation typo () 2024-07-09 17:46:10 +08:00
Keegan George
ea58140032
DEV: Remove summarization code () 2024-07-02 08:51:47 -07:00
Jarek Radosz
251b3a5c47
DEV: Remove discourse-moderator-attention ()
…from the official plugins list. It's archived now.
2024-06-19 13:26:57 +02:00
JimmyJammyDodger
712f726764
DEV: Remove non-official plugins from metadata ()
Removes BCC, Shared Edits, and Linkedin-auth from the official plugin list. 

Also corrects some alphabetising
2024-06-10 10:40:36 +01:00
Loïc Guitaut
2a28cda15c DEV: Update to lastest rubocop-discourse 2024-05-27 18:06:14 +02:00
Juan David Martínez Cubillos
7992d7a65a
DEV: Refactor to add Custom emoji sanitization ()
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
2024-05-27 15:24:55 +02:00
Krzysztof Kotlarek
cfbbfd177c
DEV: move post flags into database ()
This is preparation for a feature that will allow admins to define their custom flags. Current behaviour should stay untouched.
2024-05-23 12:19:07 +10:00
Ted Johansson
32aaf2e8d3
DEV: Remove deprecated AuthProvider#enabled_setting= ()
AuthProvider#enabled_setting=, used primarily by plugins, has been deprecated since version 2.9, in favour of Authenticator#enabled?. This PR confirms we are seeing no more usage and removes the method.
2024-05-20 18:10:15 +08:00
Régis Hanol
803c275bd7 DEV: add support for adding custom status filter
Those can be used in the /filter routes.
2024-04-26 14:04:03 +02:00
Osama Sayegh
3d4faf3272
FEATURE: Merge discourse-automation ()
Automation (previously known as discourse-automation) is now a core plugin.
2024-04-03 18:20:43 +03:00
Ted Johansson
0c875cb4d5
DEV: Make problem check registration more explicit ()
Previously the problem check registry simply looked at the subclasses of ProblemCheck. This was causing some confusion in environments where eager loading is not enabled, as the registry would appear empty as a result of the classes never being referenced (and thus never loaded.)

This PR changes the approach to a more explicit one. I followed other implementations (bookmarkable and hashtag autocomplete.) As a bonus, this now has a neat plugin entry point as well.
2024-03-28 14:00:47 +08:00
Martin Brennan
8e08a3b31f
DEV: Use caller for plugin_file_from_fixtures ()
Followup 0bbca318f2,
rather than making developers provide the plugin path
name (which may not always be the same depending on
dir names and git cloning etc) we can infer the plugin
dir from the caller in plugin_file_from_fixtures
2024-03-27 14:12:51 +11:00
Martin Brennan
70f7c0ee6f
FEATURE: More flexible admin plugin config nav definition ()
This commit changes the API for registering the plugin config
page nav configuration from a server-side to a JS one;
there is no need for it to be server-side.

It also makes some changes to allow for 2 different ways of displaying
navigation for plugin pages, depending on complexity:

* TOP - This is the best mode for simple plugins without a lot of different
  custom configuration pages, and it reuses the grey horizontal nav bar
  already used for admins.
* SIDEBAR - This is better for more complex plugins; likely this won't
  be used in the near future, but it's readily available if needed

There is a new AdminPluginConfigNavManager service too to manage which
plugin the admin is actively viewing, otherwise we would have trouble
hiding the main plugin nav for admins when viewing a single plugin.
2024-03-21 13:42:06 +10:00
Jarek Radosz
6d137a41c2
DEV: Remove the last transpile_js mentions () 2024-03-20 15:32:37 +01:00
Martin Brennan
4e7a75a7ec
DEV: Single admin plugin page for consistent admin plugin UX ()
This commit adds new plugin show routes (`/admin/plugins/:plugin_id`) as we move
towards every plugin having a consistent UI/landing page.

As part of this, we are introducing a consistent way for plugins
to show an inner sidebar in their config page, via a new plugin
API `register_admin_config_nav_routes`

This accepts an array of links with a label/text, and an
ember route. Once this commit is merged we can start the process
of conforming other plugins to follow this pattern, as well
as supporting a single-page version of this for simpler plugins
that don't require an inner sidebar.

Part of /t/122841 internally
2024-03-13 13:15:12 +10:00
David Taylor
1df9186526
FIX: Plugin image assets in production ()
Followup to 1757a688c4
2024-02-02 19:06:16 +00:00
David Taylor
1757a688c4
DEV: Remove sprockets from plugin 'extra js' pipeline ()
JS assets added by plugins via `register_asset` will be outside the `assets/javascripts` directory, and are therefore exempt from being transpiled. That means that there isn't really any need to run them through DiscourseJsProcessor. Instead, we can just concatenate them together, and avoid the need for all the sprockets-wrangling.

This commit also takes the opportunity to clean up a number of plugin-asset-related codepaths which are no longer required (e.g. globs, handlebars)
2024-02-01 11:48:31 +00:00
Sérgio Saquetim
d34a7916c0
DEV: Move Plugin::Instance.register_search_group_query_callback out of protected () 2024-01-25 13:36:43 -03:00
Martin Brennan
628873de24
FIX: Sort plugins by their setting category name ()
Some plugins have names (e.g. discourse-x-yz) that
are totally different from what they are actually called,
and that causes issues when showing them in a sorted way
in the admin plugin list.

Now, we should use the setting category name from client.en.yml
if it exists, otherwise fall back to the name, for sorting.
This is what we do on the client to determine what text to
show for the plugin name as well.
2024-01-08 09:57:25 +10:00
Martin Brennan
7fcef5f2f9
FIX: Show admin plugin route sub-links in sidebar ()
This changes the Plugins link in the admin sidebar to
be a section instead, which then shows all enabled plugin
admin routes (which are custom routes some plugins e.g.
chat define).

This is done via adding some special preloaded data for
all controllers based on AdminController, and also specifically
on Admin::PluginsController, to have the routes loaded without
additional requests on page load.

We just use a cog for all the route icons for now...we don't
have anything better.
2023-12-21 11:37:20 +10:00
Andrei Prigorshnev
6e2201135f
DEV: Introduce plugin API for getting stats ()
Before, when needed to get stats in a plugin, we called Core classes directly. 
Introducing plugin API will decouple plugins from Core and give as more freedom 
in refactoring stats in Core. Without this API, I wasn't able to do all refactorings 
I wanted when working on d91456f.
2023-12-15 23:47:20 +04:00
Jarek Radosz
694b5f108b
DEV: Fix various rubocop lints ()
These (21 + 3 from previous PRs) are soon to be enabled in rubocop-discourse:

Capybara/VisibilityMatcher
Lint/DeprecatedOpenSSLConstant
Lint/DisjunctiveAssignmentInConstructor
Lint/EmptyConditionalBody
Lint/EmptyEnsure
Lint/LiteralInInterpolation
Lint/NonLocalExitFromIterator
Lint/ParenthesesAsGroupedExpression
Lint/RedundantCopDisableDirective
Lint/RedundantRequireStatement
Lint/RedundantSafeNavigation
Lint/RedundantStringCoercion
Lint/RedundantWithIndex
Lint/RedundantWithObject
Lint/SafeNavigationChain
Lint/SafeNavigationConsistency
Lint/SelfAssignment
Lint/UnreachableCode
Lint/UselessMethodDefinition
Lint/Void

Previous PRs:
Lint/ShadowedArgument
Lint/DuplicateMethods
Lint/BooleanSymbol
RSpec/SpecFilePathSuffix
2023-12-06 23:25:00 +01:00
Martin Brennan
c58cd697d2
FIX: Further improvements for plugin list ()
Followup e37fb3042d

* Automatically remove the prefix `Discourse ` from all the plugin titles to avoid repetition
* Remove the :discourse_dev: icon from the author. Consider a "By Discourse" with no labels as official
* We add a `label` metadata to plugin.rb
  * Only plugins made by us in `discourse` and `discourse-org` GitHub organizations will show these in the list
* Make the plugin author font size a little smaller
* Make the commit sha look like a link so it's more obvious it goes to the code

Also I added some validation and truncation for plugin metadata
parsing since currently you can put absolutely anything in there
and it will show on the plugin list.
2023-11-30 10:53:17 +10:00
Daniel Waterworth
eef93ac926
DEV: Allow setting max_length for field types using the plugin API () 2023-11-29 14:17:12 -06:00
Martin Brennan
09c446c1ae
FIX: Handle missing git repo details in plugin list ()
Followup to e37fb3042d,
in some cases we cannot get git information for the
plugin folder (e.g. permission issues), so we need
to only try and get information about it if
commit_hash is present.
2023-11-24 12:08:10 +10:00
Martin Brennan
e395e5e002
FIX: Use plugin category name for plugin list ()
Followup to e37fb3042d

Some plugins like discourse-ai and discourse-saml do not
nicely change from kebab-case to Title Case (e.g. Ai, Saml),
and anyway this method of getting the plugin name is not
translated either.

Better to use the plugin setting category if it exists,
since that is written by a human and is translated.
2023-11-23 08:40:55 +10:00
Martin Brennan
e37fb3042d
FEATURE: Admin plugin list redesign ()
* Remove checkmark for official plugins
* Add author for plugin, which is By Discourse for all discourse
  and discourse-org github plugins
* Link to meta topic instead of github repo
* Add experimental flag for plugin metadata and show this as a
  badge on the plugin list if present

---------

Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
2023-11-21 09:37:11 +10:00
Andrei Prigorshnev
d91456fd53
DEV: Ability to collect stats without exposing them via API ()
This adds the ability to collect stats without exposing them 
among other stats via API.

The most important thing I wanted to achieve is to provide 
an API where stats are not exposed by default, and a developer 
has to explicitly specify that they should be 
exposed (`expose_via_api: true`). Implementing an opposite 
solution would be simpler, but that's less safe in terms of 
potential security issues. 

When working on this, I had to refactor the current solution. 
I would go even further with the refactoring, but the next steps 
seem to be going too far in changing the solution we have, 
and that would also take more time. Two things that can be 
improved in the future:
1. Data structures for holding stats can be further improved
2. Core stats are hard-coded in the About template (it's hard 
to fix it without correcting data structures first, see point 1):
    63a0700d45/app/views/about/index.html.erb (L61-L101)

The most significant refactorings are:
1. Introducing the `Stat` model
2. Aligning the way the core and the plugin stats' are registered
2023-11-10 00:44:05 +04:00
Bianca Nenciu
bdb81b5346
DEV: Use a single registry for preloaded category custom fields ()
There was a registry for preloaded site categories and a new one has
been introduced recently for categories serialized through a
CategoryList.

Having two registries created a lot of friction for developers and this
commit merges them into a single one, providing a unified API.
2023-11-09 18:23:24 +02:00
Andrei Prigorshnev
be2eb3df44
FIX: user got notified about a mention inside a chat message quote ()
When quoting a chat message in a post, if that message contains a mention, 
that mention should be ignored. But we've been detecting them and sending 
notifications to users. This PR fixes the problem. Since this fix is for 
the chat plugin, I had to introduce a new API for plugins:

    # We strip posts before detecting mentions, oneboxes, attachments etc. 
    # We strip those elements that shouldn't be detected. For example, 
    # a mention inside a quote should be ignored, so we strip it off. 
    # Using this API plugins can register their own post strippers. 
    def register_post_stripper(&block) 
    end
2023-11-08 23:13:25 +04:00
Mark VanLandingham
e3f8e9c0fb
DEV: Email notification filter plugin API () 2023-11-08 10:29:00 -06:00
Angus McLeod
2a75656ff2
DEV: Add category custom field preloading to CategoryList ()
This commit also introduced a plugin API for preloading category custom
fields.
2023-10-26 16:34:23 +03:00
David Taylor
c88303bb27
DEV: Relax auth provider registration restrictions for plugins ()
In the past we would build the stack of Omniauth providers at boot, which meant that plugins had to register any authenticators in the root of their plugin.rb (i.e. not in an `after_initialize` block). This could be frustrating because many features are not available that early in boot (e.g. Zeitwerk autoloading).

Now that we build the omniauth strategy stack 'just in time', it is safe for plugins to register their auth methods in an `after_initialize` block. This commit relaxes the old restrictions so that plugin authors have the option to move things around.
2023-10-26 10:54:30 +01:00
Blake Erickson
07360a96aa
DEV: Remove core plugins from plugin metadata file ()
* DEV: Remove core plugins from plugin metadata file

* Add new plugin names
2023-10-23 15:26:59 -06:00
Alan Guo Xiang Tan
4cb7472376
SECURITY: Prevent arbitrary topic custom fields from being set
Why this change?

The `PostsController#create` action allows arbitrary topic custom fields
to be set by any user that can create a topic. Without any restrictions,
this opens us up to potential security issues where plugins may be using
topic custom fields in security sensitive areas.

What does this change do?

1. This change introduces the `register_editable_topic_custom_field` plugin
API which allows plugins to register topic custom fields that are
editable either by staff users only or all users. The registered
editable topic custom fields are stored in `DiscoursePluginRegistry` and
is called by a new method `Topic#editable_custom_fields` which is then
used in the `PostsController#create` controller action. When an unpermitted custom fields is present in the `meta_data` params,
a 400 response code is returned.

2. Removes all reference to `meta_data` on a topic as it is confusing
   since we actually mean topic custom fields instead.
2023-10-16 10:34:35 -04:00
Mark VanLandingham
f29c476521
DEV: Add hooks to allow overriding notify_user behavior ()
Adds new plugin registry `:post_action_notify_user_handlers` and more!
2023-10-10 12:21:57 -05:00
Martin Brennan
b58f660cd2
DEV: Add meta_topic_id plugin metadata ()
For the admin plugin list we want to be able to link to
a meta topic for plugins, but we have no standard way to
do this at the moment. This adds support for meta_topic_id
alongside other plugin metadata like authors, URL etc,
that gets built into a Meta topic URL in the serializer.
2023-10-10 10:16:13 +10:00