discourse/plugins/chat/spec/fabricators/chat_fabricator.rb

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

151 lines
4.2 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
Fabricator(:chat_channel, class_name: "Chat::Channel") do
name do
sequence(:name) do |n|
random_name = [
"Gaming Lounge",
"Music Lodge",
"Random",
"Politics",
"Sports Center",
"Kino Buffs",
].sample
"#{random_name} #{n}"
end
end
chatable { Fabricate(:category) }
type do |attrs|
DEV: start glimmer-ification and optimisations of chat plugin (#19531) Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around. To make it possible this commit is doing the following changes: - converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm - moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models. - dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app. - while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases. - removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved. Future wok: - improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved - improve page objects used in chat - move more endpoints to the API - finish temporarily skipped tests - extract more code from the `chat` service - use glimmer for `chat-messages` - separate concerns in `chat-live-pane` - eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 20:21:02 +08:00
if attrs[:chatable_type] == "Category" || attrs[:chatable]&.is_a?(Category)
"CategoryChannel"
else
"DirectMessageChannel"
end
end
status { :open }
end
Fabricator(:category_channel, from: :chat_channel) {}
Fabricator(:private_category_channel, from: :category_channel) do
DEV: start glimmer-ification and optimisations of chat plugin (#19531) Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around. To make it possible this commit is doing the following changes: - converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm - moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models. - dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app. - while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases. - removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved. Future wok: - improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved - improve page objects used in chat - move more endpoints to the API - finish temporarily skipped tests - extract more code from the `chat` service - use glimmer for `chat-messages` - separate concerns in `chat-live-pane` - eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 20:21:02 +08:00
transient :group
chatable { |attrs| Fabricate(:private_category, group: attrs[:group] || Group[:staff]) }
end
Fabricator(:direct_message_channel, from: :chat_channel) do
DEV: start glimmer-ification and optimisations of chat plugin (#19531) Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around. To make it possible this commit is doing the following changes: - converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm - moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models. - dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app. - while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases. - removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved. Future wok: - improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved - improve page objects used in chat - move more endpoints to the API - finish temporarily skipped tests - extract more code from the `chat` service - use glimmer for `chat-messages` - separate concerns in `chat-live-pane` - eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 20:21:02 +08:00
transient :users, following: true, with_membership: true
chatable do |attrs|
Fabricate(:direct_message, users: attrs[:users] || [Fabricate(:user), Fabricate(:user)])
end
status { :open }
DEV: start glimmer-ification and optimisations of chat plugin (#19531) Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around. To make it possible this commit is doing the following changes: - converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm - moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models. - dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app. - while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases. - removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved. Future wok: - improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved - improve page objects used in chat - move more endpoints to the API - finish temporarily skipped tests - extract more code from the `chat` service - use glimmer for `chat-messages` - separate concerns in `chat-live-pane` - eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 20:21:02 +08:00
name nil
after_create do |channel, attrs|
if attrs[:with_membership]
channel.chatable.users.each do |user|
membership = channel.add(user)
membership.update!(following: false) if attrs[:following] == false
end
end
end
end
Fabricator(:chat_message, class_name: "Chat::Message") do
chat_channel
user
message "Beep boop"
cooked { |attrs| Chat::Message.cook(attrs[:message]) }
cooked_version Chat::Message::BAKED_VERSION
DEV: start glimmer-ification and optimisations of chat plugin (#19531) Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around. To make it possible this commit is doing the following changes: - converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm - moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models. - dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app. - while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases. - removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved. Future wok: - improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved - improve page objects used in chat - move more endpoints to the API - finish temporarily skipped tests - extract more code from the `chat` service - use glimmer for `chat-messages` - separate concerns in `chat-live-pane` - eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 20:21:02 +08:00
in_reply_to nil
end
Fabricator(:chat_mention, class_name: "Chat::Mention") do
DEV: Chat service object initial implementation (#19814) This is a combined work of Martin Brennan, Loïc Guitaut, and Joffrey Jaffeux. --- This commit implements a base service object when working in chat. The documentation is available at https://discourse.github.io/discourse/chat/backend/Chat/Service.html Generating documentation has been made as part of this commit with a bigger goal in mind of generally making it easier to dive into the chat project. Working with services generally involves 3 parts: - The service object itself, which is a series of steps where few of them are specialized (model, transaction, policy) ```ruby class UpdateAge include Chat::Service::Base model :user, :fetch_user policy :can_see_user contract step :update_age class Contract attribute :age, :integer end def fetch_user(user_id:, **) User.find_by(id: user_id) end def can_see_user(guardian:, **) guardian.can_see_user(user) end def update_age(age:, **) user.update!(age: age) end end ``` - The `with_service` controller helper, handling success and failure of the service within a service and making easy to return proper response to it from the controller ```ruby def update with_service(UpdateAge) do on_success { render_serialized(result.user, BasicUserSerializer, root: "user") } end end ``` - Rspec matchers and steps inspector, improving the dev experience while creating specs for a service ```ruby RSpec.describe(UpdateAge) do subject(:result) do described_class.call(guardian: guardian, user_id: user.id, age: age) end fab!(:user) { Fabricate(:user) } fab!(:current_user) { Fabricate(:admin) } let(:guardian) { Guardian.new(current_user) } let(:age) { 1 } it { expect(user.reload.age).to eq(age) } end ``` Note in case of unexpected failure in your spec, the output will give all the relevant information: ``` 1) UpdateAge when no channel_id is given is expected to fail to find a model named 'user' Failure/Error: it { is_expected.to fail_to_find_a_model(:user) } Expected model 'foo' (key: 'result.model.user') was not found in the result object. [1/4] [model] 'user' ❌ [2/4] [policy] 'can_see_user' [3/4] [contract] 'default' [4/4] [step] 'update_age' /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/update_age.rb:32:in `fetch_user': missing keyword: :user_id (ArgumentError) from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:202:in `instance_exec' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:202:in `call' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:219:in `call' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `block in run!' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `each' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `run!' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:411:in `run' from <internal:kernel>:90:in `tap' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:302:in `call' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/spec/services/update_age_spec.rb:15:in `block (3 levels) in <main>' ```
2023-02-13 20:09:57 +08:00
transient read: false
transient high_priority: true
transient identifier: :direct_mentions
user { Fabricate(:user) }
DEV: Chat service object initial implementation (#19814) This is a combined work of Martin Brennan, Loïc Guitaut, and Joffrey Jaffeux. --- This commit implements a base service object when working in chat. The documentation is available at https://discourse.github.io/discourse/chat/backend/Chat/Service.html Generating documentation has been made as part of this commit with a bigger goal in mind of generally making it easier to dive into the chat project. Working with services generally involves 3 parts: - The service object itself, which is a series of steps where few of them are specialized (model, transaction, policy) ```ruby class UpdateAge include Chat::Service::Base model :user, :fetch_user policy :can_see_user contract step :update_age class Contract attribute :age, :integer end def fetch_user(user_id:, **) User.find_by(id: user_id) end def can_see_user(guardian:, **) guardian.can_see_user(user) end def update_age(age:, **) user.update!(age: age) end end ``` - The `with_service` controller helper, handling success and failure of the service within a service and making easy to return proper response to it from the controller ```ruby def update with_service(UpdateAge) do on_success { render_serialized(result.user, BasicUserSerializer, root: "user") } end end ``` - Rspec matchers and steps inspector, improving the dev experience while creating specs for a service ```ruby RSpec.describe(UpdateAge) do subject(:result) do described_class.call(guardian: guardian, user_id: user.id, age: age) end fab!(:user) { Fabricate(:user) } fab!(:current_user) { Fabricate(:admin) } let(:guardian) { Guardian.new(current_user) } let(:age) { 1 } it { expect(user.reload.age).to eq(age) } end ``` Note in case of unexpected failure in your spec, the output will give all the relevant information: ``` 1) UpdateAge when no channel_id is given is expected to fail to find a model named 'user' Failure/Error: it { is_expected.to fail_to_find_a_model(:user) } Expected model 'foo' (key: 'result.model.user') was not found in the result object. [1/4] [model] 'user' ❌ [2/4] [policy] 'can_see_user' [3/4] [contract] 'default' [4/4] [step] 'update_age' /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/update_age.rb:32:in `fetch_user': missing keyword: :user_id (ArgumentError) from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:202:in `instance_exec' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:202:in `call' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:219:in `call' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `block in run!' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `each' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `run!' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:411:in `run' from <internal:kernel>:90:in `tap' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:302:in `call' from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/spec/services/update_age_spec.rb:15:in `block (3 levels) in <main>' ```
2023-02-13 20:09:57 +08:00
chat_message { Fabricate(:chat_message) }
end
Fabricator(:chat_message_reaction, class_name: "Chat::MessageReaction") do
chat_message { Fabricate(:chat_message) }
user { Fabricate(:user) }
emoji { %w[+1 tada heart joffrey_facepalm].sample }
DEV: start glimmer-ification and optimisations of chat plugin (#19531) Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around. To make it possible this commit is doing the following changes: - converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm - moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models. - dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app. - while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases. - removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved. Future wok: - improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved - improve page objects used in chat - move more endpoints to the API - finish temporarily skipped tests - extract more code from the `chat` service - use glimmer for `chat-messages` - separate concerns in `chat-live-pane` - eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 20:21:02 +08:00
after_build do |chat_message_reaction|
chat_message_reaction.chat_message.chat_channel.add(chat_message_reaction.user)
end
end
Fabricator(:chat_message_revision, class_name: "Chat::MessageRevision") do
chat_message { Fabricate(:chat_message) }
old_message { "something old" }
new_message { "something new" }
user { |attrs| attrs[:chat_message].user }
end
Fabricator(:chat_reviewable_message, class_name: "Chat::ReviewableMessage") do
reviewable_by_moderator true
type "ReviewableChatMessage"
created_by { Fabricate(:user) }
target_type Chat::Message.sti_name
target { Fabricate(:chat_message) }
reviewable_scores { |p| [Fabricate.build(:reviewable_score, reviewable_id: p[:id])] }
end
Fabricator(:direct_message, class_name: "Chat::DirectMessage") do
users { [Fabricate(:user), Fabricate(:user)] }
end
Fabricator(:chat_webhook_event, class_name: "Chat::WebhookEvent") do
chat_message { Fabricate(:chat_message) }
incoming_chat_webhook do |attrs|
Fabricate(:incoming_chat_webhook, chat_channel: attrs[:chat_message].chat_channel)
end
end
Fabricator(:incoming_chat_webhook, class_name: "Chat::IncomingWebhook") do
name { sequence(:name) { |i| "#{i + 1}" } }
key { sequence(:key) { |i| "#{i + 1}" } }
chat_channel { Fabricate(:chat_channel, chatable: Fabricate(:category)) }
end
Fabricator(:user_chat_channel_membership, class_name: "Chat::UserChatChannelMembership") do
user
chat_channel
following true
end
Fabricator(:user_chat_channel_membership_for_dm, from: :user_chat_channel_membership) do
user
chat_channel
following true
desktop_notification_level 2
mobile_notification_level 2
end
Fabricator(:chat_draft, class_name: "Chat::Draft") do
user
chat_channel
transient :value, "chat draft message"
transient :uploads, []
transient :reply_to_msg
data do |attrs|
{ value: attrs[:value], replyToMsg: attrs[:reply_to_msg], uploads: attrs[:uploads] }.to_json
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-08 08:22:07 +08:00
Fabricator(:chat_thread, class_name: "Chat::Thread") do
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
before_create do |thread, transients|
thread.original_message_user = original_message.user
thread.channel = original_message.chat_channel
end
transient :channel
original_message do |attrs|
Fabricate(:chat_message, chat_channel: attrs[:channel] || Fabricate(:chat_channel))
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
end