feat: complete drainage review and admin search workflows

2026-07-14 09:58:18 +08:00
parent dec2430b7e
commit 6421671259
33 changed files with 1107 additions and 255 deletions
@@ -185,14 +185,15 @@
 2. 通道组配置通道，企业应用通过路由规则选择通道组。企业签名和引流信息编辑时，系统必须沿“企业应用 -> 生效路由规则 -> 通道组 -> 组内通道 -> 通道报备字段”实时解析字段合集。
 3. 同一字段被多个通道引用时按字段库记录去重；任一通道将该字段配置为必填，则企业资料中按必填处理，并保留该字段来源的全部通道用于后续分别报备。
 4. 企业签名弹窗只展示签名报备/两者共用字段；每条引流信息只展示引流信息报备/两者共用字段。文件字段走真实对象存储上传，其他字段保存真实值，必填校验同时在前端和 NestJS API 执行。
-5. 企业资料保存后，原始动态值随签名 JSON 保存，同时按实际目标通道分别写入签名报备材料和引流报备材料表，供通道报备任务导出使用；删除引流项时同步清理其规范化材料记录。
-6. 客户端上传签名资料，运营端审核企业签名资料。
-7. 运营端在通道资料更新后生成通道签名报备任务，并在报备任务中导出通道报备资料。
+5. 签名动态资料保留在签名记录；每条引流信息必须保存为独立 `SmsDrainageInfo` PostgreSQL 实体，包含所属企业、签名、应用、站点、地址、动态字段、审核状态和驳回原因，不得再以签名 JSON 数组作为引流审核事实来源。
+6. 客户端上传签名资料后进入签名审核；签名审核通过后方可新增引流信息。客户端新建或修改引流信息均自动进入 `pending`，运营端必须在独立“引流信息审核”页面查看资料后通过或带原因驳回。运营端在企业签名管理中新增或修改引流信息视为运营操作，自动审核通过并写审核记录。
+7. 引流信息审核通过前不得创建新的通道报备任务、写入可导出的引流报备材料或人工修改通道报备状态；已报备引流信息再次修改时，原通道任务冻结为 `waiting_review` 且旧材料停止使用。审核通过后系统按应用当前真实路由通道生成/重置 `reportType=drainage` 任务与材料，并写报备记录。
 8. 运营端在报备任务或通道报备详情页导入通道回执，系统根据回执同步签名在各通道的报备状态。
 9. 报备记录保留每次导出、导入、状态变更和操作人。
 10. 发送前必须校验最终选中通道上的签名报备任务为 approved；补发切换到新通道时必须重新按新通道校验报备状态，未通过则该次发送失败。
 11. 企业签名页、通道报备详情页和报备任务页均允许人工修正报备状态，但三个入口必须操作同一份 `ChannelSignatureReportTask` 通道级事实并写 `ChannelSignatureReportRecord`；企业签名页修改时必须展示应用当前通道组内的具体通道矩阵，不允许直接修改移动/联通/电信汇总标签。
 12. 每次人工状态变更或回执导入后，系统必须按应用当前生效路由规则重新汇总各运营商目标通道状态和签名全局 `reportStatus`。新增目标通道但尚无任务时按未报备计入分母；移出当前配置的历史通道不参与当前汇总，但任务和记录继续保留。
+13. 报备任务和报备记录页面必须可按签名/引流信息类型筛选，并显示引流信息的站名称、地址和所属签名。报备记录查询必须关联真实任务、通道和引流实体，完整展示审核通过后创建、重置、冻结、导出、回执和人工状态变化。

 ### 4.8 CMPP Gateway 与外部接入

@@ -460,11 +461,14 @@
 - 支持在报备任务中导出通道报备资料。
 - 支持在报备任务中导入回执。
 - 支持查看报备任务详情和处理历史。
+- 企业签名、报备任务、通道报备详情三个状态修改入口必须向统一状态接口传递入口标识，并持久化到报备记录，不能只靠前端文案推断。

 ### 5.16 运营端报备记录

 - 记录报备任务生成、导出、导入、状态同步、失败原因。
 - 支持按企业、签名、通道、状态、操作时间搜索。
+- 列表必须显示真实通道名称，不以通道 ID 代替；明确展示变更主体为签名或引流信息，并展示签名内容，或“所属签名 + 引流站点 + URL + 备注”。动作和前后状态统一显示中文。
+- 人工状态变化必须显示实际修改入口：企业签名修改、报备任务修改或通道信息修改；系统自动审核、冻结、导入等动作显示为系统自动处理，历史无入口字段的数据明确标注为历史记录。

 ### 5.17 安全控制

@@ -475,6 +479,9 @@
 - 引流信息字段库：用于签名/报备资料结构化采集。
 - 企业应用级黑名单、全局黑名单、敏感词管理必须提供搜索、添加、启停/删除功能；所有操作调用真实后端 API，写入系统日志。
 - 企业黑名单必须绑定到具体短信应用，支持按企业、应用、手机号、入库原因、状态搜索；发送预览、风控和发送链路只能拦截当前应用的 active 黑名单号码，不得把同企业其他应用的黑名单串用；全局黑名单支持按手机号、原因、状态搜索；敏感词支持按词、分类/级别、状态搜索。
+- 企业模板管理的企业名称、企业应用、模板名称、模板内容必须是互相独立且可组合的服务端查询条件；企业签名管理的企业名称、企业应用、签名名称/用途和引流信息同样独立查询。按引流信息搜索时，以签名为父级、命中的引流信息为子级分组展开。
+- 企业应用管理提供企业名称、企业应用名称和状态三个独立服务端查询条件。企业黑名单搜索区提供企业名称、企业应用、手机号码、入库原因和状态五个独立条件。
+- 运营端充值记录和短信记录表头统一左对齐。
 - “引流信息字段库”菜单命名为“报备字段库”，编辑、删除按钮使用通用操作按钮样式。

 ### 5.18 风控规则闭环
@@ -326,18 +326,38 @@
 - 优先级：P0
 - 前置条件：企业应用已绑定通道组，至少一个目标通道配置 `drainage` 或 `both` 报备字段。
 - 步骤：
-  1. 在企业签名中新增引流信息，填写动态字段并保存。
-  2. 查询 `DrainageReportMaterial` 和 `ChannelSignatureReportTask(reportType=drainage)`。
-  3. 分别从企业签名、通道报备详情、报备任务页修改同一引流项在同一通道的状态。
-  4. 查看报备记录，导出任务并导入回执。
+  1. 客户端在已审核通过的企业签名中新增引流信息，填写动态字段并提交。
+  2. 查询 `SmsDrainageInfo`、`DrainageReportMaterial` 和 `ChannelSignatureReportTask(reportType=drainage)`，并尝试直接调用状态变更接口。
+  3. 在运营端“引流信息审核”查看完整资料并通过，再次查询上述表和报备记录。
+  4. 分别从企业签名、通道报备详情、报备任务页修改同一引流项在同一通道的状态，并在报备记录页按引流信息筛选。
+  5. 客户端修改已通过的引流信息，确认任务冻结后由运营再次审核通过；随后导出任务并导入回执。
+  6. 对另一条待审引流信息执行带原因驳回，客户端查看驳回原因。
 - 预期结果：
-  - 每个“签名 + 引流项 + 通道”对应独立真实任务，初始为 pending。
-  - 三个入口的状态和通过数/总数一致，修改写入 `ChannelSignatureReportRecord`。
+  - 新建/修改均写独立 `SmsDrainageInfo` 和 `AuditRecord(targetType=sms_drainage_info)`；客户端提交为 pending，运营端列表和待审数量同步增加。
+  - 审核通过前没有新的可处理通道任务或可导出材料，直接修改通道报备状态返回 400；审核通过后每个“签名 + 引流项 + 通道”生成独立 pending 任务和 `audit_approved_create/reset` 记录。
+  - 已通过引流信息再次修改后，旧材料被停用、已有任务变为 waiting_review；再次审核通过后材料按新值重建且任务恢复 pending，历史记录保留。
+  - 三个入口的状态和通过数/总数一致，修改写入 `ChannelSignatureReportRecord.sourceEntry`；报备记录分别显示“企业签名修改”“通道信息修改”“报备任务修改”。
  - 引流任务不参与 `SmsSignature.reportStatus` 聚合，也不能被短信发送选路误当为签名报备通过。
  - 字段库页面只提供字符串、图片、文件三种类型；API 对其他类型返回 400，历史其他类型迁移为字符串。
  - 缺少必填资料时前端禁止提交；直接调用 API 也返回 400，不能绕过页面保存不完整资料。
