2019-05-02 18:17:27 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2013-02-05 14:16:51 -05:00
|
|
|
class SiteSerializer < ApplicationSerializer
|
2023-07-23 20:07:37 -04:00
|
|
|
include NavigationMenuTagsMixin
|
|
|
|
|
2018-03-13 15:59:12 -04:00
|
|
|
attributes(
|
|
|
|
:default_archetype,
|
|
|
|
:notification_types,
|
|
|
|
:post_types,
|
2022-11-09 13:20:34 -05:00
|
|
|
:user_tips,
|
2021-06-01 16:11:48 -04:00
|
|
|
:trust_levels,
|
2018-03-13 15:59:12 -04:00
|
|
|
:groups,
|
|
|
|
:filters,
|
|
|
|
:periods,
|
|
|
|
:top_menu_items,
|
|
|
|
:anonymous_top_menu_items,
|
|
|
|
:uncategorized_category_id, # this is hidden so putting it here
|
|
|
|
:user_field_max_length,
|
|
|
|
:post_action_types,
|
|
|
|
:topic_flag_types,
|
|
|
|
:can_create_tag,
|
|
|
|
:can_tag_topics,
|
|
|
|
:can_tag_pms,
|
|
|
|
:tags_filter_regexp,
|
|
|
|
:top_tags,
|
2023-07-23 20:07:37 -04:00
|
|
|
:navigation_menu_site_top_tags,
|
2021-12-09 07:30:27 -05:00
|
|
|
:can_associate_groups,
|
2018-03-13 15:59:12 -04:00
|
|
|
:wizard_required,
|
|
|
|
:topic_featured_link_allowed_category_ids,
|
|
|
|
:user_themes,
|
2020-08-28 10:36:52 -04:00
|
|
|
:user_color_schemes,
|
|
|
|
:default_dark_color_scheme,
|
2019-07-31 13:33:49 -04:00
|
|
|
:censored_regexp,
|
2020-05-27 14:11:52 -04:00
|
|
|
:shared_drafts_category_id,
|
2021-02-25 07:00:58 -05:00
|
|
|
:custom_emoji_translation,
|
2021-06-02 01:36:49 -04:00
|
|
|
:watched_words_replace,
|
2021-06-23 03:21:11 -04:00
|
|
|
:watched_words_link,
|
2022-01-27 22:02:02 -05:00
|
|
|
:categories,
|
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-14 23:16:00 -04:00
|
|
|
:markdown_additional_options,
|
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-20 17:37:06 -05:00
|
|
|
:hashtag_configurations,
|
|
|
|
:hashtag_icons,
|
2023-06-14 19:31:28 -04:00
|
|
|
:anonymous_default_navigation_menu_tags,
|
2023-04-05 18:55:47 -04:00
|
|
|
:anonymous_sidebar_sections,
|
2022-12-23 13:42:46 -05:00
|
|
|
:whispers_allowed_groups_names,
|
2023-04-13 03:38:54 -04:00
|
|
|
:denied_emojis,
|
2023-05-30 10:38:14 -04:00
|
|
|
:tos_url,
|
|
|
|
:privacy_policy_url,
|
2023-12-07 12:30:44 -05:00
|
|
|
:system_user_avatar_template,
|
2024-01-17 13:26:51 -05:00
|
|
|
:lazy_load_categories,
|
2024-07-02 18:45:37 -04:00
|
|
|
:valid_flag_applies_to_types,
|
2018-03-13 15:59:12 -04:00
|
|
|
)
|
2013-02-20 13:15:50 -05:00
|
|
|
|
2013-02-05 14:16:51 -05:00
|
|
|
has_many :archetypes, embed: :objects, serializer: ArchetypeSerializer
|
2018-07-31 11:18:50 -04:00
|
|
|
has_many :user_fields, embed: :objects, serializer: UserFieldSerializer
|
|
|
|
has_many :auth_providers, embed: :objects, serializer: AuthProviderSerializer
|
2024-05-06 12:32:18 -04:00
|
|
|
has_many :anonymous_sidebar_sections, embed: :objects, serializer: SidebarSectionSerializer
|
2013-02-05 14:16:51 -05:00
|
|
|
|
2017-04-12 10:52:52 -04:00
|
|
|
def user_themes
|
|
|
|
cache_fragment("user_themes") do
|
2018-07-12 00:18:21 -04:00
|
|
|
Theme
|
|
|
|
.where("id = :default OR user_selectable", default: SiteSetting.default_theme_id)
|
2021-12-05 19:55:34 -05:00
|
|
|
.order("lower(name)")
|
2020-08-28 10:36:52 -04:00
|
|
|
.pluck(:id, :name, :color_scheme_id)
|
|
|
|
.map do |id, n, cs|
|
|
|
|
{
|
|
|
|
theme_id: id,
|
|
|
|
name: n,
|
|
|
|
default: id == SiteSetting.default_theme_id,
|
|
|
|
color_scheme_id: cs,
|
|
|
|
}
|
2023-01-09 07:20:10 -05:00
|
|
|
end
|
2017-04-12 10:52:52 -04:00
|
|
|
.as_json
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2020-08-28 10:36:52 -04:00
|
|
|
def user_color_schemes
|
|
|
|
cache_fragment("user_color_schemes") do
|
2021-06-02 01:26:09 -04:00
|
|
|
schemes = ColorScheme.includes(:color_scheme_colors).where("user_selectable").order(:name)
|
2020-08-28 10:36:52 -04:00
|
|
|
ActiveModel::ArraySerializer.new(
|
|
|
|
schemes,
|
|
|
|
each_serializer: ColorSchemeSelectableSerializer,
|
|
|
|
).as_json
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def default_dark_color_scheme
|
2024-07-01 16:08:48 -04:00
|
|
|
ColorSchemeSerializer.new(
|
|
|
|
ColorScheme.find_by_id(SiteSetting.default_dark_mode_color_scheme_id),
|
|
|
|
root: false,
|
|
|
|
).as_json
|
2020-08-28 10:36:52 -04:00
|
|
|
end
|
|
|
|
|
2015-09-28 02:43:38 -04:00
|
|
|
def groups
|
2019-02-14 18:24:29 -05:00
|
|
|
cache_anon_fragment("group_names") do
|
2021-04-06 11:13:06 -04:00
|
|
|
object
|
|
|
|
.groups
|
|
|
|
.order(:name)
|
2021-08-10 07:55:11 -04:00
|
|
|
.select(:id, :name, :flair_icon, :flair_upload_id, :flair_bg_color, :flair_color)
|
2021-04-06 11:13:06 -04:00
|
|
|
.map do |g|
|
|
|
|
{
|
|
|
|
id: g.id,
|
|
|
|
name: g.name,
|
|
|
|
flair_url: g.flair_url,
|
|
|
|
flair_bg_color: g.flair_bg_color,
|
|
|
|
flair_color: g.flair_color,
|
|
|
|
}
|
|
|
|
end
|
|
|
|
.as_json
|
2019-02-14 18:24:29 -05:00
|
|
|
end
|
2015-09-28 02:43:38 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def post_action_types
|
FIX: serialize Flags instead of PostActionType (#28362)
### Why?
Before, all flags were static. Therefore, they were stored in class variables and serialized by SiteSerializer. Recently, we added an option for admins to add their own flags or disable existing flags. Therefore, the class variable had to be dropped because it was unsafe for a multisite environment. However, it started causing performance problems.
### Solution
When a new Flag system is used, instead of using PostActionType, we can serialize Flags and use fragment cache for performance reasons.
At the same time, we are still supporting deprecated `replace_flags` API call. When it is used, we fall back to the old solution and the admin cannot add custom flags. In a couple of months, we will be able to drop that API function and clean that code properly. However, because it may still be used, redis cache was introduced to improve performance.
To test backward compatibility you can add this code to any plugin
```ruby
replace_flags do |flag_settings|
flag_settings.add(
4,
:inappropriate,
topic_type: true,
notify_type: true,
auto_action_type: true,
)
flag_settings.add(1001, :trolling, topic_type: true, notify_type: true, auto_action_type: true)
end
```
2024-08-13 22:13:46 -04:00
|
|
|
Discourse
|
|
|
|
.cache
|
|
|
|
.fetch("post_action_types_#{I18n.locale}") do
|
|
|
|
if PostActionType.overridden_by_plugin_or_skipped_db?
|
|
|
|
types = ordered_flags(PostActionType.types.values)
|
|
|
|
ActiveModel::ArraySerializer.new(types).as_json
|
|
|
|
else
|
|
|
|
ActiveModel::ArraySerializer.new(
|
|
|
|
Flag.unscoped.order(:position).where(score_type: false).all,
|
|
|
|
each_serializer: FlagSerializer,
|
|
|
|
target: :post_action,
|
|
|
|
used_flag_ids: Flag.used_flag_ids,
|
|
|
|
).as_json
|
|
|
|
end
|
|
|
|
end
|
2015-09-28 02:43:38 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def topic_flag_types
|
FIX: serialize Flags instead of PostActionType (#28362)
### Why?
Before, all flags were static. Therefore, they were stored in class variables and serialized by SiteSerializer. Recently, we added an option for admins to add their own flags or disable existing flags. Therefore, the class variable had to be dropped because it was unsafe for a multisite environment. However, it started causing performance problems.
### Solution
When a new Flag system is used, instead of using PostActionType, we can serialize Flags and use fragment cache for performance reasons.
At the same time, we are still supporting deprecated `replace_flags` API call. When it is used, we fall back to the old solution and the admin cannot add custom flags. In a couple of months, we will be able to drop that API function and clean that code properly. However, because it may still be used, redis cache was introduced to improve performance.
To test backward compatibility you can add this code to any plugin
```ruby
replace_flags do |flag_settings|
flag_settings.add(
4,
:inappropriate,
topic_type: true,
notify_type: true,
auto_action_type: true,
)
flag_settings.add(1001, :trolling, topic_type: true, notify_type: true, auto_action_type: true)
end
```
2024-08-13 22:13:46 -04:00
|
|
|
Discourse
|
|
|
|
.cache
|
|
|
|
.fetch("post_action_flag_types_#{I18n.locale}") do
|
|
|
|
if PostActionType.overridden_by_plugin_or_skipped_db?
|
|
|
|
types = ordered_flags(PostActionType.topic_flag_types.values)
|
|
|
|
ActiveModel::ArraySerializer.new(types, each_serializer: TopicFlagTypeSerializer).as_json
|
|
|
|
else
|
|
|
|
ActiveModel::ArraySerializer.new(
|
|
|
|
Flag
|
|
|
|
.unscoped
|
|
|
|
.where("'Topic' = ANY(applies_to)")
|
|
|
|
.where(score_type: false)
|
|
|
|
.order(:position)
|
|
|
|
.all,
|
|
|
|
each_serializer: FlagSerializer,
|
|
|
|
target: :topic_flag,
|
|
|
|
used_flag_ids: Flag.used_flag_ids,
|
|
|
|
).as_json
|
|
|
|
end
|
|
|
|
end
|
2015-09-28 02:43:38 -04:00
|
|
|
end
|
|
|
|
|
2013-02-05 14:16:51 -05:00
|
|
|
def default_archetype
|
|
|
|
Archetype.default
|
|
|
|
end
|
|
|
|
|
2013-02-20 13:15:50 -05:00
|
|
|
def post_types
|
2013-03-18 16:03:46 -04:00
|
|
|
Post.types
|
2013-02-20 13:15:50 -05:00
|
|
|
end
|
2013-02-25 11:42:20 -05:00
|
|
|
|
2022-11-09 13:20:34 -05:00
|
|
|
def user_tips
|
|
|
|
User.user_tips
|
2022-10-12 11:38:45 -04:00
|
|
|
end
|
|
|
|
|
2022-11-09 13:20:34 -05:00
|
|
|
def include_user_tips?
|
|
|
|
SiteSetting.enable_user_tips
|
2022-10-12 11:38:45 -04:00
|
|
|
end
|
|
|
|
|
2014-01-14 12:48:57 -05:00
|
|
|
def filters
|
|
|
|
Discourse.filters.map(&:to_s)
|
|
|
|
end
|
|
|
|
|
|
|
|
def periods
|
|
|
|
TopTopic.periods.map(&:to_s)
|
|
|
|
end
|
2014-02-05 17:54:16 -05:00
|
|
|
|
2014-01-14 12:48:57 -05:00
|
|
|
def top_menu_items
|
|
|
|
Discourse.top_menu_items.map(&:to_s)
|
|
|
|
end
|
|
|
|
|
|
|
|
def anonymous_top_menu_items
|
|
|
|
Discourse.anonymous_top_menu_items.map(&:to_s)
|
|
|
|
end
|
|
|
|
|
2013-10-23 19:05:51 -04:00
|
|
|
def uncategorized_category_id
|
|
|
|
SiteSetting.uncategorized_category_id
|
2013-05-27 14:15:20 -04:00
|
|
|
end
|
|
|
|
|
2015-02-23 13:02:30 -05:00
|
|
|
def user_field_max_length
|
|
|
|
UserField.max_length
|
|
|
|
end
|
|
|
|
|
2016-04-25 15:55:15 -04:00
|
|
|
def can_create_tag
|
2018-02-13 15:46:25 -05:00
|
|
|
scope.can_create_tag?
|
2016-04-25 15:55:15 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def can_tag_topics
|
2018-02-13 15:46:25 -05:00
|
|
|
scope.can_tag_topics?
|
|
|
|
end
|
|
|
|
|
|
|
|
def can_tag_pms
|
|
|
|
scope.can_tag_pms?
|
2016-04-25 15:55:15 -04:00
|
|
|
end
|
|
|
|
|
2021-12-09 07:30:27 -05:00
|
|
|
def can_associate_groups
|
|
|
|
scope.can_associate_groups?
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_can_associate_groups?
|
|
|
|
scope.is_admin?
|
|
|
|
end
|
|
|
|
|
2016-04-25 15:55:15 -04:00
|
|
|
def include_tags_filter_regexp?
|
|
|
|
SiteSetting.tagging_enabled
|
|
|
|
end
|
2016-07-07 09:17:56 -04:00
|
|
|
|
2016-04-25 15:55:15 -04:00
|
|
|
def tags_filter_regexp
|
|
|
|
DiscourseTagging::TAGS_FILTER_REGEXP.source
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_top_tags?
|
2016-07-07 09:17:56 -04:00
|
|
|
Tag.include_tags?
|
2016-04-25 15:55:15 -04:00
|
|
|
end
|
2016-07-07 09:17:56 -04:00
|
|
|
|
2016-04-25 15:55:15 -04:00
|
|
|
def top_tags
|
2023-07-23 20:07:37 -04:00
|
|
|
@top_tags ||= Tag.top_tags(guardian: scope)
|
2016-04-25 15:55:15 -04:00
|
|
|
end
|
2016-09-14 16:36:08 -04:00
|
|
|
|
|
|
|
def wizard_required
|
|
|
|
true
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_wizard_required?
|
2016-10-18 11:44:25 -04:00
|
|
|
Wizard.user_requires_completion?(scope.user)
|
2016-09-14 16:36:08 -04:00
|
|
|
end
|
2016-12-05 07:31:43 -05:00
|
|
|
|
|
|
|
def include_topic_featured_link_allowed_category_ids?
|
|
|
|
SiteSetting.topic_featured_link_enabled
|
|
|
|
end
|
|
|
|
|
|
|
|
def topic_featured_link_allowed_category_ids
|
|
|
|
scope.topic_featured_link_allowed_category_ids
|
|
|
|
end
|
2017-06-28 16:56:44 -04:00
|
|
|
|
2019-07-31 13:33:49 -04:00
|
|
|
def censored_regexp
|
2023-11-01 10:41:10 -04:00
|
|
|
WordWatcher.serialized_regexps_for_action(:censor, engine: :js)
|
2017-06-28 16:56:44 -04:00
|
|
|
end
|
2018-03-13 15:59:12 -04:00
|
|
|
|
2020-05-27 14:11:52 -04:00
|
|
|
def custom_emoji_translation
|
|
|
|
Plugin::CustomEmoji.translations
|
|
|
|
end
|
|
|
|
|
2018-03-13 15:59:12 -04:00
|
|
|
def shared_drafts_category_id
|
|
|
|
SiteSetting.shared_drafts_category.to_i
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_shared_drafts_category_id?
|
2021-05-06 15:09:31 -04:00
|
|
|
scope.can_see_shared_draft? && SiteSetting.shared_drafts_enabled?
|
2018-03-13 15:59:12 -04:00
|
|
|
end
|
|
|
|
|
2021-02-25 07:00:58 -05:00
|
|
|
def watched_words_replace
|
2023-11-01 10:41:10 -04:00
|
|
|
WordWatcher.regexps_for_action(:replace, engine: :js)
|
2021-02-25 07:00:58 -05:00
|
|
|
end
|
|
|
|
|
2021-06-02 01:36:49 -04:00
|
|
|
def watched_words_link
|
2023-11-01 10:41:10 -04:00
|
|
|
WordWatcher.regexps_for_action(:link, engine: :js)
|
2021-06-02 01:36:49 -04:00
|
|
|
end
|
|
|
|
|
2021-06-23 03:21:11 -04:00
|
|
|
def categories
|
|
|
|
object.categories.map { |c| c.to_h }
|
|
|
|
end
|
|
|
|
|
2023-12-28 07:36:33 -05:00
|
|
|
def include_categories?
|
2024-02-02 03:35:15 -05:00
|
|
|
object.categories.present?
|
2023-12-28 07:36:33 -05:00
|
|
|
end
|
|
|
|
|
2022-01-27 22:02:02 -05:00
|
|
|
def markdown_additional_options
|
|
|
|
Site.markdown_additional_options
|
|
|
|
end
|
|
|
|
|
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-20 17:37:06 -05:00
|
|
|
def hashtag_configurations
|
|
|
|
HashtagAutocompleteService.contexts_with_ordered_types
|
|
|
|
end
|
|
|
|
|
|
|
|
def hashtag_icons
|
2023-05-23 03:33:55 -04:00
|
|
|
HashtagAutocompleteService.data_source_icon_map
|
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-20 17:37:06 -05:00
|
|
|
end
|
|
|
|
|
2023-07-23 20:07:37 -04:00
|
|
|
SIDEBAR_TOP_TAGS_TO_SHOW = 5
|
|
|
|
|
|
|
|
def navigation_menu_site_top_tags
|
|
|
|
if top_tags.present?
|
|
|
|
tag_names = top_tags[0...SIDEBAR_TOP_TAGS_TO_SHOW]
|
|
|
|
serialized = serialize_tags(Tag.where(name: tag_names))
|
|
|
|
|
|
|
|
# Ensures order of top tags is preserved
|
|
|
|
serialized.sort_by { |tag| tag_names.index(tag[:name]) }
|
|
|
|
else
|
|
|
|
[]
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_navigation_menu_site_top_tags?
|
2023-10-08 19:24:10 -04:00
|
|
|
SiteSetting.tagging_enabled
|
2023-07-23 20:07:37 -04:00
|
|
|
end
|
|
|
|
|
2023-06-14 19:31:28 -04:00
|
|
|
def anonymous_default_navigation_menu_tags
|
2023-06-21 02:37:40 -04:00
|
|
|
@anonymous_default_navigation_menu_tags ||=
|
2023-07-23 20:07:37 -04:00
|
|
|
begin
|
|
|
|
tag_names =
|
|
|
|
SiteSetting.default_navigation_menu_tags.split("|") -
|
|
|
|
DiscourseTagging.hidden_tag_names(scope)
|
|
|
|
|
2023-10-19 20:18:49 -04:00
|
|
|
serialize_tags(Tag.where(name: tag_names).order(:name))
|
2023-07-23 20:07:37 -04:00
|
|
|
end
|
2022-08-23 04:20:46 -04:00
|
|
|
end
|
|
|
|
|
2023-06-14 19:31:28 -04:00
|
|
|
def include_anonymous_default_navigation_menu_tags?
|
2023-10-08 19:24:10 -04:00
|
|
|
scope.anonymous? && SiteSetting.tagging_enabled &&
|
2023-06-21 02:37:40 -04:00
|
|
|
SiteSetting.default_navigation_menu_tags.present? &&
|
|
|
|
anonymous_default_navigation_menu_tags.present?
|
2022-08-23 04:20:46 -04:00
|
|
|
end
|
|
|
|
|
2023-04-05 18:55:47 -04:00
|
|
|
def include_anonymous_sidebar_sections?
|
|
|
|
scope.anonymous?
|
|
|
|
end
|
|
|
|
|
2022-12-23 13:42:46 -05:00
|
|
|
def whispers_allowed_groups_names
|
2023-01-03 08:28:39 -05:00
|
|
|
Group.where(id: SiteSetting.whispers_allowed_groups_map).pluck(:name)
|
2022-12-23 13:42:46 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def include_whispers_allowed_groups_names?
|
|
|
|
scope.can_see_whispers?
|
|
|
|
end
|
|
|
|
|
2023-04-13 03:38:54 -04:00
|
|
|
def denied_emojis
|
|
|
|
@denied_emojis ||= Emoji.denied
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_denied_emojis?
|
|
|
|
denied_emojis.present?
|
|
|
|
end
|
|
|
|
|
2023-05-30 10:38:14 -04:00
|
|
|
def tos_url
|
2023-06-07 14:31:20 -04:00
|
|
|
Discourse.tos_url
|
2023-05-30 10:38:14 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def include_tos_url?
|
|
|
|
tos_url.present?
|
|
|
|
end
|
|
|
|
|
|
|
|
def privacy_policy_url
|
2023-06-07 14:31:20 -04:00
|
|
|
Discourse.privacy_policy_url
|
2023-05-30 10:38:14 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def include_privacy_policy_url?
|
|
|
|
privacy_policy_url.present?
|
|
|
|
end
|
|
|
|
|
2023-12-07 12:30:44 -05:00
|
|
|
def system_user_avatar_template
|
|
|
|
Discourse.system_user.avatar_template
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_system_user_avatar_template?
|
|
|
|
SiteSetting.show_user_menu_avatars
|
|
|
|
end
|
|
|
|
|
2024-01-17 13:26:51 -05:00
|
|
|
def lazy_load_categories
|
|
|
|
true
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_lazy_load_categories?
|
|
|
|
scope.can_lazy_load_categories?
|
|
|
|
end
|
|
|
|
|
2024-07-02 18:45:37 -04:00
|
|
|
def valid_flag_applies_to_types
|
|
|
|
Flag.valid_applies_to_types
|
|
|
|
end
|
|
|
|
|
|
|
|
def include_valid_flag_applies_to_types?
|
|
|
|
scope.is_admin?
|
|
|
|
end
|
|
|
|
|
2019-12-27 06:41:50 -05:00
|
|
|
private
|
|
|
|
|
|
|
|
def ordered_flags(flags)
|
2024-05-22 22:19:07 -04:00
|
|
|
flags.map { |id| PostActionType.new(id: id) }
|
2019-12-27 06:41:50 -05:00
|
|
|
end
|
2013-02-05 14:16:51 -05:00
|
|
|
end
|