feat: unify signature channel reporting status

This commit is contained in:
hectorzhao
2026-07-12 20:38:20 +08:00
parent 3f3ff8a793
commit eab059583f
16 changed files with 439 additions and 110 deletions
@@ -180,7 +180,7 @@
### 4.7 通道签名报备
1. 运营端先在“报备字段库”维护字段编码、名称、类型、是否必填等标准定义;通道报备详情只能从字段库选择字段,并指定用途为签名报备、引流信息报备或两者共用,不得在通道内另建同名孤立字段。
1. 运营端先在“报备字段库”维护字段编码、名称、类型、是否必填等标准定义;字段类型只允许字符串、图片、文件三种。通道报备详情只能从字段库选择字段,并指定用途为签名报备、引流信息报备或两者共用,不得在通道内另建同名孤立字段。
2. 通道组配置通道,企业应用通过路由规则选择通道组。企业签名和引流信息编辑时,系统必须沿“企业应用 -> 生效路由规则 -> 通道组 -> 组内通道 -> 通道报备字段”实时解析字段合集。
3. 同一字段被多个通道引用时按字段库记录去重;任一通道将该字段配置为必填,则企业资料中按必填处理,并保留该字段来源的全部通道用于后续分别报备。
4. 企业签名弹窗只展示签名报备/两者共用字段;每条引流信息只展示引流信息报备/两者共用字段。文件字段走真实对象存储上传,其他字段保存真实值,必填校验同时在前端和 NestJS API 执行。
@@ -190,6 +190,8 @@
8. 运营端在报备任务或通道报备详情页导入通道回执,系统根据回执同步签名在各通道的报备状态。
9. 报备记录保留每次导出、导入、状态变更和操作人。
10. 发送前必须校验最终选中通道上的签名报备任务为 approved;补发切换到新通道时必须重新按新通道校验报备状态,未通过则该次发送失败。
11. 企业签名页、通道报备详情页和报备任务页均允许人工修正报备状态,但三个入口必须操作同一份 `ChannelSignatureReportTask` 通道级事实并写 `ChannelSignatureReportRecord`;企业签名页修改时必须展示应用当前通道组内的具体通道矩阵,不允许直接修改移动/联通/电信汇总标签。
12. 每次人工状态变更或回执导入后,系统必须按应用当前生效路由规则重新汇总各运营商目标通道状态和签名全局 `reportStatus`。新增目标通道但尚无任务时按未报备计入分母;移出当前配置的历史通道不参与当前汇总,但任务和记录继续保留。
### 4.8 CMPP Gateway 与外部接入
+19 -1
View File
@@ -301,17 +301,35 @@
- 优先级:P0
- 前置条件:存在两个 active 通道、一个包含这两个通道的通道组,以及绑定该通道组的企业应用。
- 步骤:
1. 在报备字段库创建文件字段“营业执照”和文本字段“网站主体”。
1. 在报备字段库创建图片字段“营业执照”和字符串字段“网站主体”,并直接调用 API 尝试创建整数、网址、电话、日期等其他类型
2. 在通道一将营业执照配置为签名报备必填,在通道二将同一字段配置为两者共用非必填,并将网站主体配置为引流信息报备必填。
3. 打开该企业应用下的企业签名编辑弹窗和引流信息编辑弹窗。
4. 分别尝试缺少必填值保存,再补齐文件和值后保存。
5. 查询 PostgreSQL 中签名、签名报备材料和引流报备材料记录;删除该引流项后再次查询。
- 预期结果:
- 营业执照按字段库 ID 合并为一个字段,且因任一目标通道必填而整体必填;签名弹窗展示营业执照,引流弹窗展示网站主体及两者共用字段。
- 字段库页面只提供字符串、图片、文件三种类型;API 对其他类型返回 400,历史其他类型迁移为字符串。
- 缺少必填资料时前端禁止提交;直接调用 API 也返回 400,不能绕过页面保存不完整资料。
- 文件通过真实对象存储上传;动态值随签名 JSON 保存,并按来源通道分别写入规范化报备材料表。
- 删除引流项后,对应引流报备材料记录被同步删除,不保留可被后续导出误用的孤立资料。
### TC-ADMIN-005B 企业签名、通道详情和报备任务状态一致性
- 优先级:P0
- 前置条件:企业应用绑定移动、联通通道组,移动组含两个通道,联通组含一个通道;企业签名已存在。
- 步骤:
1. 在企业签名页打开“报备状态”,确认显示三个具体目标通道,将移动通道一标记通过。
2. 在移动通道二的通道报备详情中标记报备通过。
3. 在报备任务页将联通任务标记报备中,再通过回执导入改为通过。
4. 每步后分别刷新企业签名、通道详情和报备任务页面,并查询数据库任务、记录和签名状态。
5. 向移动通道组新增一个通道但不生成任务,再刷新企业签名列表。
- 预期结果:
- 三个入口操作同一条 `ChannelSignatureReportTask`;不存在的目标通道任务由统一接口真实创建。
- 每次变化写入 `ChannelSignatureReportRecord`,包含前后状态、原因、操作人和时间。
- 两个移动通道均通过后移动汇总为通过;联通处理中时签名全局状态不是通过;联通回执通过后三网目标通道全部通过,签名全局状态为 approved。
- 新增移动通道后移动汇总立即变为部分通过/报备中,分母包含新增通道,不能继续误显示全部通过。
- 发送时仍校验最终路由通道对应任务为 approved,不以企业签名列表汇总标签代替通道级校验。
### TC-ADMIN-006 报备回执导入通过
- 优先级:P0
+5
View File
@@ -1630,3 +1630,8 @@ git diff --check
- 已提交并 push `87ae4a20`,随后以该提交生成发布快照并部署生产;部署前备份 PostgreSQL 和运行源码,migration `20260712150000_link_report_field_library` 已成功应用。生产 `.deployed-commit=87ae4a20``cmpp-api``cmpp-gateway`、Nginx、MinIO 均为 active`12026/17890/8090/3000` 监听,API/Gateway health 和外部 HTTP 均通过。
- 生产数据库已确认 `ChannelReportField.drainageFieldId/reportType``DrainageReportMaterial` 存在。当前生产 `DrainageField=0``ChannelReportField=0`,因此不会凭空展示动态资料区;需要先按真实业务配置创建字段库和通道字段后再做页面来源弹窗的有数据验收。
- 浏览器可打开生产登录路由并识别页面标题“CMPP 短信平台”,但读取 DOM/控制台时浏览器连接连续超时,未将解释弹窗点击交互标记为已通过;待生产产生真实字段配置后补测。
- 2026-07-12 追加:报备字段库字段类型收窄为字符串、图片、文件三种;前端筛选和新增弹窗移除整数、网址、电话、日期,API 严格拒绝三种之外的类型。migration `20260712170000_normalize_report_field_types` 将历史其他类型及其通道字段副本统一归并为字符串。
- 2026-07-12 追加:按设计基线 `131f344a^` 恢复“通道列表 → 报备详情”页面结构,不再把报备详情错误简化为字段配置表。页面按当前通道查询真实 `ChannelSignatureReportTask/ChannelSignatureReportRecord/SmsSignature.drainageInfo`,展示签名任务、报备状态和时间,签名下引流信息默认收起并可展开;查看详情使用真实企业、应用和动态资料。发送统计没有数据库事实时明确显示“暂无统计”,不复用基线演示百分比。签名报备字段和引流信息字段配置保留为页面顶部两个入口,均从真实报备字段库选择。
- 本地验证:通道/字典定向测试 2 suites、31 项通过,API 全量 13 suites、134 项通过,API build、前端 build、`git diff --check` 通过。浏览器确认本地构建可加载且无框架错误覆盖,但本地未启动真实 API,认证验证码请求返回 502 并停留登录页,因此未把目标报备页面的登录后视觉交互标记为通过;没有绕过认证或注入 mock 数据。
- 2026-07-12 追加:报备状态改为通道任务唯一事实来源。新增统一批量状态变更 API,企业签名按应用当前通道组展示具体通道矩阵,通道详情修改当前任务,报备任务页人工修正任务;三个入口统一更新/创建 `ChannelSignatureReportTask`、写 `ChannelSignatureReportRecord`,并重算三网汇总和 `SmsSignature.reportStatus`。回执导入不再直接覆盖全局状态,同样调用汇总算法;新增但无任务的目标通道按未报备计入汇总分母。
- 已执行相关定向测试 2 suites、46 项及 API 全量测试 13 suites、135 项,API build、前端 build、`git diff --check` 均通过;前端仅有既有 Vite chunk size warning。