-  - 文件通过真实对象存储上传；动态值随签名 JSON 保存，并按来源通道分别写入规范化报备材料表。
-  - 删除引流项后，对应引流报备材料记录被同步删除，不保留可被后续导出误用的孤立资料。
+  - 文件通过真实对象存储上传；动态值保存在 `SmsDrainageInfo.reportValues`，审核通过后按来源通道分别写入规范化报备材料表。
+  - 报备任务与报备记录页可区分签名/引流信息并显示真实通道名称、签名内容、站点、地址、备注和所属签名；动作、状态变化显示中文；删除引流项后任务进入 abandoned，不再可导出或改状态，历史记录仍可追溯。
+
+### TC-ADMIN-005C 运营列表独立组合搜索与表头对齐
+
+- 优先级：P1
+- 前置条件：存在不同企业、应用、签名、引流信息、模板、黑名单和启停状态的数据。
+- 步骤：
+  1. 在企业模板管理分别填写企业名称、企业应用、模板名称、模板内容，再组合查询。
+  2. 在企业签名管理分别填写企业名称、企业应用、签名名称/用途、引流信息；使用引流站点或 URL 查询。
+  3. 在企业应用管理组合企业名称、应用名称、状态查询。
+  4. 在企业黑名单组合企业名称、应用名称、手机号、入库原因、状态查询。
+  5. 查看充值记录和短信记录表头。
+- 预期结果：
+  - 每个查询条件作为独立 API 参数进入 NestJS，并由 Prisma 对应字段执行 AND 组合过滤，不拼成一个模糊关键字。
+  - 引流信息命中后只展示包含该命中项的签名分组，并自动展开匹配的引流信息。
+  - 重置恢复全部数据；列表仍来自真实 PostgreSQL。
+  - 充值记录和短信记录表头全部靠左对齐。

 ### TC-ADMIN-005B 企业签名、通道详情和报备任务状态一致性

@@ -1679,3 +1679,20 @@ git diff --check
 - 本地真实 PostgreSQL 已成功应用 3 条新 migration；API 全量 13 suites、139 项通过，Gateway 全量 Go 测试、Prisma validate、API build、前端 build 和 `git diff --check` 通过，前端仅有既有 chunk size warning。应用内浏览器确认本地运营端登录路由标题正确、DOM 非空、无框架错误覆盖且 console 无 error/warn；真实图形验证码阻止进入受保护页，未代解验证码、未绕过认证、未注入 mock。
 - 功能提交 `551b99cb` 已 push 并部署生产。部署前 PostgreSQL 备份为 `/opt/cmpp-platform/backups/cmpp-20260713-174148.sql`，运行源码备份为 `/opt/cmpp-platform/deploy-backups/full-19d47b45-20260713-174148`；三条 migration 成功应用。生产 `.deployed-commit=551b99cb`，四项服务 active，`12026/17890/8090/3000` 监听，API/Gateway health 和外部 HTTP 200；前端产物已包含“短信签名审核”“按通道修改引流信息报备状态”“签名与引流信息报备任务”。生产现有 4 条任务均已回填为 `reportType=signature`；`DrainageReportMaterial=0`，因此没有伪造引流任务，待真实引流字段资料保存时自动生成。
 - 部署后交付复核发现历史运营端新建的 draft 签名虽可在审核页筛选，但操作按钮只对 pending 开放。已改为 draft/pending 都可由运营直接通过或驳回，用于处理【安徽航天信息】等存量草稿；新增签名仍按新规则自动通过。修正提交 `ff3e5607` 已部署，二次备份时间戳 `20260713-174512`；生产 `.deployed-commit=ff3e5607`，四项服务、端口、API/Gateway health 和外部 HTTP 200 再次验证通过，部署后 API stderr 无新错误。
