discourse/plugins/chat/plugin.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

533 lines
18 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
# name: chat
# about: Adds chat functionality to your site so it can natively support both long-form and short-form communication needs of your online community.
# meta_topic_id: 230881
# version: 0.4
# authors: Kane York, Mark VanLandingham, Martin Brennan, Joffrey Jaffeux
# url: https://github.com/discourse/discourse/tree/main/plugins/chat
# meta_topic_id: 230881
enabled_site_setting :chat_enabled
register_asset "stylesheets/colors.scss", :color_definitions
register_asset "stylesheets/mixins/index.scss"
register_asset "stylesheets/common/index.scss"
register_asset "stylesheets/desktop/index.scss", :desktop
register_asset "stylesheets/mobile/index.scss", :mobile
register_svg_icon "comments"
register_svg_icon "comment-slash"
register_svg_icon "comment-dots"
register_svg_icon "lock"
register_svg_icon "clipboard"
register_svg_icon "file-audio"
register_svg_icon "file-video"
register_svg_icon "file-image"
register_svg_icon "stop-circle"
# route: /admin/plugins/chat
add_admin_route "chat.admin.title", "chat", use_new_show_route: true
GlobalSetting.add_default(:allow_unsecure_chat_uploads, false)
module ::Chat
PLUGIN_NAME = "chat"
RETENTION_SETTINGS_TO_USER_OPTION_FIELDS = {
chat_channel_retention_days: :dismissed_channel_retention_reminder,
chat_dm_retention_days: :dismissed_dm_retention_reminder,
}
end
require_relative "lib/chat/engine"
after_initialize do
register_seedfu_fixtures(Rails.root.join("plugins", "chat", "db", "fixtures"))
UserNotifications.append_view_path(File.expand_path("../app/views", __FILE__))
register_category_custom_field_type(Chat::HAS_CHAT_ENABLED, :boolean)
register_user_custom_field_type(Chat::LAST_CHAT_CHANNEL_ID, :integer)
DiscoursePluginRegistry.serialized_current_user_fields << Chat::LAST_CHAT_CHANNEL_ID
DiscoursePluginRegistry.register_flag_applies_to_type("Chat::Message", self)
UserUpdater::OPTION_ATTR.push(:chat_enabled)
UserUpdater::OPTION_ATTR.push(:only_chat_push_notifications)
UserUpdater::OPTION_ATTR.push(:chat_sound)
UserUpdater::OPTION_ATTR.push(:ignore_channel_wide_mention)
UserUpdater::OPTION_ATTR.push(:show_thread_title_prompts)
UserUpdater::OPTION_ATTR.push(:chat_email_frequency)
UserUpdater::OPTION_ATTR.push(:chat_header_indicator_preference)
UserUpdater::OPTION_ATTR.push(:chat_separate_sidebar_mode)
register_reviewable_type Chat::ReviewableMessage
reloadable_patch do |plugin|
Site.preloaded_category_custom_fields << Chat::HAS_CHAT_ENABLED
Guardian.prepend Chat::GuardianExtensions
UserNotifications.prepend Chat::UserNotificationsExtension
Notifications::ConsolidationPlan.prepend Chat::NotificationConsolidationExtension
UserOption.prepend Chat::UserOptionExtension
Category.prepend Chat::CategoryExtension
Reviewable.prepend Chat::ReviewableExtension
Bookmark.prepend Chat::BookmarkExtension
User.prepend Chat::UserExtension
Group.prepend Chat::GroupExtension
Plugin::Instance.prepend Chat::PluginInstanceExtension
Jobs::ExportCsvFile.prepend Chat::MessagesExporter
WebHook.prepend Chat::OutgoingWebHookExtension
end
if Oneboxer.respond_to?(:register_local_handler)
Oneboxer.register_local_handler("chat/chat") do |url, route|
Chat::OneboxHandler.handle(url, route)
end
end
if InlineOneboxer.respond_to?(:register_local_handler)
InlineOneboxer.register_local_handler("chat/chat") do |url, route|
if route[:message_id].present?
message = Chat::Message.find_by(id: route[:message_id])
next if !message
chat_channel = message.chat_channel
user = message.user
next if !chat_channel || !user
title =
I18n.t(
"chat.onebox.inline_to_message",
message_id: message.id,
chat_channel: chat_channel.name,
username: user.username,
)
else
chat_channel = Chat::Channel.find_by(id: route[:channel_id])
next if !chat_channel
title =
if chat_channel.name.present?
I18n.t("chat.onebox.inline_to_channel", chat_channel: chat_channel.name)
end
end
next if !Guardian.new.can_preview_chat_channel?(chat_channel)
{ url: url, title: title }
end
end
if respond_to?(:register_upload_in_use)
register_upload_in_use do |upload|
Chat::Message.where(
"message LIKE ? OR message LIKE ?",
"%#{upload.sha1}%",
"%#{upload.base62_sha1}%",
).exists? ||
Chat::Draft.where(
"data LIKE ? OR data LIKE ?",
"%#{upload.sha1}%",
"%#{upload.base62_sha1}%",
).exists?
end
end
add_to_serializer(:user_card, :can_chat_user) do
return false if !SiteSetting.chat_enabled
return false if scope.user.blank?
return false if !scope.user.user_option.chat_enabled || !object.user_option.chat_enabled
scope.can_direct_message? && Guardian.new(object).can_chat?
end
add_to_serializer(:hidden_profile, :can_chat_user) do
return false if !SiteSetting.chat_enabled
return false if scope.user.blank?
return false if !scope.user.user_option.chat_enabled || !object.user_option.chat_enabled
scope.can_direct_message? && Guardian.new(object).can_chat?
end
add_to_serializer(
:current_user,
:can_chat,
include_condition: -> do
return @can_chat if defined?(@can_chat)
@can_chat = SiteSetting.chat_enabled && scope.can_chat?
end,
) { true }
add_to_serializer(
:current_user,
:can_direct_message,
include_condition: -> do
return @can_direct_message if defined?(@can_direct_message)
@can_direct_message = include_has_chat_enabled? && scope.can_direct_message?
end,
) { true }
add_to_serializer(
:current_user,
:has_chat_enabled,
include_condition: -> do
return @has_chat_enabled if defined?(@has_chat_enabled)
@has_chat_enabled = include_can_chat? && object.user_option.chat_enabled
end,
) { true }
add_to_serializer(
:current_user,
:chat_sound,
include_condition: -> { include_has_chat_enabled? && object.user_option.chat_sound },
) { object.user_option.chat_sound }
add_to_serializer(
:current_user,
:needs_channel_retention_reminder,
include_condition: -> do
include_has_chat_enabled? && object.staff? &&
!object.user_option.dismissed_channel_retention_reminder &&
!SiteSetting.chat_channel_retention_days.zero?
end,
) { true }
add_to_serializer(
:current_user,
:needs_dm_retention_reminder,
include_condition: -> do
include_has_chat_enabled? && !object.user_option.dismissed_dm_retention_reminder &&
!SiteSetting.chat_dm_retention_days.zero?
end,
) { true }
add_to_serializer(:current_user, :has_joinable_public_channels) do
Chat::ChannelFetcher.secured_public_channel_search(
self.scope,
following: false,
limit: 1,
status: :open,
).exists?
end
add_to_serializer(
:current_user,
:chat_drafts,
include_condition: -> { include_has_chat_enabled? },
) do
Chat::Draft
.where(user_id: object.id)
.order(updated_at: :desc)
.limit(20)
.pluck(:chat_channel_id, :data, :thread_id)
.map { |row| { channel_id: row[0], data: row[1], thread_id: row[2] } }
end
add_to_serializer(
:user_notification_total,
:chat_notifications,
include_condition: -> do
return @has_chat_enabled if defined?(@has_chat_enabled)
@has_chat_enabled =
SiteSetting.chat_enabled && scope.can_chat? && object.user_option.chat_enabled
end,
) { Chat::ChannelFetcher.unreads_total(self.scope) }
add_to_serializer(:user_option, :chat_enabled) { object.chat_enabled }
add_to_serializer(
:user_option,
:chat_sound,
include_condition: -> { !object.chat_sound.blank? },
) { object.chat_sound }
add_to_serializer(:user_option, :only_chat_push_notifications) do
object.only_chat_push_notifications
end
add_to_serializer(:user_option, :ignore_channel_wide_mention) do
object.ignore_channel_wide_mention
end
add_to_serializer(:user_option, :show_thread_title_prompts) { object.show_thread_title_prompts }
add_to_serializer(:current_user_option, :show_thread_title_prompts) do
object.show_thread_title_prompts
end
add_to_serializer(:user_option, :chat_email_frequency) { object.chat_email_frequency }
add_to_serializer(:user_option, :chat_header_indicator_preference) do
object.chat_header_indicator_preference
end
add_to_serializer(:current_user_option, :chat_header_indicator_preference) do
object.chat_header_indicator_preference
end
add_to_serializer(:user_option, :chat_separate_sidebar_mode) { object.chat_separate_sidebar_mode }
add_to_serializer(:current_user_option, :chat_separate_sidebar_mode) do
object.chat_separate_sidebar_mode
end
on(:site_setting_changed) do |name, old_value, new_value|
user_option_field = Chat::RETENTION_SETTINGS_TO_USER_OPTION_FIELDS[name.to_sym]
begin
if user_option_field && old_value != new_value && !new_value.zero?
UserOption.where(user_option_field => true).update_all(user_option_field => false)
end
rescue => e
Rails.logger.warn(
"Error updating user_options fields after chat retention settings changed: #{e}",
)
end
if name == :secure_uploads && old_value == false && new_value == true
Chat::SecureUploadsCompatibility.update_settings
end
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-22 08:19:59 +08:00
if name == :chat_allowed_groups
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
Jobs.enqueue(Jobs::Chat::AutoJoinUsers, event: "chat_allowed_groups_changed")
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-22 08:19:59 +08:00
end
end
on(:post_alerter_after_save_post) do |post, new_record, notified|
next if !new_record
Chat::PostNotificationHandler.new(post, notified).handle
end
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
on(:group_destroyed) do |group, _user_ids|
Chat::AutoLeaveChannels.call(params: { group_id: group.id, event: :group_destroyed })
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-22 08:19:59 +08:00
end
register_presence_channel_prefix("chat") do |channel_name|
next nil unless channel_name == "/chat/online"
config = PresenceChannel::Config.new
config.allowed_group_ids = Chat.allowed_group_ids
config
end
register_presence_channel_prefix("chat-reply") do |channel_name|
if (
channel_id, thread_id =
channel_name.match(%r{^/chat-reply/(\d+)(?:/thread/(\d+))?$})&.captures
)
chat_channel = nil
if thread_id
chat_channel = Chat::Thread.find_by!(id: thread_id, channel_id: channel_id).channel
else
chat_channel = Chat::Channel.find(channel_id)
end
PresenceChannel::Config.new.tap do |config|
config.allowed_group_ids = chat_channel.allowed_group_ids
config.allowed_user_ids = chat_channel.allowed_user_ids
config.public = !chat_channel.read_restricted?
end
end
rescue ActiveRecord::RecordNotFound
nil
end
register_presence_channel_prefix("chat-user") do |channel_name|
if user_id = channel_name[%r{/chat-user/(chat|core)/(\d+)}, 2]
user = User.find(user_id)
config = PresenceChannel::Config.new
config.allowed_user_ids = [user.id]
config
end
rescue ActiveRecord::RecordNotFound
nil
end
register_push_notification_filter do |user, payload|
if user.user_option.only_chat_push_notifications && user.user_option.chat_enabled
payload[:notification_type].in?(::Notification.types.values_at(:chat_mention, :chat_message))
else
true
end
end
on(:user_seen) do |user|
if user.last_seen_at == user.first_seen_at
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
Chat::AutoJoinChannels.call(params: { user_id: user.id })
end
end
on(:user_confirmed_email) do |user|
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
Chat::AutoJoinChannels.call(params: { user_id: user.id }) if user.active?
end
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
on(:user_added_to_group) do |user, _group|
Chat::AutoJoinChannels.call(params: { user_id: user.id })
end
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
on(:user_removed_from_group) do |user, _group|
Chat::AutoLeaveChannels.call(params: { user_id: user.id, event: :user_removed_from_group })
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-22 08:19:59 +08:00
end
on(:category_updated) do |category|
# There's a bug on core where this event is triggered with an `#update` result (true/false)
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
next unless category.is_a?(Category)
next unless category_channel = Chat::Channel.find_by(chatable: category)
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
if category_channel.auto_join_users
Chat::AutoJoinChannels.call(params: { category_id: category.id })
end
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-12 12:00:59 +08:00
Chat::AutoLeaveChannels.call(params: { category_id: category.id, event: :category_updated })
end
# outgoing webhook events
%i[
chat_message_created
chat_message_edited
chat_message_trashed
chat_message_restored
].each do |chat_message_event|
on(chat_message_event) do |message, channel, user|
guardian = Guardian.new(user)
payload = {
message: Chat::MessageSerializer.new(message, { scope: guardian, root: false }).as_json,
channel:
Chat::ChannelSerializer.new(
channel,
{ scope: guardian, membership: channel.membership_for(user), root: false },
).as_json,
}
category_id = channel.chatable_type == "Category" ? channel.chatable_id : nil
WebHook.enqueue_chat_message_hooks(
chat_message_event,
payload.to_json,
category_id: category_id,
)
end
end
Discourse::Application.routes.append do
mount ::Chat::Engine, at: "/chat"
get "/admin/plugins/chat/hooks" => "chat/admin/incoming_webhooks#index",
:constraints => StaffConstraint.new
post "/admin/plugins/chat/hooks" => "chat/admin/incoming_webhooks#create",
:constraints => StaffConstraint.new
put "/admin/plugins/chat/hooks/:incoming_chat_webhook_id" =>
"chat/admin/incoming_webhooks#update",
:constraints => StaffConstraint.new
get "/admin/plugins/chat/hooks/new" => "chat/admin/incoming_webhooks#new",
:constraints => StaffConstraint.new
get "/admin/plugins/chat/hooks/:incoming_chat_webhook_id" =>
"chat/admin/incoming_webhooks#show",
:constraints => StaffConstraint.new
delete "/admin/plugins/chat/hooks/:incoming_chat_webhook_id" =>
"chat/admin/incoming_webhooks#destroy",
:constraints => StaffConstraint.new
get "u/:username/preferences/chat" => "users#preferences",
:constraints => {
username: RouteFormat.username,
}
end
add_automation_scriptable("send_chat_message") do
field :chat_channel_id, component: :text, required: true
field :message, component: :message, required: true, accepts_placeholders: true
field :sender, component: :user
placeholder :channel_name
placeholder :post_quote, triggerable: :post_created_edited
triggerables %i[recurring topic_tags_changed post_created_edited]
script do |context, fields, automation|
sender = User.find_by(username: fields.dig("sender", "value")) || Discourse.system_user
channel = Chat::Channel.find_by(id: fields.dig("chat_channel_id", "value"))
placeholders = { channel_name: channel.title(sender) }.merge(context["placeholders"] || {})
if context["kind"] == "post_created_edited"
placeholders[:post_quote] = utils.build_quote(context["post"])
end
creator =
::Chat::CreateMessage.call(
guardian: sender.guardian,
params: {
chat_channel_id: channel.id,
message: utils.apply_placeholders(fields.dig("message", "value"), placeholders),
},
)
if creator.failure?
Rails.logger.warn "[discourse-automation] Chat message failed to send:\n#{creator.inspect_steps.inspect}\n#{creator.inspect_steps.error}"
end
end
end
add_api_key_scope(
:chat,
{
create_message: {
actions: %w[chat/api/channel_messages#create],
params: %i[chat_channel_id],
},
},
)
# Dark mode email styles
Email::Styles.register_plugin_style do |fragment|
fragment.css(".chat-summary-header").each { |element| element[:dm] = "header" }
fragment.css(".chat-summary-content").each { |element| element[:dm] = "body" }
end
register_email_unsubscriber("chat_summary", EmailControllerHelper::ChatSummaryUnsubscriber)
register_stat("chat_messages", expose_via_api: true) { Chat::Statistics.about_messages }
register_stat("chat_users", expose_via_api: true) { Chat::Statistics.about_users }
register_stat("chat_channels", expose_via_api: true) { Chat::Statistics.about_channels }
register_stat("chat_channel_messages") { Chat::Statistics.channel_messages }
register_stat("chat_direct_messages") { Chat::Statistics.direct_messages }
register_stat("chat_open_channels_with_threads_enabled") do
Chat::Statistics.open_channels_with_threads_enabled
end
register_stat("chat_threaded_messages") { Chat::Statistics.threaded_messages }
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 06:37:06 +08:00
# Make sure to update spec/system/hashtag_autocomplete_spec.rb when changing this.
register_hashtag_data_source(Chat::ChannelHashtagDataSource)
register_hashtag_type_priority_for_context("channel", "chat-composer", 200)
register_hashtag_type_priority_for_context("category", "chat-composer", 100)
register_hashtag_type_priority_for_context("tag", "chat-composer", 50)
register_hashtag_type_priority_for_context("channel", "topic-composer", 10)
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 06:37:06 +08:00
register_post_stripper do |nokogiri_fragment|
nokogiri_fragment.css(".chat-transcript .mention").remove
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-21 06:37:06 +08:00
Site.markdown_additional_options["chat"] = {
limited_pretty_text_features: Chat::Message::MARKDOWN_FEATURES,
limited_pretty_text_markdown_rules: Chat::Message::MARKDOWN_IT_RULES,
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 06:37:06 +08:00
hashtag_configurations: HashtagAutocompleteService.contexts_with_ordered_types,
}
register_user_destroyer_on_content_deletion_callback(
Proc.new { |user| Jobs.enqueue(Jobs::Chat::DeleteUserMessages, user_id: user.id) },
)
register_notification_consolidation_plan(
Chat::NotificationConsolidationExtension.watched_thread_message_plan,
)
register_bookmarkable(Chat::MessageBookmarkable)
# When we eventually allow secure_uploads in chat, this will need to be
# removed. Depending on the channel, uploads may end up being secure.
UploadSecurity.register_custom_public_type("chat-composer")
end
if Rails.env == "test"
Dir[Rails.root.join("plugins/chat/spec/support/**/*.rb")].each { |f| require f }
end