2019-05-02 18:17:27 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2016-06-14 14:31:51 -04:00
|
|
|
module PrettyText
|
|
|
|
module Helpers
|
|
|
|
extend self
|
|
|
|
|
2020-07-13 12:13:17 -04:00
|
|
|
TAG_HASHTAG_POSTFIX = "::tag"
|
|
|
|
|
2016-06-14 14:31:51 -04:00
|
|
|
# functions here are available to v8
|
|
|
|
def t(key, opts)
|
|
|
|
key = "js." + key
|
2023-02-16 04:40:11 -05:00
|
|
|
return I18n.t(key) if opts.blank?
|
|
|
|
str = I18n.t(key, Hash[opts.entries].symbolize_keys).dup
|
2023-12-06 17:25:00 -05:00
|
|
|
opts.each { |k, v| str.gsub!("{{#{k}}}", v.to_s) }
|
2023-02-16 04:40:11 -05:00
|
|
|
str
|
2016-06-14 14:31:51 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def avatar_template(username)
|
|
|
|
return "" unless username
|
|
|
|
user = User.find_by(username_lower: username.downcase)
|
2024-05-27 06:27:13 -04:00
|
|
|
return "" if user.blank?
|
2016-06-14 14:31:51 -04:00
|
|
|
|
|
|
|
# TODO: Add support for ES6 and call `avatar-template` directly
|
2017-10-06 14:00:39 -04:00
|
|
|
UrlHelper.schemaless(UrlHelper.absolute(user.avatar_template))
|
2016-06-14 14:31:51 -04:00
|
|
|
end
|
|
|
|
|
2017-11-03 09:51:40 -04:00
|
|
|
def lookup_primary_user_group(username)
|
|
|
|
return "" unless username
|
|
|
|
user = User.find_by(username_lower: username.downcase)
|
2024-05-27 06:27:13 -04:00
|
|
|
return "" if user.blank?
|
2017-11-03 09:51:40 -04:00
|
|
|
|
|
|
|
user.primary_group.try(:name) || ""
|
|
|
|
end
|
|
|
|
|
2017-11-20 16:28:03 -05:00
|
|
|
# Overwrite this in a plugin to change how markdown can format
|
|
|
|
# usernames on the server side
|
|
|
|
def format_username(username)
|
|
|
|
username
|
|
|
|
end
|
|
|
|
|
2019-05-28 21:00:25 -04:00
|
|
|
def lookup_upload_urls(urls)
|
2017-08-22 11:46:15 -04:00
|
|
|
map = {}
|
|
|
|
result = {}
|
|
|
|
|
|
|
|
urls.each do |url|
|
|
|
|
sha1 = Upload.sha1_from_short_url(url)
|
2024-05-29 10:24:29 -04:00
|
|
|
if (url.split(".")[1].nil?) # video sha1 without extension for thumbnail
|
|
|
|
thumbnail = Upload.where("original_filename LIKE ?", "#{sha1}.%").last
|
|
|
|
sha1 = thumbnail.sha1 if thumbnail
|
|
|
|
end
|
2017-08-22 11:46:15 -04:00
|
|
|
map[url] = sha1 if sha1
|
|
|
|
end
|
|
|
|
|
|
|
|
if map.length > 0
|
2018-09-05 09:46:43 -04:00
|
|
|
reverse_map = {}
|
|
|
|
|
|
|
|
map.each do |key, value|
|
|
|
|
reverse_map[value] ||= []
|
|
|
|
reverse_map[value] << key
|
|
|
|
end
|
2017-08-22 11:46:15 -04:00
|
|
|
|
2019-11-17 20:25:42 -05:00
|
|
|
Upload
|
|
|
|
.where(sha1: map.values)
|
|
|
|
.pluck(:sha1, :url, :extension, :original_filename, :secure)
|
|
|
|
.each do |row|
|
|
|
|
sha1, url, extension, original_filename, secure = row
|
2023-01-09 07:10:19 -05:00
|
|
|
|
2018-09-05 09:46:43 -04:00
|
|
|
if short_urls = reverse_map[sha1]
|
2022-09-28 19:24:33 -04:00
|
|
|
secure_uploads = SiteSetting.secure_uploads? && secure
|
2023-01-09 07:10:19 -05:00
|
|
|
|
2019-05-28 21:00:25 -04:00
|
|
|
short_urls.each do |short_url|
|
|
|
|
result[short_url] = {
|
2022-09-28 19:24:33 -04:00
|
|
|
url:
|
2023-01-09 07:10:19 -05:00
|
|
|
(
|
2022-09-28 19:24:33 -04:00
|
|
|
if secure_uploads
|
|
|
|
Upload.secure_uploads_url_from_upload_url(url)
|
2023-01-09 07:10:19 -05:00
|
|
|
else
|
2022-09-28 19:24:33 -04:00
|
|
|
Discourse.store.cdn_url(url)
|
2023-01-09 07:10:19 -05:00
|
|
|
end
|
2022-09-28 19:24:33 -04:00
|
|
|
),
|
2019-06-10 21:15:45 -04:00
|
|
|
short_path: Upload.short_path(sha1: sha1, extension: extension),
|
|
|
|
base62_sha1: Upload.base62_sha1(sha1),
|
2019-05-28 21:00:25 -04:00
|
|
|
}
|
2023-01-09 07:10:19 -05:00
|
|
|
end
|
2019-05-28 21:00:25 -04:00
|
|
|
end
|
2017-08-22 11:46:15 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
result
|
|
|
|
end
|
|
|
|
|
2016-06-14 14:31:51 -04:00
|
|
|
def get_topic_info(topic_id)
|
2017-04-15 00:11:02 -04:00
|
|
|
return unless topic_id.is_a?(Integer)
|
2016-06-14 14:31:51 -04:00
|
|
|
# TODO this only handles public topics, secured one do not get this
|
|
|
|
topic = Topic.find_by(id: topic_id)
|
2023-12-06 01:37:32 -05:00
|
|
|
if topic && Guardian.new.can_see?(topic)
|
2017-01-09 14:52:45 -05:00
|
|
|
{ title: Rack::Utils.escape_html(topic.title), href: topic.url }
|
2018-12-02 13:22:40 -05:00
|
|
|
elsif topic
|
2024-02-13 00:20:24 -05:00
|
|
|
{ title: I18n.t("on_another_topic"), href: topic.slugless_url }
|
2016-06-14 14:31:51 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-12-08 19:34:25 -05:00
|
|
|
def hashtag_lookup(slug, cooking_user_id, types_in_priority_order)
|
2022-12-18 20:05:37 -05:00
|
|
|
# NOTE: This is _somewhat_ expected since we need to be able to cook posts
|
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
|
|
|
# etc. without a user sometimes, but it is still an edge case.
|
2022-12-18 20:05:37 -05:00
|
|
|
#
|
|
|
|
# The Discourse.system_user is usually an admin with access to _all_
|
|
|
|
# categories, however if the suppress_secured_categories_from_admin
|
|
|
|
# site setting is activated then this user will not be able to access
|
|
|
|
# secure categories, so hashtags that are secure will not render.
|
2022-12-08 19:34:25 -05:00
|
|
|
if cooking_user_id.blank?
|
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
|
|
|
cooking_user = Discourse.system_user
|
2022-12-08 19:34:25 -05:00
|
|
|
else
|
|
|
|
cooking_user = User.find(cooking_user_id)
|
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-18 20:52:18 -04:00
|
|
|
types_in_priority_order =
|
|
|
|
types_in_priority_order.select do |type|
|
|
|
|
HashtagAutocompleteService.data_source_types.include?(type)
|
|
|
|
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
|
|
|
result =
|
|
|
|
HashtagAutocompleteService.new(Guardian.new(cooking_user)).lookup(
|
|
|
|
[slug],
|
|
|
|
types_in_priority_order,
|
|
|
|
)
|
|
|
|
|
|
|
|
found_hashtag = nil
|
|
|
|
types_in_priority_order.each do |type|
|
|
|
|
if result[type.to_sym].any?
|
|
|
|
found_hashtag = result[type.to_sym].first.to_h
|
|
|
|
break
|
|
|
|
end
|
|
|
|
end
|
|
|
|
found_hashtag
|
|
|
|
end
|
|
|
|
|
2016-07-07 03:52:56 -04:00
|
|
|
def get_current_user(user_id)
|
2017-04-25 03:19:12 -04:00
|
|
|
return unless user_id.is_a?(Integer)
|
2017-04-24 16:56:12 -04:00
|
|
|
{ staff: User.where(id: user_id).where("moderator OR admin").exists? }
|
2016-07-07 03:52:56 -04:00
|
|
|
end
|
2016-06-14 14:31:51 -04:00
|
|
|
end
|
|
|
|
end
|