discourse/plugins/chat/spec/integration/auto_channel_user_removal_s...

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

294 lines
9.5 KiB
Ruby
Raw Normal View History

FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
# frozen_string_literal: true
describe "Automatic user removal from channels" do
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
fab!(:user_1) { Fabricate(:user, trust_level: 1) }
fab!(:user_2) { Fabricate(:user, trust_level: 3) }
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
fab!(:user_1_guardian) { Guardian.new(user_1) }
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
fab!(:secret_group) { Fabricate(:group) }
fab!(:private_category) { Fabricate(:private_category, group: secret_group) }
fab!(:public_channel) { Fabricate(:chat_channel) }
fab!(:private_channel) { Fabricate(:chat_channel, chatable: private_category) }
fab!(:dm_channel) { Fabricate(:direct_message_channel, users: [user_1, user_2]) }
before do
SiteSetting.chat_enabled = true
Jobs.run_immediately!
secret_group.add(user_1)
public_channel.add(user_1)
private_channel.add(user_1)
public_channel.add(user_2)
CategoryGroup.create(category: public_channel.chatable, group_id: Group::AUTO_GROUPS[:everyone])
end
context "when the chat_allowed_groups site setting changes" do
it "removes the user who is no longer in chat_allowed_groups" do
expect { SiteSetting.chat_allowed_groups = Group::AUTO_GROUPS[:trust_level_3] }.to change {
Chat::UserChatChannelMembership.count
}.by(-3)
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: public_channel),
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).not_to include(
public_channel.id,
)
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).not_to include(
private_channel.id,
)
end
it "does not remove the user who is in one of the chat_allowed_groups" do
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
user_2.change_trust_level!(4)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect { SiteSetting.chat_allowed_groups = Group::AUTO_GROUPS[:trust_level_3] }.to change {
Chat::UserChatChannelMembership.count
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
}.by(-3)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(user: user_2, chat_channel: public_channel),
).to eq(true)
end
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
it "removes users from their DM channels" do
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect { SiteSetting.chat_allowed_groups = "" }.to change {
Chat::UserChatChannelMembership.count
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
}.by(-5)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: dm_channel)).to eq(
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
false,
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
)
expect(Chat::UserChatChannelMembership.exists?(user: user_2, chat_channel: dm_channel)).to eq(
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
false,
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
)
end
context "for staff users" do
fab!(:staff_user) { Fabricate(:admin) }
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
it "does not remove them from chat channels" do
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
public_channel.add(staff_user)
private_channel.add(staff_user)
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
expect(
Chat::UserChatChannelMembership.where(
user: staff_user,
chat_channel: [public_channel, private_channel],
).count,
).to eq(2)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
SiteSetting.chat_allowed_groups = ""
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.where(
user: staff_user,
chat_channel: [public_channel, private_channel],
).count,
).to eq(2)
end
it "does not remove them from DM channels" do
staff_dm_channel = Fabricate(:direct_message_channel, users: [user_1, staff_user])
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.where(
user: staff_user,
chat_channel: [staff_dm_channel],
).count,
).to eq(1)
end
end
end
context "when a user is removed from a group" do
context "when the user is no longer in any chat_allowed_groups" do
fab!(:group)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
before do
group.add(user_1)
SiteSetting.chat_allowed_groups = group.id
end
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
it "removes the user from all channels" do
expect(Chat::UserChatChannelMembership.where(user: user_1).count).to eq(3)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
group.remove(user_1)
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
expect(Chat::UserChatChannelMembership.where(user: user_1).count).to eq(0)
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
end
context "for staff users" do
fab!(:staff_user) { Fabricate(:admin) }
it "does not remove them from public channels" do
public_channel.add(staff_user)
private_channel.add(staff_user)
group.add(staff_user)
group.remove(staff_user)
expect(
Chat::UserChatChannelMembership.where(
user: staff_user,
chat_channel: [public_channel, private_channel],
).count,
).to eq(2)
end
end
end
context "when a user is removed from a private category group" do
context "when the user is in another group that can interact with the channel" do
fab!(:stealth_group) { Fabricate(:group) }
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
before do
CategoryGroup.create!(
category: private_category,
group: stealth_group,
permission_type: CategoryGroup.permission_types[:full],
)
stealth_group.add(user_1)
end
it "does not remove them from the corresponding channel" do
secret_group.remove(user_1)
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
).to eq(true)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).to include(
private_channel.id,
)
end
end
context "when the user is in no other groups that can interact with the channel" do
it "removes them from the corresponding channel" do
secret_group.remove(user_1)
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).not_to include(
private_channel.id,
)
end
end
end
end
context "when a category is updated" do
context "when the group's permission changes from reply+see to just see for the category" do
it "removes the user from the corresponding category channel" do
private_category.update!(permissions: { secret_group.id => :readonly })
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).not_to include(
private_channel.id,
)
end
context "for staff users" do
fab!(:staff_user) { Fabricate(:admin) }
it "does not remove them from the channel" do
secret_group.add(staff_user)
private_channel.add(staff_user)
private_category.update!(permissions: { secret_group.id => :readonly })
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(
user: staff_user,
chat_channel: private_channel,
),
).to eq(true)
end
end
end
context "when the secret_group is no longer allowed to access the private category" do
it "removes the user from the corresponding category channel" do
private_category.update!(permissions: { Group::AUTO_GROUPS[:staff] => :full })
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).not_to include(
private_channel.id,
)
end
context "for staff users" do
fab!(:staff_user) { Fabricate(:admin) }
it "does not remove them from the channel" do
secret_group.add(staff_user)
private_channel.add(staff_user)
private_category.update!(permissions: {})
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
expect(
Chat::UserChatChannelMembership.exists?(
user: staff_user,
chat_channel: private_channel,
),
).to eq(true)
end
end
end
end
context "when a group is destroyed" do
context "when it was the last group on the private category" do
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
it "remove users because the category defaults to staff having full access" do
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
secret_group.destroy!
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
PERF: auto join & leave chat channels (#29193) Chat channels that are linked to a category can be set to automatically join users. This is handled by subscribing to the following events - group_destroyed - user_seen - user_confirmed_email - user_added_to_group - user_removed_from_group - category_updated - site_setting_changed (for `chat_allowed_groups`) As well as a - hourly background job (`AutoJoinUsers`) - `CreateCategoryChannel` service - `UpdateChannel` service There was however two issues with the current implementation 1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system 2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync This PR "simply" adds two new servicesL `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join a leave a chat channel. Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened. In the making of these classes, a few bugs were encountered and fixed, notably - A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting - A category that has no associated "category groups" is only accessible to staff members (and not "Everyone") - A silenced user should not be able to automatically join channels - We should not attempt to automatically join users to deleted chat channels - There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users Internal - t/135259 & t/70607 * DEV: add specs for auto join/leave channels services * DEV: less hacky specs * DEV: no instance variables in specs
2024-11-11 23:00:59 -05:00
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).to_not include(
FEATURE: Auto-remove users without permission from channel (#20344) There are many situations that may cause users to lose permission to send messages in a chat channel. Until now we have relied on security checks in `Chat::ChatChannelFetcher` to remove channels which the user may have a `UserChatChannelMembership` record for but which they do not have access to. This commit takes a more proactive approach. Now any of these following `DiscourseEvent` triggers may cause `UserChatChannelMembership` records to be deleted: * `category_updated` - Permissions of the category changed (i.e. CategoryGroup records changed) * `user_removed_from_group` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` * `site_setting_changed` - The `chat_allowed_groups` was updated, some users may no longer be in groups that can access chat. * `group_destroyed` - Means the user may not be able to access the channel based on `GroupUser` or also `chat_allowed_groups` All of these are handled in a distinct service run in a background job. Users removed are logged via `StaffActionLog` and then we publish messages on a per-channel basis to users who had their memberships deleted. When the user has a channel they are kicked from open, we show a dialog saying "You no longer have access to this channel". When they click OK we redirect them either: * To their first other public channel, if they have any followed * The chat browse page if they don't This is to save on tons of requests from kicked out users getting messages from other channels. When the user does not have the kicked channel open, we can just silently yoink it out of their sidebar and turn off subscriptions.
2023-03-21 20:19:59 -04:00
private_channel.id,
)
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: public_channel),
).to eq(true)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).to include(
public_channel.id,
)
end
end
context "when there is another group on the private category" do
before do
CategoryGroup.create(group_id: Group::AUTO_GROUPS[:staff], category: private_category)
end
it "only removes users who are not in that group" do
secret_group.destroy!
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: private_channel),
).to eq(false)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).not_to include(
private_channel.id,
)
expect(
Chat::UserChatChannelMembership.exists?(user: user_1, chat_channel: public_channel),
).to eq(true)
expect(Chat::ChannelFetcher.all_secured_channel_ids(user_1_guardian)).to include(
public_channel.id,
)
end
end
end
end