2022-11-02 21:41:30 +08:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
##
|
|
|
|
# Used to move chat messages from a chat channel to some other
|
|
|
|
# location.
|
|
|
|
#
|
|
|
|
# Channel -> Channel:
|
|
|
|
# -------------------
|
|
|
|
#
|
|
|
|
# Messages are sometimes misplaced and must be moved to another channel. For
|
|
|
|
# now we only support moving messages between public channels, handling the
|
|
|
|
# permissions and membership around moving things in and out of DMs is a little
|
|
|
|
# much for V1.
|
|
|
|
#
|
|
|
|
# The original messages will be deleted, and then similar to PostMover in core,
|
|
|
|
# all of the references associated to a chat message (e.g. reactions, bookmarks,
|
|
|
|
# notifications, revisions, mentions, uploads) will be updated to the new
|
|
|
|
# message IDs via a moved_chat_messages temporary table.
|
FEATURE: Automatically create chat threads in background (#20206)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.
If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.
* Root message (ID 1) - no thread ID
* Message (ID 2, in_reply_to 1) - no thread ID
* When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message
If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.
* Root message (ID 1) - thread ID 700
* Message (ID 2, in_reply_to 1) - thread ID 700
* When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message
We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.
This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.
This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.
This commit also includes thread considerations in the `MessageMover` class:
* If the original message and N other messages of a thread is moved,
the remaining messages in the thread have a new thread created in
the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
not created in the destination channel.
In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 08:22:07 +08:00
|
|
|
#
|
|
|
|
# Reply chains are a little complex. No reply chains are preserved when moving
|
|
|
|
# messages into a new channel. Remaining messages that referenced moved ones
|
|
|
|
# have their in_reply_to_id cleared so the data makes sense.
|
|
|
|
#
|
|
|
|
# Threads are even more complex. No threads are preserved when moving messages
|
|
|
|
# into a new channel, they end up as just a flat series of messages that are
|
|
|
|
# not in a chain. If the original message of a thread and N other messages
|
|
|
|
# in that thread, then any messages left behind just get placed into a new
|
|
|
|
# thread. Message moving will be disabled in the thread UI while
|
|
|
|
# enable_experimental_chat_threaded_discussions is present, its too complicated
|
|
|
|
# to have end users reason about for now, and we may want a standalone
|
|
|
|
# "Move Thread" UI later on.
|
2022-11-02 21:41:30 +08:00
|
|
|
class Chat::MessageMover
|
|
|
|
class NoMessagesFound < StandardError
|
|
|
|
end
|
|
|
|
class InvalidChannel < StandardError
|
|
|
|
end
|
|
|
|
|
|
|
|
def initialize(acting_user:, source_channel:, message_ids:)
|
|
|
|
@source_channel = source_channel
|
|
|
|
@acting_user = acting_user
|
|
|
|
@source_message_ids = message_ids
|
|
|
|
@source_messages = find_messages(@source_message_ids, source_channel)
|
|
|
|
@ordered_source_message_ids = @source_messages.map(&:id)
|
|
|
|
end
|
|
|
|
|
|
|
|
def move_to_channel(destination_channel)
|
|
|
|
if !@source_channel.public_channel? || !destination_channel.public_channel?
|
|
|
|
raise InvalidChannel.new(I18n.t("chat.errors.message_move_invalid_channel"))
|
|
|
|
end
|
|
|
|
|
|
|
|
if @ordered_source_message_ids.empty?
|
|
|
|
raise NoMessagesFound.new(I18n.t("chat.errors.message_move_no_messages_found"))
|
|
|
|
end
|
|
|
|
|
|
|
|
moved_messages = nil
|
|
|
|
|
|
|
|
ChatMessage.transaction do
|
|
|
|
create_temp_table
|
|
|
|
moved_messages =
|
|
|
|
find_messages(
|
|
|
|
create_destination_messages_in_channel(destination_channel),
|
|
|
|
destination_channel,
|
|
|
|
)
|
|
|
|
bulk_insert_movement_metadata
|
|
|
|
update_references
|
|
|
|
delete_source_messages
|
FEATURE: Automatically create chat threads in background (#20206)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.
If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.
* Root message (ID 1) - no thread ID
* Message (ID 2, in_reply_to 1) - no thread ID
* When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message
If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.
* Root message (ID 1) - thread ID 700
* Message (ID 2, in_reply_to 1) - thread ID 700
* When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message
We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.
This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.
This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.
This commit also includes thread considerations in the `MessageMover` class:
* If the original message and N other messages of a thread is moved,
the remaining messages in the thread have a new thread created in
the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
not created in the destination channel.
In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 08:22:07 +08:00
|
|
|
update_reply_references
|
|
|
|
update_thread_references
|
2022-11-02 21:41:30 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
add_moved_placeholder(destination_channel, moved_messages.first)
|
|
|
|
moved_messages
|
|
|
|
end
|
|
|
|
|
|
|
|
private
|
|
|
|
|
|
|
|
def find_messages(message_ids, channel)
|
FEATURE: Automatically create chat threads in background (#20206)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.
If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.
* Root message (ID 1) - no thread ID
* Message (ID 2, in_reply_to 1) - no thread ID
* When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message
If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.
* Root message (ID 1) - thread ID 700
* Message (ID 2, in_reply_to 1) - thread ID 700
* When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message
We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.
This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.
This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.
This commit also includes thread considerations in the `MessageMover` class:
* If the original message and N other messages of a thread is moved,
the remaining messages in the thread have a new thread created in
the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
not created in the destination channel.
In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 08:22:07 +08:00
|
|
|
ChatMessage
|
|
|
|
.includes(thread: %i[original_message original_message_user])
|
|
|
|
.where(id: message_ids, chat_channel_id: channel.id)
|
|
|
|
.order("created_at ASC, id ASC")
|
2022-11-02 21:41:30 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
def create_temp_table
|
|
|
|
DB.exec("DROP TABLE IF EXISTS moved_chat_messages") if Rails.env.test?
|
|
|
|
|
|
|
|
DB.exec <<~SQL
|
|
|
|
CREATE TEMPORARY TABLE moved_chat_messages (
|
|
|
|
old_chat_message_id INTEGER,
|
|
|
|
new_chat_message_id INTEGER
|
|
|
|
) ON COMMIT DROP;
|
|
|
|
|
|
|
|
CREATE INDEX moved_chat_messages_old_chat_message_id ON moved_chat_messages(old_chat_message_id);
|
|
|
|
SQL
|
|
|
|
end
|
|
|
|
|
|
|
|
def bulk_insert_movement_metadata
|
|
|
|
values_sql = @movement_metadata.map { |mm| "(#{mm[:old_id]}, #{mm[:new_id]})" }.join(",\n")
|
|
|
|
DB.exec(
|
|
|
|
"INSERT INTO moved_chat_messages(old_chat_message_id, new_chat_message_id) VALUES #{values_sql}",
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
##
|
|
|
|
# We purposefully omit in_reply_to_id when creating the messages in the
|
|
|
|
# new channel, because it could be pointing to a message that has not
|
|
|
|
# been moved.
|
|
|
|
def create_destination_messages_in_channel(destination_channel)
|
|
|
|
query_args = {
|
|
|
|
message_ids: @ordered_source_message_ids,
|
|
|
|
destination_channel_id: destination_channel.id,
|
|
|
|
}
|
|
|
|
moved_message_ids = DB.query_single(<<~SQL, query_args)
|
2022-11-08 07:06:13 +08:00
|
|
|
INSERT INTO chat_messages(
|
|
|
|
chat_channel_id, user_id, last_editor_id, message, cooked, cooked_version, created_at, updated_at
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
SELECT :destination_channel_id,
|
|
|
|
user_id,
|
2022-11-08 07:06:13 +08:00
|
|
|
last_editor_id,
|
2022-11-02 21:41:30 +08:00
|
|
|
message,
|
|
|
|
cooked,
|
|
|
|
cooked_version,
|
|
|
|
CLOCK_TIMESTAMP(),
|
|
|
|
CLOCK_TIMESTAMP()
|
|
|
|
FROM chat_messages
|
|
|
|
WHERE id IN (:message_ids)
|
|
|
|
RETURNING id
|
|
|
|
SQL
|
|
|
|
|
|
|
|
@movement_metadata =
|
|
|
|
moved_message_ids.map.with_index do |chat_message_id, idx|
|
|
|
|
{ old_id: @ordered_source_message_ids[idx], new_id: chat_message_id }
|
|
|
|
end
|
|
|
|
moved_message_ids
|
|
|
|
end
|
|
|
|
|
|
|
|
def update_references
|
|
|
|
DB.exec(<<~SQL)
|
|
|
|
UPDATE chat_message_reactions cmr
|
|
|
|
SET chat_message_id = mm.new_chat_message_id
|
|
|
|
FROM moved_chat_messages mm
|
|
|
|
WHERE cmr.chat_message_id = mm.old_chat_message_id
|
|
|
|
SQL
|
|
|
|
|
|
|
|
DB.exec(<<~SQL)
|
2023-01-24 11:28:21 +08:00
|
|
|
UPDATE upload_references uref
|
|
|
|
SET target_id = mm.new_chat_message_id
|
2022-11-02 21:41:30 +08:00
|
|
|
FROM moved_chat_messages mm
|
2023-01-24 11:28:21 +08:00
|
|
|
WHERE uref.target_id = mm.old_chat_message_id AND uref.target_type = 'ChatMessage'
|
2022-11-02 21:41:30 +08:00
|
|
|
SQL
|
|
|
|
|
|
|
|
DB.exec(<<~SQL)
|
|
|
|
UPDATE chat_mentions cment
|
|
|
|
SET chat_message_id = mm.new_chat_message_id
|
|
|
|
FROM moved_chat_messages mm
|
|
|
|
WHERE cment.chat_message_id = mm.old_chat_message_id
|
|
|
|
SQL
|
|
|
|
|
|
|
|
DB.exec(<<~SQL)
|
|
|
|
UPDATE chat_message_revisions crev
|
|
|
|
SET chat_message_id = mm.new_chat_message_id
|
|
|
|
FROM moved_chat_messages mm
|
|
|
|
WHERE crev.chat_message_id = mm.old_chat_message_id
|
|
|
|
SQL
|
|
|
|
|
|
|
|
DB.exec(<<~SQL)
|
|
|
|
UPDATE chat_webhook_events cweb
|
|
|
|
SET chat_message_id = mm.new_chat_message_id
|
|
|
|
FROM moved_chat_messages mm
|
|
|
|
WHERE cweb.chat_message_id = mm.old_chat_message_id
|
|
|
|
SQL
|
|
|
|
end
|
|
|
|
|
|
|
|
def delete_source_messages
|
FEATURE: Automatically create chat threads in background (#20206)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.
If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.
* Root message (ID 1) - no thread ID
* Message (ID 2, in_reply_to 1) - no thread ID
* When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message
If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.
* Root message (ID 1) - thread ID 700
* Message (ID 2, in_reply_to 1) - thread ID 700
* When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message
We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.
This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.
This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.
This commit also includes thread considerations in the `MessageMover` class:
* If the original message and N other messages of a thread is moved,
the remaining messages in the thread have a new thread created in
the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
not created in the destination channel.
In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 08:22:07 +08:00
|
|
|
# We do this so @source_messages is not nulled out, which is the
|
|
|
|
# case when using update_all here.
|
|
|
|
DB.exec(<<~SQL, source_message_ids: @source_message_ids, deleted_by_id: @acting_user.id)
|
|
|
|
UPDATE chat_messages
|
|
|
|
SET deleted_at = NOW(), deleted_by_id = :deleted_by_id
|
|
|
|
WHERE id IN (:source_message_ids)
|
|
|
|
SQL
|
2022-11-02 21:41:30 +08:00
|
|
|
ChatPublisher.publish_bulk_delete!(@source_channel, @source_message_ids)
|
|
|
|
end
|
|
|
|
|
|
|
|
def add_moved_placeholder(destination_channel, first_moved_message)
|
|
|
|
Chat::ChatMessageCreator.create(
|
|
|
|
chat_channel: @source_channel,
|
|
|
|
user: Discourse.system_user,
|
|
|
|
content:
|
|
|
|
I18n.t(
|
|
|
|
"chat.channel.messages_moved",
|
|
|
|
count: @source_message_ids.length,
|
|
|
|
acting_username: @acting_user.username,
|
|
|
|
channel_name: destination_channel.title(@acting_user),
|
|
|
|
first_moved_message_url: first_moved_message.url,
|
|
|
|
),
|
|
|
|
)
|
|
|
|
end
|
FEATURE: Automatically create chat threads in background (#20206)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.
If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.
* Root message (ID 1) - no thread ID
* Message (ID 2, in_reply_to 1) - no thread ID
* When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message
If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.
* Root message (ID 1) - thread ID 700
* Message (ID 2, in_reply_to 1) - thread ID 700
* When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message
We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.
This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.
This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.
This commit also includes thread considerations in the `MessageMover` class:
* If the original message and N other messages of a thread is moved,
the remaining messages in the thread have a new thread created in
the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
not created in the destination channel.
In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 08:22:07 +08:00
|
|
|
|
|
|
|
def update_reply_references
|
|
|
|
DB.exec(<<~SQL, deleted_reply_to_ids: @source_message_ids)
|
|
|
|
UPDATE chat_messages
|
|
|
|
SET in_reply_to_id = NULL
|
|
|
|
WHERE in_reply_to_id IN (:deleted_reply_to_ids)
|
|
|
|
SQL
|
|
|
|
end
|
|
|
|
|
|
|
|
def update_thread_references
|
|
|
|
threads_to_update = []
|
|
|
|
@source_messages
|
|
|
|
.select { |message| message.thread_id.present? }
|
|
|
|
.each do |message_with_thread|
|
|
|
|
# If one of the messages we are moving is the original message in a thread,
|
|
|
|
# then all the remaining messages for that thread must be moved to a new one,
|
|
|
|
# otherwise they will be pointing to a thread in a different channel.
|
|
|
|
if message_with_thread.thread.original_message_id == message_with_thread.id
|
|
|
|
threads_to_update << message_with_thread.thread
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
threads_to_update.each do |thread|
|
|
|
|
# NOTE: We may want to do something different with the old empty thread at some
|
|
|
|
# point when we add an explicit thread move UI, for now we can just delete it,
|
|
|
|
# since it will not contain any important data.
|
|
|
|
if thread.chat_messages.empty?
|
|
|
|
thread.destroy!
|
|
|
|
next
|
|
|
|
end
|
|
|
|
|
|
|
|
ChatThread.transaction do
|
|
|
|
original_message = thread.chat_messages.first
|
|
|
|
new_thread =
|
|
|
|
ChatThread.create!(
|
|
|
|
original_message: original_message,
|
|
|
|
original_message_user: original_message.user,
|
|
|
|
channel: @source_channel,
|
|
|
|
)
|
|
|
|
thread.chat_messages.update_all(thread_id: new_thread.id)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
end
|