群管理员加入申请改造 (2026-02-25)
数据结构
- 表:
group_admin_join_requests - 字段:
id、group_id、user_id、role、status、时间戳 role:user | artist(记录“申请当时”该用户在群内的group_user_pivot.role)status:pending | canceled | accepted
影响接口
POST /api/groups/request_admin_joinPOST /api/groups/cancel_request_admin_joinPOST /api/groups/listPOST /api/groups/new_groupsPOST /api/groups/infoPOST /api/groups/openPOST /api/admin_center/work_task/listPOST /api/admin_center/profile/job_countPOST /api/admin_center/group/join- Echo 事件:
GroupUpdated/GroupCreated/GroupMessageCreated
变更点
request_admin_join从布尔标记升级为申请记录数组(默认只返回pending)。- 支持多人申请,同一群可有多个申请人。
- 同一用户同一群仅允许 1 条
pending申请。 - 申请时会记录
role(user/artist)。 - 返回申请关联数据时,
user补充artist关联,便于前端按role决定展示user.name/cname或user.artist.name/cname。 - 用户执行申请/取消申请后,会更新该用户在
group_user_pivot中对应群的order_at_ts。 - 用户执行申请/取消申请后,会触发
GroupUpdated给该群所有成员(不仅是申请人),用于刷新聊天页 group list。 POST /api/groups/info现已复用与list/new_groups相同的组装逻辑(getGroupsByIds + transformGroups),返回结构保持一致。POST /api/groups/info查询不到可见群时返回data: null。- 群相关实时事件消息中的
group也会返回request_admin_join(pending 申请数组),与接口数据结构保持一致。 - 管理员执行
POST /api/admin_center/group/join后,该群pending申请统一改为accepted。
接口示例(详细)
1) 用户发起申请
POST /api/groups/request_admin_join
请求:
返回:
2) 用户取消申请(按申请 id)
POST /api/groups/cancel_request_admin_join
请求:
效果:
- 当前用户在该群的
order_at_ts会更新为当前时间戳(毫秒)。 - 该群所有成员都会收到
GroupUpdated事件,前端可直接刷新 group list 排序。
返回:
3) 群信息类接口返回(list/new_groups/info/open)
POST /api/groups/listPOST /api/groups/new_groupsPOST /api/groups/infoPOST /api/groups/open
返回中的群对象片段:
说明:
- 由于申请/取消会更新
order_at_ts并触发GroupUpdated,该群会在 list 中上浮到最前(同open group行为)。
3.1) info 返回结构对齐 list
POST /api/groups/info
请求(按 id 查询):
请求(按 work_task_id 查询):
返回(结构与 list/new_groups 中单个群对象一致):
无可见群(不存在 / 不在群里)时:
4) 管理端工单列表
POST /api/admin_center/work_task/list
请求(筛选有管理员申请的群):
返回片段:
5) 管理端计数
POST /api/admin_center/profile/job_count
返回片段:
说明:join_group 表示“存在至少 1 条 pending 申请的群数量”。
6) 管理员加入群后的状态变化
POST /api/admin_center/group/join
行为:
- 该群所有
pending申请改为accepted。 - 之后群对象
request_admin_join默认不再返回这些申请(因为只返回pending)。
7) 群相关 Echo 事件返回
适用事件:
GroupUpdatedGroupCreatedGroupMessageCreated(其group字段)
事件 group 片段示例:
兼容性说明
- 前端不应再把
request_admin_join当布尔值使用,应按数组处理。 - 前端可基于
request_admin_join[i].role决定展示名称来源:artist:优先展示request_admin_join[i].user.artist.name/cnameuser:展示request_admin_join[i].user.name/cname
补充更新:Admin 取消通知模板(2026-02-28)
影响接口
POST /api/admin_center/service_request/cancelPOST /api/admin_center/work_task/cancelPOST /api/admin_center/admin_cancel_notify_templates/list
变更点
- 管理员取消
service_request/work_task时,新增可选参数:cancel_notify_template_id。 cancel_notify_template_id必须是启用状态(is_active=true)的模板。- 新增模板列表接口:
POST /api/admin_center/admin_cancel_notify_templates/list。 - 列表接口不分页,且仅返回启用中的模板(按
sort asc, id asc)。 - 旧接口已移除:
POST /api/admin_center/cancel_notify_template/listPOST /api/admin_center/admin_cancel_notify_templates/update
通知渲染规则
- 取消通知仍由
notification_templates统一管理。 admin_canceled场景模板渲染变量:title使用{{ $cancel_reason_title }}content使用{{ $cancel_reason }}
- 业务层会向通知
meta注入:cancel_notify_template_idcancel_reason_title(多语言)cancel_reason(多语言)
- 未选择模板时,
cancel_reason_title/cancel_reason会注入空多语言值(zh/en/ja为空字符串),保证模板可稳定渲染。
请求示例
POST /api/admin_center/service_request/cancel
POST /api/admin_center/work_task/cancel
POST /api/admin_center/admin_cancel_notify_templates/list
返回片段示例:

