2022-11-02 21:41:30 +08:00
|
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
|
|
describe UserNotifications do
|
|
|
|
|
fab!(:chatters_group) { Fabricate(:group) }
|
2024-01-25 14:28:26 +08:00
|
|
|
|
fab!(:sender) { Fabricate(:user, group_ids: [chatters_group.id], refresh_auto_groups: true) }
|
|
|
|
|
fab!(:user) { Fabricate(:user, group_ids: [chatters_group.id], refresh_auto_groups: true) }
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
before do
|
|
|
|
|
SiteSetting.chat_enabled = true
|
|
|
|
|
SiteSetting.chat_allowed_groups = chatters_group.id
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
def refresh_auto_groups
|
|
|
|
|
user.reload
|
|
|
|
|
sender.reload
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
describe ".chat_summary" do
|
|
|
|
|
context "with private channel" do
|
|
|
|
|
fab!(:channel) do
|
|
|
|
|
refresh_auto_groups
|
2023-07-03 08:18:37 +08:00
|
|
|
|
create_dm_channel(sender, [sender, user])
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
|
|
|
|
|
2022-12-19 08:35:28 +08:00
|
|
|
|
it "calls guardian can_join_chat_channel?" do
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
Guardian.any_instance.expects(:can_join_chat_channel?).once
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
email.subject
|
|
|
|
|
end
|
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
describe "email subject" do
|
2023-11-23 22:54:22 +08:00
|
|
|
|
context "when private_email setting is enabled" do
|
|
|
|
|
before { SiteSetting.private_email = true }
|
|
|
|
|
|
|
|
|
|
it "has a generic subject" do
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.private_message",
|
|
|
|
|
email_prefix: SiteSetting.email_prefix.presence || SiteSetting.title,
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
it "includes the sender username in the subject" do
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.direct_message_from_1",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
username: sender.username,
|
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
|
|
|
|
expect(email.subject).to include(sender.username)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "only includes the name of the user who sent the message even if the DM has multiple participants" do
|
|
|
|
|
another_participant = Fabricate(:user, group_ids: [chatters_group.id])
|
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership_for_dm,
|
|
|
|
|
user: another_participant,
|
|
|
|
|
chat_channel: channel,
|
|
|
|
|
)
|
2023-03-17 21:24:38 +08:00
|
|
|
|
Chat::DirectMessageUser.create!(
|
|
|
|
|
direct_message: channel.chatable,
|
|
|
|
|
user: another_participant,
|
|
|
|
|
)
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.direct_message_from_1",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
username: sender.username,
|
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
|
|
|
|
expect(email.subject).to include(sender.username)
|
|
|
|
|
expect(email.subject).not_to include(another_participant.username)
|
|
|
|
|
end
|
|
|
|
|
|
2022-12-07 22:45:02 +08:00
|
|
|
|
it "includes both usernames when there are exactly two DMs with unread messages" do
|
2022-11-02 21:41:30 +08:00
|
|
|
|
another_dm_user = Fabricate(:user, group_ids: [chatters_group.id])
|
|
|
|
|
refresh_auto_groups
|
|
|
|
|
another_dm_user.reload
|
2023-07-03 08:18:37 +08:00
|
|
|
|
another_channel = create_dm_channel(user, [another_dm_user, user])
|
2022-11-02 21:41:30 +08:00
|
|
|
|
Fabricate(:chat_message, user: another_dm_user, chat_channel: another_channel)
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.direct_message_from_2",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
username1: another_dm_user.username,
|
|
|
|
|
username2: sender.username,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
expect(email.subject).to include(sender.username)
|
|
|
|
|
expect(email.subject).to include(another_dm_user.username)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "displays a count when there are more than two DMs with unread messages" do
|
2024-01-25 14:28:26 +08:00
|
|
|
|
user = Fabricate(:user, group_ids: [chatters_group.id], refresh_auto_groups: true)
|
2022-12-07 22:45:02 +08:00
|
|
|
|
senders = []
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
3.times do
|
2024-01-25 14:28:26 +08:00
|
|
|
|
sender = Fabricate(:user, group_ids: [chatters_group.id], refresh_auto_groups: true)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
refresh_auto_groups
|
|
|
|
|
sender.reload
|
2022-12-07 22:45:02 +08:00
|
|
|
|
senders << sender
|
2023-07-03 08:18:37 +08:00
|
|
|
|
channel = create_dm_channel(sender, [sender, user])
|
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
user
|
|
|
|
|
.user_chat_channel_memberships
|
|
|
|
|
.where(chat_channel_id: channel.id)
|
|
|
|
|
.update!(following: true)
|
|
|
|
|
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.direct_message_from_more",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
username: senders.first.username,
|
|
|
|
|
count: 2,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "returns an email if the user is not following the direct channel" do
|
|
|
|
|
user
|
|
|
|
|
.user_chat_channel_memberships
|
|
|
|
|
.where(chat_channel_id: channel.id)
|
|
|
|
|
.update!(following: false)
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
context "with public channel" do
|
|
|
|
|
fab!(:channel) { Fabricate(:category_channel) }
|
|
|
|
|
fab!(:chat_message) { Fabricate(:chat_message, user: sender, chat_channel: channel) }
|
2023-05-30 18:25:14 +08:00
|
|
|
|
# using fab! for user_membership below makes these specs flaky
|
|
|
|
|
let!(:user_membership) do
|
2022-11-02 21:41:30 +08:00
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership,
|
|
|
|
|
chat_channel: channel,
|
|
|
|
|
user: user,
|
|
|
|
|
last_read_message_id: chat_message.id - 2,
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
2023-08-24 21:22:51 +08:00
|
|
|
|
before do
|
|
|
|
|
channel.add(sender)
|
|
|
|
|
channel.update!(last_message: chat_message)
|
|
|
|
|
end
|
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
it "doesn't return an email if there are no unread mentions" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
context "with channel-wide mentions" do
|
|
|
|
|
before { Jobs.run_immediately! }
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
def create_chat_message_with_mentions_and_notifications(content)
|
|
|
|
|
# Sometimes it's not enough to just fabricate a message
|
|
|
|
|
# and we have to create it like here. In this case all the necessary
|
|
|
|
|
# db records for mentions and notifications will be created under the hood.
|
2023-09-07 14:57:29 +08:00
|
|
|
|
Chat::CreateMessage.call(
|
|
|
|
|
chat_channel_id: channel.id,
|
|
|
|
|
guardian: sender.guardian,
|
|
|
|
|
message: content,
|
|
|
|
|
)
|
2023-05-30 18:25:14 +08:00
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
it "returns email for @all mention by default" do
|
|
|
|
|
create_chat_message_with_mentions_and_notifications("Mentioning @all")
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
it "returns email for @here mention by default" do
|
|
|
|
|
user.update(last_seen_at: 1.second.ago)
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
create_chat_message_with_mentions_and_notifications("Mentioning @here")
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
context "when channel-wide mentions are disabled in a channel" do
|
|
|
|
|
before { channel.update!(allow_channel_wide_mentions: false) }
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
it "doesn't return email for @all mention" do
|
|
|
|
|
create_chat_message_with_mentions_and_notifications("Mentioning @all")
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
it "doesn't return email for @here mention" do
|
|
|
|
|
user.update(last_seen_at: 1.second.ago)
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
create_chat_message_with_mentions_and_notifications("Mentioning @here")
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
context "when user has disabled channel-wide mentions" do
|
|
|
|
|
before { user.user_option.update!(ignore_channel_wide_mention: true) }
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
it "doesn't return email for @all mention" do
|
|
|
|
|
create_chat_message_with_mentions_and_notifications("Mentioning @all")
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
it "doesn't return email for @here mention" do
|
|
|
|
|
user.update(last_seen_at: 1.second.ago)
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
create_chat_message_with_mentions_and_notifications("Mentioning @here")
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
2023-03-22 10:44:01 +08:00
|
|
|
|
|
2023-05-30 18:25:14 +08:00
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
2023-03-17 01:43:56 +08:00
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
describe "email subject" do
|
|
|
|
|
context "with regular mentions" do
|
2023-02-27 18:41:28 +08:00
|
|
|
|
before do
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: chat_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
|
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
2023-11-23 22:54:22 +08:00
|
|
|
|
context "when private_email setting is enabled" do
|
|
|
|
|
before { SiteSetting.private_email = true }
|
|
|
|
|
|
|
|
|
|
it "has a generic subject" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.private_message",
|
|
|
|
|
email_prefix: SiteSetting.email_prefix.presence || SiteSetting.title,
|
|
|
|
|
),
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
it "includes the sender username in the subject" do
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.chat_channel_1",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
channel: channel.title(user),
|
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
|
|
|
|
expect(email.subject).to include(channel.title(user))
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "includes both channel titles when there are exactly two with unread mentions" do
|
|
|
|
|
another_chat_channel = Fabricate(:category_channel, name: "Test channel")
|
|
|
|
|
another_chat_message =
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: another_chat_channel)
|
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership,
|
|
|
|
|
chat_channel: another_chat_channel,
|
|
|
|
|
user: sender,
|
|
|
|
|
)
|
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership,
|
|
|
|
|
chat_channel: another_chat_channel,
|
|
|
|
|
user: user,
|
|
|
|
|
last_read_message_id: another_chat_message.id - 2,
|
|
|
|
|
)
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: another_chat_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
2023-08-24 21:22:51 +08:00
|
|
|
|
another_chat_channel.update!(last_message: another_chat_message)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.chat_channel_2",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
channel1: channel.title(user),
|
|
|
|
|
channel2: another_chat_channel.title(user),
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
expect(email.subject).to include(channel.title(user))
|
|
|
|
|
expect(email.subject).to include(another_chat_channel.title(user))
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "displays a count when there are more than two channels with unread mentions" do
|
|
|
|
|
2.times do |n|
|
|
|
|
|
another_chat_channel = Fabricate(:category_channel, name: "Test channel #{n}")
|
|
|
|
|
another_chat_message =
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: another_chat_channel)
|
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership,
|
|
|
|
|
chat_channel: another_chat_channel,
|
|
|
|
|
user: sender,
|
|
|
|
|
)
|
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership,
|
|
|
|
|
chat_channel: another_chat_channel,
|
|
|
|
|
user: user,
|
|
|
|
|
last_read_message_id: another_chat_message.id - 2,
|
|
|
|
|
)
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: another_chat_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
2023-08-24 21:22:51 +08:00
|
|
|
|
another_chat_channel.update!(last_message: another_chat_message)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
2022-12-07 22:45:02 +08:00
|
|
|
|
|
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.chat_channel_more",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
channel: channel.title(user),
|
|
|
|
|
count: 2,
|
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
context "with both unread DM messages and mentions" do
|
|
|
|
|
before do
|
|
|
|
|
refresh_auto_groups
|
2023-07-03 08:18:37 +08:00
|
|
|
|
channel = create_dm_channel(sender, [sender, user])
|
2022-11-02 21:41:30 +08:00
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: chat_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "always includes the DM second" do
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expected_subject =
|
|
|
|
|
I18n.t(
|
|
|
|
|
"user_notifications.chat_summary.subject.chat_channel_and_direct_message",
|
|
|
|
|
email_prefix: SiteSetting.title,
|
|
|
|
|
channel: channel.title(user),
|
|
|
|
|
username: sender.username,
|
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
2022-12-07 22:45:02 +08:00
|
|
|
|
expect(email.subject).to eq(expected_subject)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
describe "When there are mentions" do
|
2023-02-27 18:41:28 +08:00
|
|
|
|
before do
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: chat_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
|
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
describe "selecting mentions" do
|
|
|
|
|
it "doesn't return an email if the user can't see chat" do
|
|
|
|
|
SiteSetting.chat_allowed_groups = ""
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email if the user can't see any of the included channels" do
|
|
|
|
|
channel.chatable.destroy!
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email if the user is not following the channel" do
|
|
|
|
|
user_membership.update!(following: false)
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email if the membership object doesn't exist" do
|
|
|
|
|
user_membership.destroy!
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email if the sender was deleted" do
|
|
|
|
|
sender.destroy!
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email when the user already saw the mention" do
|
|
|
|
|
user_membership.update!(last_read_message_id: chat_message.id)
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "returns an email when the user haven't read a message yet" do
|
|
|
|
|
user_membership.update!(last_read_message_id: nil)
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email when the unread count belongs to a different channel" do
|
|
|
|
|
user_membership.update!(last_read_message_id: chat_message.id)
|
|
|
|
|
second_channel = Fabricate(:chat_channel)
|
|
|
|
|
Fabricate(
|
|
|
|
|
:user_chat_channel_membership,
|
|
|
|
|
chat_channel: second_channel,
|
|
|
|
|
user: user,
|
|
|
|
|
last_read_message_id: chat_message.id - 1,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email if the message was deleted" do
|
|
|
|
|
chat_message.trash!
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "returns an email when the user has unread private messages" do
|
|
|
|
|
user_membership.update!(last_read_message_id: chat_message.id)
|
|
|
|
|
refresh_auto_groups
|
2023-07-03 08:18:37 +08:00
|
|
|
|
channel = create_dm_channel(sender, [sender, user])
|
2022-11-02 21:41:30 +08:00
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel)
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "returns an email if the user read all the messages included in the previous summary" do
|
|
|
|
|
user_membership.update!(
|
|
|
|
|
last_read_message_id: chat_message.id,
|
|
|
|
|
last_unread_mention_when_emailed_id: chat_message.id,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
new_message = Fabricate(:chat_message, user: sender, chat_channel: channel)
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: new_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't return an email if the mention is older than 1 week" do
|
|
|
|
|
chat_message.update!(created_at: 1.5.weeks.ago)
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to be_blank
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
describe "mail contents" do
|
2023-11-23 22:54:22 +08:00
|
|
|
|
context "when private_email setting is enabled" do
|
|
|
|
|
before { SiteSetting.private_email = true }
|
|
|
|
|
|
|
|
|
|
it "has a generic channel title name" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.html_part.body.to_s).to include(
|
|
|
|
|
I18n.t("system_messages.private_channel_title", id: channel.id),
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn’t include message content" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.html_part.body.to_s).to_not include(chat_message.cooked_for_excerpt)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn’t include user info" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.html_part.body.to_s).to_not include(chat_message.user.small_avatar_url)
|
|
|
|
|
expect(email.html_part.body.to_s).to_not include(chat_message.user.username)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2022-11-02 21:41:30 +08:00
|
|
|
|
it "returns an email when the user has unread mentions" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
expect(email.to).to contain_exactly(user.email)
|
|
|
|
|
expect(email.html_part.body.to_s).to include(chat_message.cooked_for_excerpt)
|
|
|
|
|
|
|
|
|
|
user_avatar =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row img")
|
|
|
|
|
|
|
|
|
|
expect(user_avatar.attribute("src").value).to eq(sender.small_avatar_url)
|
|
|
|
|
expect(user_avatar.attribute("alt").value).to eq(sender.username)
|
|
|
|
|
|
|
|
|
|
more_messages_channel_link =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".more-messages-link")
|
|
|
|
|
|
|
|
|
|
expect(more_messages_channel_link.attribute("href").value).to eq(chat_message.full_url)
|
|
|
|
|
expect(more_messages_channel_link.text).to include(
|
|
|
|
|
I18n.t("user_notifications.chat_summary.view_messages", count: 1),
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "displays the sender's name when the site is configured to prioritize it" do
|
|
|
|
|
SiteSetting.enable_names = true
|
|
|
|
|
SiteSetting.prioritize_username_in_ux = false
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
user_name = Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row span")
|
|
|
|
|
expect(user_name.text).to include(sender.name)
|
|
|
|
|
|
|
|
|
|
user_avatar =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row img")
|
|
|
|
|
|
|
|
|
|
expect(user_avatar.attribute("alt").value).to eq(sender.name)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "displays the sender's username when the site is configured to prioritize it" do
|
|
|
|
|
SiteSetting.enable_names = true
|
|
|
|
|
SiteSetting.prioritize_username_in_ux = true
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
user_name = Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row span")
|
|
|
|
|
expect(user_name.text).to include(sender.username)
|
|
|
|
|
|
|
|
|
|
user_avatar =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row img")
|
|
|
|
|
|
|
|
|
|
expect(user_avatar.attribute("alt").value).to eq(sender.username)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "displays the sender's username when names are disabled" do
|
|
|
|
|
SiteSetting.enable_names = false
|
|
|
|
|
SiteSetting.prioritize_username_in_ux = false
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
user_name = Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row span")
|
|
|
|
|
expect(user_name.text).to include(sender.username)
|
|
|
|
|
|
|
|
|
|
user_avatar =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row img")
|
|
|
|
|
|
|
|
|
|
expect(user_avatar.attribute("alt").value).to eq(sender.username)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "displays the sender's username when the site is configured to prioritize it" do
|
|
|
|
|
SiteSetting.enable_names = false
|
|
|
|
|
SiteSetting.prioritize_username_in_ux = true
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
|
|
|
|
|
user_name = Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row span")
|
|
|
|
|
expect(user_name.text).to include(sender.username)
|
|
|
|
|
|
|
|
|
|
user_avatar =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".message-row img")
|
|
|
|
|
|
|
|
|
|
expect(user_avatar.attribute("alt").value).to eq(sender.username)
|
|
|
|
|
end
|
|
|
|
|
|
2024-01-11 00:52:57 +08:00
|
|
|
|
context "with subfolder" do
|
|
|
|
|
before { set_subfolder "/community" }
|
|
|
|
|
|
|
|
|
|
it "includes correct view summary link in template" do
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
expect(email.html_part.body.to_s).to include(
|
|
|
|
|
"<a class=\"more-messages-link\" href=\"#{Discourse.base_url}/chat",
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
2023-11-23 22:54:22 +08:00
|
|
|
|
context "when there are more than two mentions" do
|
|
|
|
|
it "includes a view more link " do
|
|
|
|
|
2.times do
|
|
|
|
|
msg = Fabricate(:chat_message, user: sender, chat_channel: channel)
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: msg,
|
|
|
|
|
notifications: [notification],
|
|
|
|
|
)
|
2023-11-23 22:54:22 +08:00
|
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
2023-11-23 22:54:22 +08:00
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
more_messages_channel_link =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".more-messages-link")
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
2023-11-23 22:54:22 +08:00
|
|
|
|
expect(more_messages_channel_link.attribute("href").value).to eq(
|
|
|
|
|
chat_message.full_url,
|
|
|
|
|
)
|
|
|
|
|
expect(more_messages_channel_link.text).to include(
|
|
|
|
|
I18n.t("user_notifications.chat_summary.view_more", count: 1),
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
context "when private_email setting is enabled" do
|
|
|
|
|
before { SiteSetting.private_email = true }
|
|
|
|
|
|
|
|
|
|
it "has only a link to view all messages" do
|
|
|
|
|
2.times do
|
|
|
|
|
msg = Fabricate(:chat_message, user: sender, chat_channel: channel)
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-11-23 22:54:22 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-11-23 22:54:22 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: msg,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-11-23 22:54:22 +08:00
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
more_messages_channel_link =
|
|
|
|
|
Nokogiri::HTML5.fragment(email.html_part.body.to_s).css(".more-messages-link")
|
|
|
|
|
expect(more_messages_channel_link.text).to include(
|
|
|
|
|
I18n.t("user_notifications.chat_summary.view_messages", count: 3),
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
it "doesn't repeat mentions we already sent" do
|
|
|
|
|
user_membership.update!(
|
|
|
|
|
last_read_message_id: chat_message.id - 1,
|
|
|
|
|
last_unread_mention_when_emailed_id: chat_message.id,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
new_message =
|
|
|
|
|
Fabricate(:chat_message, user: sender, chat_channel: channel, cooked: "New message")
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
notification = Fabricate(:notification, user: user)
|
2023-02-27 18:41:28 +08:00
|
|
|
|
Fabricate(
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
|
:user_chat_mention,
|
2023-02-27 18:41:28 +08:00
|
|
|
|
user: user,
|
|
|
|
|
chat_message: new_message,
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
|
notifications: [notification],
|
2023-02-27 18:41:28 +08:00
|
|
|
|
)
|
2022-11-02 21:41:30 +08:00
|
|
|
|
|
|
|
|
|
email = described_class.chat_summary(user, {})
|
|
|
|
|
body = email.html_part.body.to_s
|
|
|
|
|
|
|
|
|
|
expect(body).not_to include(chat_message.cooked_for_excerpt)
|
|
|
|
|
expect(body).to include(new_message.cooked_for_excerpt)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
2023-07-03 08:18:37 +08:00
|
|
|
|
|
|
|
|
|
def create_dm_channel(sender, target_users)
|
|
|
|
|
result =
|
|
|
|
|
Chat::CreateDirectMessageChannel.call(
|
|
|
|
|
guardian: sender.guardian,
|
|
|
|
|
target_usernames: target_users.map(&:username),
|
|
|
|
|
)
|
|
|
|
|
service_failed!(result) if result.failure?
|
|
|
|
|
result.channel
|
|
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
|
end
|