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.

264 lines
7.6 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|
if attrs[:chatable_type] == "Category" || attrs[:chatable].is_a?(Category)
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
"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
transient :users, :group, following: true, with_membership: true
chatable do |attrs|
Fabricate(
:direct_message,
users: attrs[:users] || [Fabricate(:user), Fabricate(:user)],
group: attrs[:group] || false,
)
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
threading_enabled true
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_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
transient use_service: false
initialize_with do |transients|
Fabricate(
transients[:use_service] ? :chat_message_with_service : :chat_message_without_service,
**to_params,
)
end
end
Fabricator(:chat_message_without_service, class_name: "Chat::Message") do
user
chat_channel
message { Faker::Alphanumeric.alpha(number: SiteSetting.chat_minimum_message_length) }
after_build { |message, attrs| message.cook }
after_create { |message, attrs| message.upsert_mentions }
end
Fabricator(:chat_message_with_service, class_name: "Chat::CreateMessage") do
transient :chat_channel,
:user,
:message,
:in_reply_to,
:thread,
:upload_ids,
:incoming_chat_webhook
initialize_with do |transients|
channel =
transients[:chat_channel] || transients[:thread]&.channel ||
transients[:in_reply_to]&.chat_channel || Fabricate(:chat_channel)
user = transients[:user] || Fabricate(:user)
Group.refresh_automatic_groups!
channel.add(user)
result =
resolved_class.call(
chat_channel_id: channel.id,
guardian: user.guardian,
message:
transients[:message] ||
Faker::Alphanumeric.alpha(number: SiteSetting.chat_minimum_message_length),
thread_id: transients[:thread]&.id,
in_reply_to_id: transients[:in_reply_to]&.id,
upload_ids: transients[:upload_ids],
incoming_chat_webhook: transients[:incoming_chat_webhook],
process_inline: true,
)
if result.failure?
raise RSpec::Expectations::ExpectationNotMetError.new(
"Service `#{resolved_class}` failed, see below for step details:\n\n" +
result.inspect_steps.inspect,
)
end
result.message_instance
end
end
PERF: fix performance of chat email notifications When chat is enabled, there's a scheduled job that runs every 5 minutes to check whether we need to send a "chat summary" email to users with unread chat messages or mentions. On Discourse with a large number of users, the query used wasn't optimal and sometimes taking minutes. Which isn't good when the query is called every 5 minutes 😬 This PR reworks the query in `Chat::Mailer.send_unread_mentions_summary`. Instead of starting from the `users` table, it starts from the `user_chat_channel_memberships` table which is the main piece tying everything together. The new query is mostly similar to the previous one, with some bug fixes (like ensuring the user has `allow_private_messages` enabled for direct messages) and is also slightly simpler since it doesn't keep track of the `memberships_with_unread_messages` anymore. That part has been moved to the `user_notifications.chat_summary` email method. The `UserEmailExtension` has been deleted since that was using to N+1 update the `user_chat_channel_memberships.last_unread_mention_when_emailed_it`(quite a mouthful 😛) but that's now done directly in the `user_notifications.chat_summary` email method. The "plat de résistance" of that PR - the `user_notifications.chat_summary` method has been re-worked for improved performances 🚀 Instead of doing everything in one query, it does 4 tiny ones. - One to retrieve the list of unread mentions (@something) in "category" channels - One to retrieve the list of unread messages in "direct message" channels (aka. 1-1 and group discussions) - One to load all the chat messages for each "category" channels from the last unread mention - One to load all the chat messages for each "direct message" channels from the last unread message All the specs for both `Chat::Mailer` and `UserNotification.chat_summary` have been rewriten for easier comprehension and faster execution (mostly by not using chat services which makes the specs go 10x slower...) Internal ref - t/129848
2024-06-08 06:20:37 +08:00
Fabricator(:chat_mention_notification, class_name: "Chat::MentionNotification") do
chat_mention { Fabricate(:user_chat_mention) }
notification { Fabricate(:notification) }
end
Fabricator(:user_chat_mention, class_name: "Chat::UserMention") 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(:group_chat_mention, class_name: "Chat::GroupMention") do
chat_message { Fabricate(:chat_message) }
group { Fabricate(:group) }
end
Fabricator(:all_chat_mention, class_name: "Chat::AllMention") do
chat_message { Fabricate(:chat_message) }
end
Fabricator(:here_chat_mention, class_name: "Chat::HereMention") do
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 { 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| "Test webhook #{i + 1}" } }
emoji { %w[:joy: :rocket: :handshake:].sample }
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
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 :with_replies, :channel, :original_message_user, :old_om, use_service: false
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
original_message do |attrs|
Fabricate(
:chat_message,
chat_channel: attrs[:channel] || Fabricate(:chat_channel, threading_enabled: true),
user: attrs[:original_message_user] || Fabricate(:user),
use_service: attrs[:use_service],
)
end
after_create do |thread, transients|
attrs = { thread_id: thread.id }
# Sometimes we make this older via created_at so any messages fabricated for this thread
# afterwards are not created earlier in time than the OM.
attrs[:created_at] = 1.week.ago if transients[:old_om]
thread.original_message.update!(**attrs)
thread.add(thread.original_message_user)
if transients[:with_replies]
Fabricate
.times(
transients[:with_replies],
:chat_message,
thread: thread,
use_service: transients[:use_service],
)
.each { |message| thread.add(message.user) }
thread.update!(replies_count: transients[:with_replies])
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
end
Fabricator(:user_chat_thread_membership, class_name: "Chat::UserChatThreadMembership") do
user
after_create do |membership|
Chat::UserChatChannelMembership.find_or_create_by!(
user: membership.user,
chat_channel: membership.thread.channel,
).update!(following: true)
end
end