我不太确定你的意图——你是想:

- 把“新成员可见历史”作为 PotatoChat 的第 410 号需求/问题来描述并提交?
- 说明这个功能应该怎么设计(行为规范、权限策略、UI 文案)?
- 或者要具体的实现方案(后端数据模型、API、前端交互、权限校验)?
下面我先给出一个简明的功能规格与实现建议(可直接拿去做 Issue 或开发评审),如果你需要具体代码或把它写成 Issue 模板我可以继续补充。
功能概述
- 名称:新成员可见历史
- 目的:控制群聊中新加入成员是否能查看加入之前的消息历史
- 场景:群管理员/群设置决定当有人被邀请/加入群组后,能看到该用户加入时间之前的聊天记录多少或是否全部可见
可选策略(设计选项)
- 完全可见:新成员可以查看群内的全部历史(默认所有历史可见)。
- 完全不可见:新成员只能看到加入后产生的消息(历史对新成员不可见)。
- 分段可见:允许管理员设定可见范围(如:最近 N 条消息 / 最近 X 天的历史)。
- 自定义权限:基于角色(管理员、受邀成员、通过群链接加入的访客)决定是否可见历史。
- 逐条级别权限:个别消息可设置“仅对加入前成员不可见”(复杂,一般不推荐首期实现)。
隐私与合规注意
- 若群涉及私密/敏感信息,默认“完全可见”可能带来隐私风险,建议默认对新成员不展示历史或需要管理员明确开启。
- 若有法规或存档需求(例如企业合规),要兼容消息审计/备份策略。
- 入群通知要明确提示“是否可查看历史”,让加入者知情同意。
数据模型与后端实现思路(简要)
- 在群组表(group)增加字段:history_visibility(枚举:ALL / NONE / TIME_WINDOW / COUNT)和 history_window_value(int,例如天数或消息数)。
- 每条消息(message)保留:group_id, created_at(已有)。判断可见性时比较新成员的 join_time 与 message.created_at,或依据 count 的最近 N 条。
- 入群记录(group_members)应存储 join_time,区分邀请/被踢/重新加入等状态,以便计算历史可见范围。
- API 层:当客户端请求拉取历史(GET /groups/{id}/messages?limit=…&before=…),后端需根据请求者的 join_time 与群的 history_visibility 策略过滤返回的消息。
- 如果做基于 count 的实现,后端需按时间倒序取最近 N 条后再按时间正序返回给新成员(但若 join 后已有更多消息,逻辑需仔细处理)。
前端/UX
- 群设置界面增加“新成员可见历史”选项,描述清楚含义(示例文案):
- “允许新成员查看加入前的全部消息(不推荐用于私密群)”
- “不允许新成员查看加入前的消息(推荐用于隐私群)”
- “仅允许查看最近 X 天/最近 N 条消息”
- 新成员入群时弹窗/提示:例如“本群设置为:新成员可见最近 7 天的历史。继续加入/查看”。
- 对于不可见的历史,界面可以显示占位提示:“更多历史对你不可见”。
API/权限样例(高层)
- GET /groups/{group_id}/messages
- 服务器根据 requester_id 的 group_members.join_time 与群的 history_visibility 返回可见消息集合。
- POST /groups/{group_id}/settings/history_visibility
- 仅群主/管理员可修改,需记录变更历史(谁在何时修改为何值)。
测试要点
- 新成员加入后拉取历史:验证按策略只返回应见消息。
- 老成员查看历史不受影响。
- 改变设置后,不同时间加入的成员权限差异(历史可见性基于入群时刻或基于当前设置?需要明确策略;建议设计为“按入群时间和当时的设置或按当前设置”二选一并写入规范)。
- 邀请被拒、踢出后再加入的边界情况处理。
- 性能:按 count 或按时间筛选大量消息时的分页/索引优化。
建议的默认策略(实用)
- 默认:不显示加入之前的历史(更安全),管理员可开启“允许历史可见”并选择范围。
- 入群提示强制告知历史可见策略。
如果你要提交为 Issue(编号 410),可以用如下简短描述(中文):
- 标题:410 – 新成员历史可见设置
- 描述:新增群设置项“新成员可见历史”,支持:全部/无/最近 N 天/最近 N 条,默认不显示。后端按 group_members.join_time 与 group.history_visibility 策略筛选消息,前端在群设置和入群提示中展示该选项与说明。包含权限校验与测试用例。
你想要我把上面的规格写成更详细的开发任务分解(含数据库迁移 SQL、API 参数样例、前端 mockup 文案或单元测试用例)吗?还是只需要一行简单的 Issue 描述?