feat: unify drainage targets and carrier status UI
This commit is contained in:
hectorzhao
@@ -214,7 +214,7 @@
|
||||
10. 发送前必须校验最终选中通道上的签名报备任务为 approved；补发切换到新通道时必须重新按新通道校验报备状态，未通过则该次发送失败。
|
||||
11. 企业签名页、通道报备详情页和报备任务页均允许人工修正报备状态，但三个入口必须操作同一份 `ChannelSignatureReportTask` 通道级事实并写 `ChannelSignatureReportRecord`；企业签名页修改时必须展示应用当前通道组内的具体通道矩阵，不允许直接修改移动/联通/电信汇总标签。
|
||||
12. 每次人工状态变更或回执导入后，系统必须按应用当前生效路由规则重新汇总各运营商目标通道状态和签名全局 `reportStatus`。新增目标通道但尚无任务时按未报备计入分母；移出当前配置的历史通道不参与当前汇总，但任务和记录继续保留。
|
||||
13. 报备任务和报备记录页面必须可按签名/引流信息类型筛选，并显示引流信息的站名称、地址和所属签名。报备记录查询必须关联真实任务、通道和引流实体，完整展示审核通过后创建、重置、冻结、导出、回执和人工状态变化。
|
||||
13. 报备任务和报备记录页面必须可按签名/引流信息类型筛选，并显示引流 URL 或号码及所属签名。报备记录查询必须关联真实任务、通道和引流实体，完整展示审核通过后创建、重置、冻结、导出、回执和人工状态变化。
|
||||
|
||||
### 4.8 CMPP Gateway 与外部接入
|
||||
|
||||
@@ -1509,7 +1509,7 @@
|
||||
### 2026-07-15 签名与引流资料批量导入、通道映射及统一报备
|
||||
|
||||
1. 运营端在“报备任务”下提供“待报备资料”工作台。WPS 在线表格须先由用户另存为 `.xlsx`，系统读取真实工作簿、工作表、表头、单元格和内嵌图片；原始文件及拆出的图片写入 MinIO，导入批次、映射和业务资料写入 PostgreSQL，不支持用 CSV、前端静态数组或浏览器本地存储冒充图片导入。
|
||||
2. 导入分为“解析预览”和“确认入库”两步。用户可指定企业、企业应用、资料类型、表头行数、数据起始行并复用映射方案；每个源列可映射到签名名称、用途、所属签名、站点名称、URL、备注或报备字段库中的动态字段，同时配置文本/图片/文件、必填和转换规则。源文件中的签名名称同样必须使用完整中文黑括号格式 `【签名】`，不得通过导入绕过页面/API签名校验；源文件字段名称和顺序不固定，映射方案必须可持久化复用。
|
||||
2. 导入分为“解析预览”和“确认入库”两步。用户可指定企业、企业应用、资料类型、表头行数、数据起始行并复用映射方案；每个源列可映射到签名名称、用途、所属签名、引流 URL 或号码、备注或报备字段库中的动态字段，同时配置文本/图片/文件、必填和转换规则。源文件中的签名名称同样必须使用完整中文黑括号格式 `【签名】`，不得通过导入绕过页面/API签名校验；源文件字段名称和顺序不固定，映射方案必须可持久化复用。
|
||||
3. 导入和业务页面的新建/修改只将已审核签名或引流信息标记为待报备，并递增材料版本；不得在每次导入后自动创建通道报备任务。运营人员可跨签名、跨引流信息勾选资料，一次创建统一报备批次。
|
||||
4. 创建批次时按每条资料所属企业应用的当前生效路由规则展开所有通道；一个签名走多个通道时，必须为每个通道创建或重置独立报备任务并生成一份该通道的 `.xlsx`。无生效路由、通道未配置字段或缺少通道必填资料时，该资料继续保留在待报备池，任务进入“资料待补充”，不得伪装为已完成。
|
||||
5. 通道“配置签名报备字段”和“配置引流信息字段”弹窗使用字段池，按资料类型分别配置。每列包含标准字段、通道导出表头、列顺序、必填、说明、列宽、文本转换、缺省值以及图片宽高；导出表头和列顺序必须严格使用通道配置，不受导入表格原始名称和顺序影响。
|
||||
@@ -2179,3 +2179,10 @@
|
||||
- 客户端签名与引流列表不展示使用场景、已提交资料或审核状态，只展示移动、联通、电信三网可用性；全部通过和部分通过均显示“报备通过”，数据来自当前应用路由和真实通道报备任务汇总。
|
||||
- 人工审核批量任务把`pending_review`独立显示为“待人工审核”，审核期间进度为0；客户端仅允许取消`scheduled`任务，并展示审核原因和驳回原因。运营审核页展示审核任务号与关联批量任务号。
|
||||
- 运营端签名质量的通道活跃度热力图支持通道名搜索；短信任务进度支持后端任务状态查询。
|
||||
|
||||
## 2026-08-28 签名与引流三网状态及引流字段统一
|
||||
|
||||
- 客户端“签名与引流信息”列表将移动、联通、电信的真实报备可用性集中展示为同一组三网状态单元；每个单元同时显示运营商名称、状态指示和“报备通过/暂不可用”，签名与关联引流信息使用一致布局。状态继续来自应用当前路由、通道运营商范围和真实报备任务汇总，不新增静态兜底或前端推测。
|
||||
- 引流信息的业务主字段统一为“引流 URL 或号码”，支持 `http/https` URL、手机号码和固定电话号码。客户端新增/修改弹窗不再显示或要求“名称”，原“访问地址”统一改名为“引流 URL 或号码”。
|
||||
- API 和服务端必须真实接受上述三种内容并拒绝无效任意文本。数据库既有 `SmsDrainageInfo.siteName` 仅作为兼容列保留，新建或修改时由后端同步写入规范化后的 URL/号码；客户端不得继续提交或依赖独立名称。
|
||||
- 运营端单条审核列表、审核详情、导入审核、报备任务和报备记录统一只展示 URL/号码，不再把兼容列作为独立名称。批量导入映射和官方模板去掉“站点名称”必填列，只要求所属短信签名及“引流 URL 或号码”。
|
||||
|
||||
@@ -4952,3 +4952,15 @@ npm run verify:phase8
|
||||
| TC-UI-REVIEW-008 | 创建命中人工审核规则的批量任务 | 两端显示“待人工审核”、进度为0；客户端无终止按钮，详情显示审核原因，运营审核页可见关联批量任务号 |
|
||||
| TC-UI-REVIEW-009 | 审核通过或驳回批量任务 | 状态按真实后端刷新；驳回时展示原因，不重复入队或发送 |
|
||||
| TC-UI-REVIEW-010 | 接口对接某个日志子接口失败 | 接口概览仍可用且提示中文，不直接显示`Internal server error` |
|
||||
|
||||
## TC-DRAINAGE-UI-20260828 三网状态与引流字段统一
|
||||
|
||||
| 用例ID | 场景 | 预期 |
|
||||
| --- | --- | --- |
|
||||
| TC-DRAINAGE-UI-001 | 客户端查看签名及展开后的引流信息列表 | 移动、联通、电信在同一组三网状态单元中清晰展示；每项含运营商名称和真实“报备通过/暂不可用”状态，签名与引流行布局一致 |
|
||||
| TC-DRAINAGE-UI-002 | 客户端打开新增或修改引流信息弹窗 | 仅有必填“引流 URL 或号码”，不存在“名称”和“访问地址”；提示明确支持 URL、手机号码和固定电话号码 |
|
||||
| TC-DRAINAGE-UI-003 | 分别提交 `https://example.com/path`、`13800138000`、`0755-12345678` | 三种输入均通过真实客户端 API 和服务端校验，写入 PostgreSQL；兼容 `siteName` 列与 `url` 列同步保存相同目标值，进入真实待审核流程 |
|
||||
| TC-DRAINAGE-UI-004 | 提交普通文字或空值 | 前端禁止空值提交；绕过前端提交普通文字时后端返回受控参数错误，不写数据库、不创建审核记录 |
|
||||
| TC-DRAINAGE-UI-005 | 运营端查看单条审核列表、详情、报备任务及报备记录 | 统一显示“引流 URL 或号码”及真实目标值，不再显示独立站点名称或旧“引流地址”标签；审核通过/驳回仍调用原真实 API |
|
||||
| TC-DRAINAGE-UI-006 | 下载引流官方导入模板并配置导入映射 | 模板和映射仅要求“所属短信签名”“引流 URL 或号码”，不再要求“站点名称”；导入项进入真实审核批次 |
|
||||
| TC-DRAINAGE-UI-007 | 桌面和窄屏查看三网状态组及引流列表 | 状态单元不相互覆盖，文字不截断为不可辨认内容；窄屏沿用受控列表滚动，不产生页面级横向溢出 |
|
||||
|
||||
Reference in New Issue
Block a user