+
+## 2026-07-13 引流信息独立审核与报备任务门禁
+
+- 生产只读核查确认当前 `DrainageReportMaterial=0`、`reportType=drainage` 任务为 0、包含引流数组的签名为 0，因此本轮可安全引入规范化模型，不需要改写活跃引流业务数据。生产运行代码仍为 `ff3e5607`，本轮暂未部署。
+- 新增独立 PostgreSQL 实体 `SmsDrainageInfo`，客户端在已审核签名下新建或修改引流信息均进入 pending，并写 `AuditRecord(targetType=sms_drainage_info)`；运营端新增/修改自动通过。运营端审核中心新增“引流信息审核”页，支持真实 API 查询、详情、通过和带原因驳回，首页和侧栏待审数量同步纳入引流信息。
+- 通道报备增加审核门禁：审核通过前不创建新任务或可导出材料；已通过引流信息再次修改时删除旧材料并将已有任务冻结为 waiting_review。审核通过后按应用当前生效路由及通道引流字段重建材料，创建或重置 `ChannelSignatureReportTask(reportType=drainage)`，并写 `audit_approved_create/reset` 报备记录。
+- 企业端签名页面补充引流信息新建、修改、删除、动态字段和真实对象存储上传；运营端企业签名页改为调用独立引流 API，并显示引流审核状态。报备任务和报备记录页增加类型筛选，直接关联真实引流实体显示站点、地址和所属签名。
+- 本地真实 PostgreSQL 已成功应用 migration `20260713190000_add_drainage_audit_workflow`，Prisma validate/migrate status 通过。真实 NestJS API 验收使用现有已审核签名、应用路由和通道临时增加报备字段：客户端创建后为 pending 且任务数 0；运营审核通过后生成 1 条 drainage 任务和报备记录；客户端修改后任务冻结为 waiting_review；驳回原因可从 API 返回。验收数据、临时报备字段、材料、任务、审核及报备记录已在本地数据库清理，不污染业务样本。
+- API 全量测试 13 suites、141 项通过，API build、前端 build、`git diff --check` 通过；前端仅有既有 Vite chunk size warning。应用内浏览器确认本地构建标题、非空登录 DOM、无框架错误覆盖且 console 无 error/warn；访问 `/admin/drainage-audits` 按真实权限跳转登录页，因图形验证码未获授权代解，登录后的新增审核页点击和视觉验收未执行。该批改动纳入 2026-07-14 发布批次统一提交和部署。
+
+## 2026-07-14 运营列表组合搜索与报备记录可追溯性
+
+- 企业模板管理将企业名称、企业应用、模板名称、模板内容拆成独立查询参数；企业签名管理拆分企业名称、企业应用、签名名称/用途和引流信息。引流信息查询命中后按签名父级分组，并只展开显示命中的站点、URL 或备注。
+- 企业应用管理新增应用名称和状态条件；企业黑名单搜索区重做为企业名称、企业应用、手机号码、入库原因、状态五个独立条件。上述条件均由 NestJS 接收并通过 Prisma AND 组合查询真实 PostgreSQL，不再拼接为单个模糊关键字。
+- `ChannelSignatureReportRecord` 新增 `sourceEntry`，企业签名、报备任务、通道报备详情三个入口分别持久化 `enterprise_signature/report_task/channel_report`。报备记录列表展示真实通道名称、签名或引流信息主体、完整主体内容、中文动作和状态变化，并将入口翻译为“企业签名修改 / 报备任务修改 / 通道信息修改”。
+- 充值记录、短信记录表头统一左对齐；搜索区使用自适应网格，增加条件后不挤压操作按钮。
+- 本地真实 PostgreSQL 已应用 `20260714100000_add_report_record_source_entry`，并通过编译后的 NestJS 服务对现有应用、签名、模板执行真实组合查询。API 全量测试 13 suites、141 项通过；Prisma validate、API build、前端 build、Gateway 测试和 `git diff --check` 通过。应用内浏览器确认真实鉴权跳转、页面标题、非空 DOM、无框架错误覆盖及 console 无 error/warn；因图形验证码未获授权代解，登录后页面点击验收未执行。