Rocket.Chat 怎么禁用用户并处理解禁后需重新邀请的行为【免费下载链接】Rocket.ChatThe Secure CommsOS™ for mission-critical operations项目地址: https://gitcode.com/GitHub_Trending/ro/Rocket.Chat在 Rocket.Chat 中当你需要把某个用户踢出某个频道或群组、同时又不想丢失其订阅记录时应该使用「封禁Ban」而不是「踢出Kick」。封禁会把该用户的订阅记录保留下来并标记为status: BANNED形成一道持久的访问屏障而踢出是直接删除订阅。本文覆盖完整的操作路径执行封禁、查看被封禁用户列表、执行解禁以及解禁之后为什么该用户必须被重新邀请或重新加入才能回到房间。封禁前确认权限与适用条件执行封禁的用户需要具备ban-user权限默认拥有该权限的角色是admin、owner、moderator权限按房间作用域校验。服务端还会做以下检查见 封禁校验逻辑该房间类型允许执行封禁操作roomDirectives.allowMemberAction执行者本人对该房间有访问权限目标用户存在且当前在房间中否则报User not found或User is not in this room目标用户已处于封禁状态时拒绝重复封禁User is already banned from this room目标是房间内最后一个 owner 时拒绝需先指定新的 ownerYou are the last owner. Please set new owner before banning the user.。确认以上条件后封禁可以通过三种入口触发UI、API、斜杠命令。执行封禁UI 路径进入房间后在用户信息面板中对目标用户执行封禁操作。该入口由ban-user权限、roomCanBan及 federation 规则共同控制。执行时会出现danger样式的确认弹窗GenericModal。API 路径调用POST /v1/rooms.banUser需要认证authRequired: true。请求体支持两种形式见 REST 类型定义{ userId: 用户ID, roomId: 房间ID }或{ username: 目标用户名, roomId: 房间ID }成功时返回{ success: true }端点实现见 rooms.ts。斜杠命令路径在房间中输入/ban username实现位于 ban.ts。封禁执行后核心逻辑见 封禁功能文档订阅被更新为status: BANNED记录本身不会被删除该房间从用户的__rooms数组中移除房间的usersCount递减频道和群组中的房间级角色moderator、owner、leader被移除如果该房间是团队主房间成员还会从团队中移除保存一条user-banned系统消息客户端收到订阅上的removed事件断开该房间的流。查看被封禁用户列表房间工具箱room toolbox中有Banned Users标签页需要ban-user权限才能看到列表支持虚拟滚动与无限分页。对应 API 为GET /v1/rooms.bannedUsers需要认证且调用者必须能访问该房间支持count与offset分页参数返回结构包含bannedUsers每项含_id、username、name、count、offset、total。执行解禁解禁同样有三种入口UI在 Banned Users 列表项的上下文菜单中执行解禁danger确认弹窗APIPOST /v1/rooms.unbanUser请求体格式与封禁一致userId或usernameroomId成功返回{ success: true }斜杠命令/unban username见 unban.ts。解禁的服务端行为解禁流程通过findOneBannedSubscription找到被封禁的订阅整条删除该订阅Subscriptions.removeById而不是把它恢复为活跃状态保存一条user-unbanned系统消息。解禁后用户必须重新入房这是最容易踩坑的一点解禁不会让用户重新成为房间成员。被封禁的订阅已经被删除用户此刻对该房间没有任何有效订阅处于“从未加入”的状态。因此解禁之后必须再走一次入房流程公开房间用户自行加入即可私有房间或团队由管理员通过 UI 的 “Add Users”、APIgroups.invite、channels.invite或邀请链接重新邀请。完整的预期流程是先解禁API、/unban username或 “Banned Users” 上下文栏删除被封禁的订阅然后再邀请或加入用户即可正常回到房间。反过来封禁期间该用户的任何入房路径都会被拦截邀请被拒addUsersToRoom在调用addUserToRoom之前先检查BANNED订阅命中则返回error-user-is-bannedUI 会弹出警告提示管理员先解禁。该检查位于方法层对普通房间和 federation 房间同样生效。邀请链接失效useInviteToken在保存邀请 token 或调用addUserToRoom之前就检查BANNED订阅命中则返回error-user-is-bannedtoken 不会被消费经由setUsername的注册入房路径也因此被阻断。直接加入被拒Room.join先调用canAccessRoom。公开房间与团队内的公开房间会显式检查findOneBannedSubscription并拒绝访问私有房间则因countByRoomIdAndUserId排除了BANNED订阅导致“已加入”校验为 false访问被拒绝。Federation 邀请事件Matrix 侧发送的邀请会被handleInvite提前返回不会产生新的INVITED订阅因此也走不到handleJoin。系统消息与参考系统消息触发时机user-banned用户被从房间封禁user-unbanned用户被解禁包括经重新添加触发的解禁REST 端点汇总MethodEndpoint说明POST/v1/rooms.banUser封禁用户接受userId或usernameroomIdPOST/v1/rooms.unbanUser解禁用户GET/v1/rooms.bannedUsers分页列出被封禁用户相关实现文件封禁校验、REST 端点、封禁/解禁斜杠命令、功能说明文档。【免费下载链接】Rocket.ChatThe Secure CommsOS™ for mission-critical operations项目地址: https://gitcode.com/GitHub_Trending/ro/Rocket.Chat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rocket.Chat 怎么禁用用户并处理解禁后需重新邀请的行为？
Rocket.Chat 怎么禁用用户并处理解禁后需重新邀请的行为【免费下载链接】Rocket.ChatThe Secure CommsOS™ for mission-critical operations项目地址: https://gitcode.com/GitHub_Trending/ro/Rocket.Chat在 Rocket.Chat 中当你需要把某个用户踢出某个频道或群组、同时又不想丢失其订阅记录时应该使用「封禁Ban」而不是「踢出Kick」。封禁会把该用户的订阅记录保留下来并标记为status: BANNED形成一道持久的访问屏障而踢出是直接删除订阅。本文覆盖完整的操作路径执行封禁、查看被封禁用户列表、执行解禁以及解禁之后为什么该用户必须被重新邀请或重新加入才能回到房间。封禁前确认权限与适用条件执行封禁的用户需要具备ban-user权限默认拥有该权限的角色是admin、owner、moderator权限按房间作用域校验。服务端还会做以下检查见 封禁校验逻辑该房间类型允许执行封禁操作roomDirectives.allowMemberAction执行者本人对该房间有访问权限目标用户存在且当前在房间中否则报User not found或User is not in this room目标用户已处于封禁状态时拒绝重复封禁User is already banned from this room目标是房间内最后一个 owner 时拒绝需先指定新的 ownerYou are the last owner. Please set new owner before banning the user.。确认以上条件后封禁可以通过三种入口触发UI、API、斜杠命令。执行封禁UI 路径进入房间后在用户信息面板中对目标用户执行封禁操作。该入口由ban-user权限、roomCanBan及 federation 规则共同控制。执行时会出现danger样式的确认弹窗GenericModal。API 路径调用POST /v1/rooms.banUser需要认证authRequired: true。请求体支持两种形式见 REST 类型定义{ userId: 用户ID, roomId: 房间ID }或{ username: 目标用户名, roomId: 房间ID }成功时返回{ success: true }端点实现见 rooms.ts。斜杠命令路径在房间中输入/ban username实现位于 ban.ts。封禁执行后核心逻辑见 封禁功能文档订阅被更新为status: BANNED记录本身不会被删除该房间从用户的__rooms数组中移除房间的usersCount递减频道和群组中的房间级角色moderator、owner、leader被移除如果该房间是团队主房间成员还会从团队中移除保存一条user-banned系统消息客户端收到订阅上的removed事件断开该房间的流。查看被封禁用户列表房间工具箱room toolbox中有Banned Users标签页需要ban-user权限才能看到列表支持虚拟滚动与无限分页。对应 API 为GET /v1/rooms.bannedUsers需要认证且调用者必须能访问该房间支持count与offset分页参数返回结构包含bannedUsers每项含_id、username、name、count、offset、total。执行解禁解禁同样有三种入口UI在 Banned Users 列表项的上下文菜单中执行解禁danger确认弹窗APIPOST /v1/rooms.unbanUser请求体格式与封禁一致userId或usernameroomId成功返回{ success: true }斜杠命令/unban username见 unban.ts。解禁的服务端行为解禁流程通过findOneBannedSubscription找到被封禁的订阅整条删除该订阅Subscriptions.removeById而不是把它恢复为活跃状态保存一条user-unbanned系统消息。解禁后用户必须重新入房这是最容易踩坑的一点解禁不会让用户重新成为房间成员。被封禁的订阅已经被删除用户此刻对该房间没有任何有效订阅处于“从未加入”的状态。因此解禁之后必须再走一次入房流程公开房间用户自行加入即可私有房间或团队由管理员通过 UI 的 “Add Users”、APIgroups.invite、channels.invite或邀请链接重新邀请。完整的预期流程是先解禁API、/unban username或 “Banned Users” 上下文栏删除被封禁的订阅然后再邀请或加入用户即可正常回到房间。反过来封禁期间该用户的任何入房路径都会被拦截邀请被拒addUsersToRoom在调用addUserToRoom之前先检查BANNED订阅命中则返回error-user-is-bannedUI 会弹出警告提示管理员先解禁。该检查位于方法层对普通房间和 federation 房间同样生效。邀请链接失效useInviteToken在保存邀请 token 或调用addUserToRoom之前就检查BANNED订阅命中则返回error-user-is-bannedtoken 不会被消费经由setUsername的注册入房路径也因此被阻断。直接加入被拒Room.join先调用canAccessRoom。公开房间与团队内的公开房间会显式检查findOneBannedSubscription并拒绝访问私有房间则因countByRoomIdAndUserId排除了BANNED订阅导致“已加入”校验为 false访问被拒绝。Federation 邀请事件Matrix 侧发送的邀请会被handleInvite提前返回不会产生新的INVITED订阅因此也走不到handleJoin。系统消息与参考系统消息触发时机user-banned用户被从房间封禁user-unbanned用户被解禁包括经重新添加触发的解禁REST 端点汇总MethodEndpoint说明POST/v1/rooms.banUser封禁用户接受userId或usernameroomIdPOST/v1/rooms.unbanUser解禁用户GET/v1/rooms.bannedUsers分页列出被封禁用户相关实现文件封禁校验、REST 端点、封禁/解禁斜杠命令、功能说明文档。【免费下载链接】Rocket.ChatThe Secure CommsOS™ for mission-critical operations项目地址: https://gitcode.com/GitHub_Trending/ro/Rocket.Chat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考