2022-11-02 09:41:30 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
class Chat::ChatMessageCreator
|
|
|
|
attr_reader :error, :chat_message
|
|
|
|
|
|
|
|
def self.create(opts)
|
|
|
|
instance = new(**opts)
|
|
|
|
instance.create
|
|
|
|
instance
|
|
|
|
end
|
|
|
|
|
|
|
|
def initialize(
|
|
|
|
chat_channel:,
|
|
|
|
in_reply_to_id: nil,
|
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-07 19:22:07 -05:00
|
|
|
thread_id: nil,
|
2022-11-02 09:41:30 -04:00
|
|
|
user:,
|
|
|
|
content:,
|
|
|
|
staged_id: nil,
|
|
|
|
incoming_chat_webhook: nil,
|
|
|
|
upload_ids: nil
|
|
|
|
)
|
|
|
|
@chat_channel = chat_channel
|
|
|
|
@user = user
|
|
|
|
@guardian = Guardian.new(user)
|
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-07 19:22:07 -05:00
|
|
|
|
|
|
|
# NOTE: We confirm this exists and the user can access it in the ChatController,
|
|
|
|
# but in future the checks should be here
|
2022-11-02 09:41:30 -04:00
|
|
|
@in_reply_to_id = in_reply_to_id
|
|
|
|
@content = content
|
|
|
|
@staged_id = staged_id
|
|
|
|
@incoming_chat_webhook = incoming_chat_webhook
|
|
|
|
@upload_ids = upload_ids || []
|
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-07 19:22:07 -05:00
|
|
|
@thread_id = thread_id
|
2022-11-02 09:41:30 -04:00
|
|
|
@error = nil
|
|
|
|
|
|
|
|
@chat_message =
|
|
|
|
ChatMessage.new(
|
|
|
|
chat_channel: @chat_channel,
|
|
|
|
user_id: @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
|
|
|
last_editor_id: @user.id,
|
2022-11-02 09:41:30 -04:00
|
|
|
in_reply_to_id: @in_reply_to_id,
|
|
|
|
message: @content,
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
def create
|
|
|
|
begin
|
|
|
|
validate_channel_status!
|
|
|
|
uploads = get_uploads
|
|
|
|
validate_message!(has_uploads: uploads.any?)
|
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-07 19:22:07 -05:00
|
|
|
validate_reply_chain!
|
|
|
|
validate_existing_thread!
|
|
|
|
@chat_message.thread_id = @existing_thread&.id
|
2022-11-02 09:41:30 -04:00
|
|
|
@chat_message.cook
|
|
|
|
@chat_message.save!
|
|
|
|
create_chat_webhook_event
|
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-07 19:22:07 -05:00
|
|
|
create_thread
|
2022-11-02 09:41:30 -04:00
|
|
|
@chat_message.attach_uploads(uploads)
|
|
|
|
ChatDraft.where(user_id: @user.id, chat_channel_id: @chat_channel.id).destroy_all
|
|
|
|
ChatPublisher.publish_new!(@chat_channel, @chat_message, @staged_id)
|
|
|
|
Jobs.enqueue(:process_chat_message, { chat_message_id: @chat_message.id })
|
|
|
|
Chat::ChatNotifier.notify_new(
|
|
|
|
chat_message: @chat_message,
|
|
|
|
timestamp: @chat_message.created_at,
|
|
|
|
)
|
2022-12-06 13:33:39 -05:00
|
|
|
@chat_channel.touch(:last_message_sent_at)
|
2022-11-07 13:06:10 -05:00
|
|
|
DiscourseEvent.trigger(:chat_message_created, @chat_message, @chat_channel, @user)
|
2022-11-02 09:41:30 -04:00
|
|
|
rescue => error
|
|
|
|
@error = error
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def failed?
|
|
|
|
@error.present?
|
|
|
|
end
|
|
|
|
|
|
|
|
private
|
|
|
|
|
|
|
|
def validate_channel_status!
|
|
|
|
return if @guardian.can_create_channel_message?(@chat_channel)
|
|
|
|
|
|
|
|
if @chat_channel.direct_message_channel? && !@guardian.can_create_direct_message?
|
|
|
|
raise StandardError.new(I18n.t("chat.errors.user_cannot_send_direct_messages"))
|
|
|
|
else
|
|
|
|
raise StandardError.new(
|
2023-02-20 04:31:02 -05:00
|
|
|
I18n.t("chat.errors.channel_new_message_disallowed.#{@chat_channel.status}"),
|
2022-11-02 09:41:30 -04:00
|
|
|
)
|
|
|
|
end
|
|
|
|
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-07 19:22:07 -05:00
|
|
|
def validate_reply_chain!
|
|
|
|
return if @in_reply_to_id.blank?
|
|
|
|
|
|
|
|
@original_message_id = DB.query_single(<<~SQL).last
|
|
|
|
WITH RECURSIVE original_message_finder( id, in_reply_to_id )
|
|
|
|
AS (
|
|
|
|
-- start with the message id we want to find the parents of
|
|
|
|
SELECT id, in_reply_to_id
|
|
|
|
FROM chat_messages
|
|
|
|
WHERE id = #{@in_reply_to_id}
|
|
|
|
|
|
|
|
UNION ALL
|
|
|
|
|
|
|
|
-- get the chain of direct parents of the message
|
|
|
|
-- following in_reply_to_id
|
|
|
|
SELECT cm.id, cm.in_reply_to_id
|
|
|
|
FROM original_message_finder rm
|
|
|
|
JOIN chat_messages cm ON rm.in_reply_to_id = cm.id
|
|
|
|
)
|
|
|
|
SELECT id FROM original_message_finder
|
|
|
|
|
|
|
|
-- this makes it so only the root parent ID is returned, we can
|
|
|
|
-- exclude this to return all parents in the chain
|
|
|
|
WHERE in_reply_to_id IS NULL;
|
|
|
|
SQL
|
|
|
|
|
|
|
|
if @original_message_id.blank?
|
|
|
|
raise StandardError.new(I18n.t("chat.errors.original_message_not_found"))
|
|
|
|
end
|
|
|
|
|
|
|
|
@original_message = ChatMessage.with_deleted.find_by(id: @original_message_id)
|
|
|
|
if @original_message&.trashed?
|
|
|
|
raise StandardError.new(I18n.t("chat.errors.original_message_not_found"))
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def validate_existing_thread!
|
|
|
|
return if @thread_id.blank?
|
|
|
|
@existing_thread = ChatThread.find(@thread_id)
|
|
|
|
|
|
|
|
if @existing_thread.channel_id != @chat_channel.id
|
|
|
|
raise StandardError.new(I18n.t("chat.errors.thread_invalid_for_channel"))
|
|
|
|
end
|
|
|
|
|
|
|
|
reply_to_thread_mismatch =
|
|
|
|
@chat_message.in_reply_to&.thread_id &&
|
|
|
|
@chat_message.in_reply_to.thread_id != @existing_thread.id
|
|
|
|
original_message_has_no_thread = @original_message && @original_message.thread_id.blank?
|
|
|
|
original_message_thread_mismatch =
|
|
|
|
@original_message && @original_message.thread_id != @existing_thread.id
|
|
|
|
if reply_to_thread_mismatch || original_message_has_no_thread ||
|
|
|
|
original_message_thread_mismatch
|
|
|
|
raise StandardError.new(I18n.t("chat.errors.thread_does_not_match_parent"))
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-11-02 09:41:30 -04:00
|
|
|
def validate_message!(has_uploads:)
|
|
|
|
@chat_message.validate_message(has_uploads: has_uploads)
|
|
|
|
if @chat_message.errors.present?
|
|
|
|
raise StandardError.new(@chat_message.errors.map(&:full_message).join(", "))
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_chat_webhook_event
|
|
|
|
return if @incoming_chat_webhook.blank?
|
|
|
|
ChatWebhookEvent.create(
|
|
|
|
chat_message: @chat_message,
|
|
|
|
incoming_chat_webhook: @incoming_chat_webhook,
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
def get_uploads
|
|
|
|
return [] if @upload_ids.blank? || !SiteSetting.chat_allow_uploads
|
|
|
|
|
|
|
|
Upload.where(id: @upload_ids, user_id: @user.id)
|
|
|
|
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-07 19:22:07 -05:00
|
|
|
|
|
|
|
def create_thread
|
|
|
|
return if @in_reply_to_id.blank?
|
|
|
|
return if @chat_message.thread_id.present?
|
|
|
|
|
|
|
|
thread =
|
|
|
|
@original_message.thread ||
|
|
|
|
ChatThread.create!(
|
|
|
|
original_message: @chat_message.in_reply_to,
|
|
|
|
original_message_user: @chat_message.in_reply_to.user,
|
|
|
|
channel: @chat_message.chat_channel,
|
|
|
|
)
|
|
|
|
|
|
|
|
# NOTE: We intentionally do not try to correct thread IDs within the chain
|
|
|
|
# if they are incorrect, and only set the thread ID of messages where the
|
|
|
|
# thread ID is NULL. In future we may want some sync/background job to correct
|
|
|
|
# any inconsistencies.
|
|
|
|
DB.exec(<<~SQL)
|
|
|
|
WITH RECURSIVE thread_updater AS (
|
|
|
|
SELECT cm.id, cm.in_reply_to_id
|
|
|
|
FROM chat_messages cm
|
|
|
|
WHERE cm.in_reply_to_id IS NULL AND cm.id = #{@original_message_id}
|
|
|
|
|
|
|
|
UNION ALL
|
|
|
|
|
|
|
|
SELECT cm.id, cm.in_reply_to_id
|
|
|
|
FROM chat_messages cm
|
|
|
|
JOIN thread_updater ON cm.in_reply_to_id = thread_updater.id
|
|
|
|
)
|
|
|
|
UPDATE chat_messages
|
|
|
|
SET thread_id = #{thread.id}
|
|
|
|
FROM thread_updater
|
|
|
|
WHERE thread_id IS NULL AND chat_messages.id = thread_updater.id
|
|
|
|
SQL
|
2023-02-13 20:38:41 -05:00
|
|
|
|
|
|
|
@chat_message.thread_id = thread.id
|
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-07 19:22:07 -05:00
|
|
|
end
|
2022-11-02 09:41:30 -04:00
|
|
|
end
|