Commit Graph

324 Commits

Author SHA1 Message Date
Bianca Nenciu 58479fe10b
DEV: Pass kwargs to defined method (#19552) 2022-12-21 19:02:40 +02:00
Martin Brennan 6b9c0ee554
DEV: Change HashtagAutocompleteService to use DiscoursePluginRegistry (#19491)
Follow up to a review in #18937, this commit changes the HashtagAutocompleteService to no longer use class variables to register hashtag data sources or types in context priority order. This is to address multisite concerns, where one site could e.g. have chat disabled and another might not. The filtered plugin registers I added will not be included if the plugin is disabled.
2022-12-19 13:46:17 +10:00
jbrw 1a48ea767e
DEV: Allow additional TopicList preloaded associations (#18891)
This provides a means to allow additional associations to be preloaded when generating a TopicList.
2022-12-12 09:08:13 -05:00
Roman Rizzi 07a9163ea8
FEATURE: Deleting a user with their posts also deletes chat messages. (#19194)
This commit introduce a new API for registering callbacks, which we'll execute when a user gets destroyed, and the `delete_posts` opt is true. The chat plugin registers one callback and queues a job to destroy every message from that user in batches.
2022-11-28 13:32:57 -03:00
David Taylor abe2813789
DEV: Add useful error message for hbs register_asset (#19185)
This hasn't been necessary for many years, and is no longer supported following 84bec1cb. Only extremely old plugins might be trying to do this. All the affected open-source plugins I can find have already been updated.
2022-11-24 19:03:06 +00:00
Martin Brennan d3f02a1270
FEATURE: Generic hashtag autocomplete lookup and markdown cooking (#18937)
This commit fleshes out and adds functionality for the new `#hashtag` search and
lookup system, still hidden behind the `enable_experimental_hashtag_autocomplete`
feature flag.

**Serverside**

We have two plugin API registration methods that are used to define data sources
(`register_hashtag_data_source`) and hashtag result type priorities depending on
the context (`register_hashtag_type_in_context`). Reading the comments in plugin.rb
should make it clear what these are doing. Reading the `HashtagAutocompleteService`
in full will likely help a lot as well.

Each data source is responsible for providing its own **lookup** and **search**
method that returns hashtag results based on the arguments provided. For example,
the category hashtag data source has to take into account parent categories and
how they relate, and each data source has to define their own icon to use for the
hashtag, and so on.

The `Site` serializer has two new attributes that source data from `HashtagAutocompleteService`.
There is `hashtag_icons` that is just a simple array of all the different icons that
can be used for allowlisting in our markdown pipeline, and there is `hashtag_context_configurations`
that is used to store the type priority orders for each registered context.

When sending emails, we cannot render the SVG icons for hashtags, so
we need to change the HTML hashtags to the normal `#hashtag` text.

**Markdown**

The `hashtag-autocomplete.js` file is where I have added the new `hashtag-autocomplete`
markdown rule, and like all of our rules this is used to cook the raw text on both the clientside
and on the serverside using MiniRacer. Only on the server side do we actually reach out to
the database with the `hashtagLookup` function, on the clientside we just render a plainer
version of the hashtag HTML. Only in the composer preview do we do further lookups based
on this.

This rule is the first one (that I can find) that uses the `currentUser` based on a passed
in `user_id` for guardian checks in markdown rendering code. This is the `last_editor_id`
for both the post and chat message. In some cases we need to cook without a user present,
so the `Discourse.system_user` is used in this case.

**Chat Channels**

This also contains the changes required for chat so that chat channels can be used
as a data source for hashtag searches and lookups. This data source will only be
used when `enable_experimental_hashtag_autocomplete` is `true`, so we don't have
to worry about channel results suddenly turning up.

------

**Known Rough Edges**

- Onebox excerpts will not render the icon svg/use tags, I plan to address that in a follow up PR
- Selecting a hashtag + pressing the Quote button will result in weird behaviour, I plan to address that in a follow up PR
- Mixed hashtag contexts for hashtags without a type suffix will not work correctly, e.g. #ux which is both a category and a channel slug will resolve to a category when used inside a post or within a [chat] transcript in that post. Users can get around this manually by adding the correct suffix, for example ::channel. We may get to this at some point in future
- Icons will not show for the hashtags in emails since SVG support is so terrible in email (this is not likely to be resolved, but still noting for posterity)
- Additional refinements and review fixes wil
2022-11-21 08:37:06 +10:00
Natalie Tay 612ab8710a
DEV: Give em plugins the green tick (#18836) 2022-11-03 11:41:25 +08:00
Roman Rizzi 0a5f548635
DEV: Move `discourse-chat` to the core repo. (#18776)
As part of this move, we are also renaming `discourse-chat` to `chat`.
2022-11-02 10:41:30 -03:00
Martin Brennan 7c25597da2
FEATURE: Generic hashtag autocomplete part 1 (#18592)
This commit adds a new `/hashtag/search` endpoint and both
relevant JS and ruby plugin APIs to handle plugins adding their
own data sources and priority orders for types of things to search
when `#` is pressed.

A `context` param is added to `setupHashtagAutocomplete` which
a corresponding chat PR https://github.com/discourse/discourse-chat/pull/1302
will now use.

The UI calls `registerHashtagSearchParam` for each context that will
require a `#` search (e.g. the topic composer), for each type of record that
the context needs to search for, as well as a priority order for that type. Core
uses this call to add the `category` and `tag` data sources to the topic composer.

The `register_hashtag_data_source` ruby plugin API call is for plugins to
add a new data source for the hashtag searching endpoint, e.g. discourse-chat
may add a `channel` data source.

This functionality is hidden behind the `enable_experimental_hashtag_autocomplete`
flag, except for the change to `setupHashtagAutocomplete` since only core and
discourse-chat are using that function. Note this PR does **not** include required
changes for hashtag lookup or new styling.
2022-10-19 14:03:57 +10:00
David Taylor e06b9d4a52
DEV: Remove support for legacy plugin JS compilation pipeline (#18293)
This became the default in b1755137
2022-09-21 12:38:02 +01:00
David Taylor 9ebebfb4cc
FIX: Load admin-specific JS when compiling via ember-cli (#18086)
The previous sprockets implementation was including admin-specific JS in the plugin's main JS file, which would be served to all users regardless of admin status. This commit achieves the same result under the ember-cli plugin asset compiler with one difference: the admin js is compiled into a separate file. That means that in future, we'll be able to make it loaded only for admins. For now though, it's loaded for everyone, just like before.
2022-08-25 11:36:02 +01:00
Gerhard Schlager 9685852a1f
DEV: Add salesforce plugin to official list of plugins (#18072) 2022-08-24 10:42:43 +02:00
David Taylor 33a2624f09
DEV: Introduce flag for compiling Plugin JS with Ember CLI (#17965)
When `EMBER_CLI_PLUGIN_ASSETS=1`, plugin application JS will be compiled via Ember CLI. In this mode, the existing `register_asset` API will cause any registered JS files to be made available in `/plugins/{plugin-name}_extra.js`. These 'extra' files will be loaded immediately after the plugin app JS file, so this should not affect functionality.

Plugin compilation in Ember CLI is implemented as an addon, similar to the existing 'admin' addon. We bypass the normal Ember CLI compilation process (which would add the JS to the main app bundle), and reroute the addon Broccoli tree into a separate JS file per-plugin. Previously, Sprockets would add compiled templates directly to `Ember.TEMPLATES`. Under Ember CLI, they are compiled into es6 modules. Some new logic in `discourse-boot.js` takes care of remapping the new module names into the old-style `Ember.TEMPLATES`.

This change has been designed to be a like-for-like replacement of the old plugin compilation system, so we do not expect any breakage. Even so, the environment variable flag will allow us to test this in a range of environments before enabling it by default.

A manual silence implementation is added for the build-time `ember-glimmer.link-to.positional-arguments` deprecation while we work on a better story for plugins.
2022-08-22 09:56:39 +01:00
TheJammiestDodger 39f12ddeca
Add discourse-question-answer to official plugins (#17807) 2022-08-05 14:31:58 +05:30
Rishabh 03c9c3da76
DEV: Add discourse-chat to official plugins (#17773)
https://meta.discourse.org/t/discourse-chat-plugin/230881/11
2022-08-03 13:23:57 +01:00
Sérgio Saquetim a0d501b0b1
DEV: Add discourse-templates in the official plugins list (#17560) 2022-07-18 16:46:49 -03:00
Martin Brennan 098ab29d41
FEATURE: Add plugin API to register About stat group (#17442)
This commit introduces a new plugin API to register
a group of stats that will be included in about.json
and also conditionally in the site about UI at /about.

The usage is like this:

```ruby
register_about_stat_group("chat_messages", show_in_ui: true) do
  {
    last_day: 1,
    "7_days" => 10,
    "30_days" => 100,
    count: 1000,
    previous_30_days: 120
  }
end
```

In reality the stats will be generated any way the implementer
chooses within the plugin. The `last_day`, `7_days`, `30_days,` and `count`
keys must be present but apart from that additional stats may be added.
Only those core 4 stat keys will be shown in the UI, but everything will be shown
in about.json.

The stat group name is used to prefix the stats in about.json like so:

```json
"chat_messages_last_day": 2322,
"chat_messages_7_days": 2322,
"chat_messages_30_days": 2322,
"chat_messages_count": 2322,
```

The `show_in_ui` option (default false) is used to determine whether the
group of stats is shown on the site About page in the Site Statistics
table. Some stats may be needed purely for reporting purposes and thus
do not need to be shown in the UI to admins/users. An extension to the Site
serializer, `displayed_about_plugin_stat_groups`, has been added so this
can be inspected on the client-side.
2022-07-15 13:16:00 +10:00
Jarek Radosz 624c684d51
DEV: Transpile all plugin js by default (#17175)
Goodbye `# transpile_js: true`? 🙂
2022-06-21 22:07:10 +02:00
Roman Rizzi e0ba35350e
FEATURE: Custom unsubscribe options (#17090)
With this change, plugins can create custom unsubscribe keys, extend the unsubscribe view with custom preferences, and decide how they are updated.
2022-06-21 15:49:47 -03:00
tshenry 08a8c27f16
DEV: Mark discourse-group-tracker as official (#16574) 2022-06-01 15:07:51 +01:00
Gerhard Schlager 45dbbbadba
DEV: Add discourse-gamification to the official plugins (#16639) 2022-05-04 21:06:06 +02:00
Loïc Guitaut 008b700a3f DEV: Upgrade to Rails 7
This patch upgrades Rails to version 7.0.2.4.
2022-04-28 11:51:03 +02:00
Jarek Radosz 3f98af73ce
DEV: Add discourse-bcc to the official plugins (#16251) 2022-03-22 18:18:09 +01:00
Jarek Radosz f9e1ba4f8f
DEV: Remove remnants of nginx-perf-report plugin (#16107)
The plugin is no longer official as of Nov 18, 2019 (e2ccb0c608)
2022-03-05 17:22:23 +01:00
tshenry 3b6da9045f
DEV: Mark `discourse-automation` as official (#16029) 2022-02-22 13:31:54 -08:00
Osama Sayegh 189df5ef43
UX: Add discourse-follow to official plugin list (#16005)
The follow plugin is an official plugin: https://meta.discourse.org/t/follow-plugin/110579?u=osama.
2022-02-20 23:32:46 +03:00
Bianca Nenciu 5eaf214594
FEATURE: New plugin API to check if upload is used (#15545)
This commit introduces two new APIs for handling unused uploads, one
can be used to exclude uploads in bulk when the data model allow and
the other one excludes uploads one by one.
2022-02-16 09:00:30 +02:00
David Taylor 3acc54c218
UX: Add whos-online to official plugin list (#15910) 2022-02-11 12:00:24 +00:00
Peter Zhu c5fd8c42db
DEV: Fix methods removed in Ruby 3.2 (#15459)
* File.exists? is deprecated and removed in Ruby 3.2 in favor of
File.exist?
* Dir.exists? is deprecated and removed in Ruby 3.2 in favor of
Dir.exist?
2022-01-05 18:45:08 +01:00
Jarek Radosz 2a4df93b8e
FEATURE: Allow to modify topic-backed static pages (#15324)
A plugin API that allows customizing existing topic-backed static pages, like:
faq, tos, privacy (see: StaticController) The block passed to this
method has to return a SiteSetting name that contains a topic id.

```
add_topic_static_page("faq") do |controller|
  current_user&.locale == "pl" ? "polish_faq_topic_id" : "faq_topic_id"
end
```

You can also add new pages in a plugin, but remember to add a route,
for example:

```
get "contact" => "static#show", id: "contact"
```
2021-12-16 04:24:11 +01:00
Natalie Tay 9fd1a00eef
DEV: Remove customer flair from being an official plugin (#15315) 2021-12-15 22:30:50 +08:00
David Taylor b3e5421b25
DEV: Add discourse-vk-auth to official plugins list (#15287) 2021-12-13 22:54:28 +00:00
David Taylor 1773d9d594
DEV: Add SAML to official plugin list (#15276) 2021-12-13 15:50:57 +00:00
Dax74 f8b3fe65d7
FEATURE: Add Apple plugin to the official list (#15261) 2021-12-13 16:29:02 +11:00
Roman Rizzi b7b61d4b56
FEATURE: A notification consolidation plan for keeping the latest one. (#15249)
We previously used ConsolidateNotifications with a threshold of 1 to re-use an existing notification and bump it to the top instead of creating a new one. It produces some jumpiness in the user notification list, and it relies on updating the `created_at` attribute, which is a bit hacky.

As a better alternative, we're introducing a new plan that deletes all the previous versions of the notification, then creates a new one.
2021-12-10 10:32:15 -03:00
Daniel Waterworth 3ebce550fe
DEV: Make add_api_parameter_route parameter deprecations errors (#15198)
Since we said we would remove support in 2.7, this is overdue.
2021-12-06 09:10:14 -06:00
David Taylor 93860fd29b
DEV: Update discourse-plugin-linkedin-auth to discourse-linkedin-auth (#15181) 2021-12-03 17:42:14 +00:00
David Taylor 75dbc488d9
DEV: Update official plugin list (#15180)
- Remove Discord plugin (it has now been merged into core)
- Rename discourse-plugin-office365-auth to discourse-microsoft-auth
2021-12-03 12:05:05 +00:00
Daniel Waterworth bd10f113e9
DEV: Raise errors for (black|white)list accesses (#15174)
These have been deprecated for a while
2021-12-02 12:16:55 -06:00
Roman Rizzi 1fc06520bd
REFACTOR: Improve support for consolidating notifications. (#14904)
* REFACTOR: Improve support for consolidating notifications.

Before this commit, we didn't have a single way of consolidating notifications. For notifications like group summaries, we manually removed old ones before creating a new one. On the other hand, we used an after_create callback for likes and group membership requests, which caused unnecessary work, as we need to delete the record we created to replace it with a consolidated one.

We now have all the consolidation rules centralized in a single place: the consolidation planner class. Other parts of the app looking to create a consolidable notification can do so by calling Notification#consolidate_or_save!, instead of the default Notification#create! method.

Finally, we added two more rules: one for re-using existing group summaries and another for deleting duplicated dashboard problems PMs notifications when the user is tracking the moderator's inbox. Setting the threshold to one forces the planner to apply this rule every time.

I plan to add plugin support for adding custom rules in another PR to keep this one relatively small.

* DEV: Introduces a plugin API for consolidating notifications.

This commit removes the `Notification#filter_by_consolidation_data` scope since plugins could have to define their criteria. The Plan class now receives two blocks, one to query for an already consolidated notification, which we'll try to update, and another to query for existing ones to consolidate.

It also receives a consolidation window, which accepts an ActiveSupport::Duration object, and filter notifications created since that value.
2021-11-30 13:36:14 -03:00
Daniel Waterworth e7c0bbb9c0
DEV: Let's always give a drop_from param to deprecate (#14901)
So that we know when deprecations can be removed in the future.
2021-11-12 08:52:59 -06:00
Mark VanLandingham 67265a5045
DEV: Plugin instance method for push_notification_filters (#14787) 2021-11-03 12:21:33 -05:00
Alan Guo Xiang Tan d1201d6188
DEV: Pass topic to `TopicView.add_post_custom_fields_allowlister` (#14678)
Allows custom fields to be loaded based on the attributes of a topic.
2021-10-22 10:22:09 +08:00
tshenry 9bc68a5502
DEV: Mark discourse-category-experts official (#14655) 2021-10-19 19:04:54 -07:00
Joshua Rosenfeld 92afa74d92
Mark shared-edits plugin as official (#14639) 2021-10-19 10:38:06 +08:00
Roman Rizzi 9f3b82eeb2
DEV: Move settings to linkify to the serializer code. (#14553)
We aren't translating these settings, so it makes more sense to move them into the code. I added an instance method so plugins can add mappings for custom reasons.
2021-10-07 12:41:57 -03:00
Dax74 bdd2b5bb9c
Add LTI plugin (#14532)
Add LTI plugin to the Official list
2021-10-06 19:19:12 +02:00
tshenry ba17d9106e
DEV: Make discourse-reactions official and sort existing plugin list (#14452) 2021-09-28 09:44:10 +08:00
Krzysztof Kotlarek e3793e6d7c
FIX: better filter for groups search (#14262)
Follow up of https://github.com/discourse/discourse/pull/14216

Allow plugins to register custom filter with block
2021-09-08 09:38:45 +10:00
Krzysztof Kotlarek f859fd6bde
FEATURE: allow plugins to extend Groups (#14216)
* add_permitted_group_param API for plugins
* add groups-interaction-custom-options outlet
* custom search can use custom group scope
2021-09-06 10:18:51 +10:00