This commit is contained in:
luo
@@ -0,0 +1,59 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 后台新登录密码统一校验
|
||||
|
||||
后台既有设置新登录密码的表单 SHALL 按用户最新确认使用专用统一校验：长度 8～12 位，仅允许 ASCII 英文字母和数字，必须同时包含大写字母、小写字母和数字。特殊符号、空白、中文、emoji 和其他非英文字母数字字符 MUST 拒绝；用户确认 MUST 优先于原对接说明的四类字符规则。
|
||||
|
||||
#### Scenario: 有效新密码
|
||||
|
||||
- **WHEN** 用户在后台本人改密、账号创建、店铺初始账号、企业创建或企业改密入口输入 `Abc12345`
|
||||
- **THEN** 新密码校验 MUST 通过
|
||||
- **AND** 新密码/确认密码输入限制及说明 MUST 为 8～12 位，仅英文字母和数字，且大写、小写和数字三类均必需
|
||||
- **AND** 需要确认密码的表单 MUST 验证其与新密码一致
|
||||
|
||||
#### Scenario: 无效新密码
|
||||
|
||||
- **WHEN** 用户输入 7 位、13 位、缺少大写/小写/数字任一类的密码，或包含特殊符号、空白、中文、emoji 等非法字符的密码
|
||||
- **THEN** 前端 MUST 阻止提交并展示具体规则提示
|
||||
- **AND** MUST NOT 静默 trim 密码后当作合法值提交
|
||||
|
||||
#### Scenario: 字符类别齐全但含特殊符号
|
||||
|
||||
- **WHEN** 用户输入 `Abc1234!`，长度符合且已包含大写、小写和数字
|
||||
- **THEN** 前端 MUST 因 `!` 是禁止的特殊符号拒绝该密码
|
||||
- **AND** MUST 提示只允许英文字母和数字，不能按原四类字符规则放行
|
||||
|
||||
#### Scenario: 修改账号未设置新密码
|
||||
|
||||
- **WHEN** 既有账号修改操作未提供可选 `password`
|
||||
- **THEN** 页面 MUST NOT 因缺少密码阻止其他字段修改
|
||||
- **AND** MUST NOT 提交空密码覆盖原值
|
||||
- **AND** 本批次 MUST NOT 仅为接口清单补建当前没有的账号密码编辑入口
|
||||
|
||||
### Requirement: 后台密码接口字段与旧密码兼容
|
||||
|
||||
后台密码服务 SHALL 保持各接口规定的请求字段；本人改密和账号独立改密的新密码使用 `new_password`，账号创建/可选修改及企业创建/改密使用 `password`，店铺初始密码使用 `init_password`。后端字段级错误 MUST 以既有 `msg` 或提供的 `message` 展示，不替换为笼统提示，不记录密码。
|
||||
|
||||
#### Scenario: 独立修改账号密码
|
||||
|
||||
- **WHEN** 既有服务调用 `PUT /api/admin/accounts/{id}/password`
|
||||
- **THEN** 请求体 MUST 按本批次说明使用 `new_password`，而不是当前旧封装的 `password`
|
||||
- **AND** 本批次 MUST NOT 将其他账号接口的 `password` 改名
|
||||
|
||||
#### Scenario: 使用旧密码登录和本人改密
|
||||
|
||||
- **WHEN** 用户使用仍被后端接受的旧密码登录或填写本人改密 `old_password`
|
||||
- **THEN** 前端 MUST NOT 对这些旧密码输入套用新的 8～12 位/三类/禁止特殊符号限制
|
||||
- **AND** 本人改密成功后的清理表单、清理登录态和返回登录页行为 MUST 保留
|
||||
|
||||
#### Scenario: 非登录密码与 C 端保持不变
|
||||
|
||||
- **WHEN** 实施本批次密码适配
|
||||
- **THEN** 操作密码、WiFi 密码和通用校验器其他调用行为 MUST 保持不变
|
||||
- **AND** 本仓库公开扫码注册页面和所有 `/api/c/v1` 服务 MUST 不修改
|
||||
|
||||
#### Scenario: 展示后端字段级原因
|
||||
|
||||
- **WHEN** 密码相关请求返回包含具体校验原因的 `msg` 或 `message`
|
||||
- **THEN** 页面 MUST 展示该原因且不重复弹错
|
||||
- **AND** 请求、日志和错误反馈 MUST NOT 输出输入的密码值
|
||||
@@ -0,0 +1,19 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 后台代理注册审批提交失败反馈
|
||||
|
||||
后台代理注册审核 SHALL 支持业务状态 `3`「审批提交失败」的筛选和失败标签，终态下隐藏恢复审批，并提示申请人从原扫码入口重新申请。后台 MUST NOT 为重新申请调用任何 `/api/c/v1` 接口。
|
||||
|
||||
#### Scenario: 审核失败申请
|
||||
|
||||
- **WHEN** 列表或详情收到 `status=3` 的注册申请
|
||||
- **THEN** 页面 MUST 展示「审批提交失败」，查询类型和筛选 MUST 支持值 3
|
||||
- **AND** MUST 隐藏恢复审批，即使陈旧响应 `recoverable=true`
|
||||
- **AND** MUST 提示「请申请人重新扫码申请」，保留详情只读功能
|
||||
- **AND** MUST NOT 新增后台代注册提交或修改公开注册页面
|
||||
|
||||
#### Scenario: 非终态未知结果仍可恢复
|
||||
|
||||
- **WHEN** 非失败终态申请的提交结果未知，后端允许恢复且用户有原恢复权限
|
||||
- **THEN** 页面 MUST 保留原恢复审批行为并在操作后刷新详情
|
||||
- **AND** MUST NOT 把提交状态数值直接当作注册业务状态
|
||||
@@ -0,0 +1,26 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 线下充值审批失败重新新建
|
||||
|
||||
后台线下充值 SHALL 识别业务状态 `7` 为「审批提交失败」终态，支持状态筛选和失败标签；有原创建资格的用户 SHALL 通过既有线下新建表单重新发起，使用 `POST /api/admin/agent-recharges` 新建单，而不是给原单恢复/补发审批。
|
||||
|
||||
#### Scenario: 失败单只读与终态操作
|
||||
|
||||
- **WHEN** 线下充值列表或详情展示 `status=7` 的单据
|
||||
- **THEN** 页面 MUST 展示「审批提交失败」，筛选 MUST 支持值 7
|
||||
- **AND** MUST 隐藏原单补发审批、恢复审批及仅适用于待处理单的确认/拒绝操作
|
||||
- **AND** 原权限允许的查看详情和查看凭证 MUST 保留
|
||||
|
||||
#### Scenario: 重新发起线下充值
|
||||
|
||||
- **WHEN** 具备现有线下创建资格的用户为失败单选择重新发起
|
||||
- **THEN** 页面 MUST 打开既有线下创建表单并沿用原字段校验
|
||||
- **AND** 提交 MUST 使用 `POST /api/admin/agent-recharges`，不得携带原单 ID 调用虚构重提接口
|
||||
- **AND** 新建成功后 MUST 刷新列表，不乐观将旧单状态改成成功
|
||||
|
||||
#### Scenario: 保留线上充值与原权限
|
||||
|
||||
- **WHEN** 实施终态适配
|
||||
- **THEN** 在线支付、可用方式、线下收款方式/流水号/OCR/凭证等原行为 MUST 保持不变
|
||||
- **AND** 前端 MUST NOT 为重新发起扩大原角色、店铺或创建权限
|
||||
- **AND** MUST NOT 修改 C 端接口或将未知结果自动视为失败
|
||||
@@ -0,0 +1,37 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 佣金提现审批提交失败状态
|
||||
|
||||
后台提现审核、店铺提现记录和相关详情 SHALL 支持业务状态 `5`「审批提交失败」，各原有提现状态筛选 MUST 包含值 5；具备既有店铺操作资格的用户 SHALL 通过原提现重提接口重新提交，不复用失败审批或本地模拟冻结金额。
|
||||
|
||||
#### Scenario: 失败提现展示与操作
|
||||
|
||||
- **WHEN** 提现列表或详情收到 `status=5`
|
||||
- **THEN** 页面 MUST 展示失败标签并支持筛选值 5
|
||||
- **AND** MUST NOT 为该终态展示待审核专有审批或恢复旧审批操作
|
||||
- **AND** 可操作的店铺提现入口 MUST 支持「重新提交」，调用 `PUT /api/admin/shops/{shop_id}/withdrawal-requests/{id}`
|
||||
- **AND** 既有金额、收款信息、附件校验及店铺权限范围 MUST 保留
|
||||
|
||||
#### Scenario: 刷新已释放的冻结金额
|
||||
|
||||
- **WHEN** 失败状态已由后端释放冻结金额，或用户成功重新提交提现
|
||||
- **THEN** 页面 MUST 刷新后端佣金概览和提现记录
|
||||
- **AND** MUST NOT 前端自行增减冻结金额或推断新的冻结结果
|
||||
|
||||
### Requirement: 提现资料审批失败提交新版本
|
||||
|
||||
后台提现资料 SHALL 识别业务状态 `4` 为「审批提交失败」，展示失败标签并支持以值 4 筛选。原权限允许的用户 SHALL 使用已有资料表单提交新版本，不对失败实例恢复审批。
|
||||
|
||||
#### Scenario: 失败资料展示和重提
|
||||
|
||||
- **WHEN** 店铺提现资料返回 `status=4`
|
||||
- **THEN** 页面 MUST 展示「审批提交失败」，资料状态筛选 MUST 支持值 4
|
||||
- **AND** 有原资料提交资格时 MUST 允许复用原表单，通过 `POST /api/admin/shops/{shop_id}/withdrawal-qualifications` 提交新版本
|
||||
- **AND** 成功后 MUST 刷新版本列表，保留旧版本历史，不乐观复用旧审批
|
||||
- **AND** 原店铺隔离、附件校验和作废权限 MUST 保持不变
|
||||
|
||||
#### Scenario: 状态数值不跨业务共用
|
||||
|
||||
- **WHEN** 页面同时处理提现状态 5、资料状态 4 和佣金明细状态
|
||||
- **THEN** 前端 MUST 使用各自业务映射
|
||||
- **AND** MUST NOT 将佣金明细的状态 5「回溯」改成审批提交失败
|
||||
@@ -0,0 +1,27 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 设备导入说明标注 IMEI 必填
|
||||
|
||||
后台设备导入说明 SHALL 将独立 IMEI 列标注为必填，不再列作可选；现有 Excel 模板列名、列数、列序和上传结构 MUST 不变，前端 MUST NOT 增加文档以外的 IMEI 格式、长度或重复限制。
|
||||
|
||||
#### Scenario: 查看导入说明和模板
|
||||
|
||||
- **WHEN** 用户打开设备导入弹窗
|
||||
- **THEN** 说明 MUST 明确 IMEI 必填，且不能因为首列允许 IMEI 作为设备标识就误认为独立 IMEI 列可省略
|
||||
- **AND** 原模板下载及列结构 MUST 保持不变
|
||||
- **AND** 其他已约定的设备标识、SN 和卡 ICCID 规则 MUST 保留
|
||||
|
||||
### Requirement: 保留设备导入行级失败反馈
|
||||
|
||||
设备导入任务详情 SHALL 继续按后端 `failed_items` 展示行号、设备标识和原因，IMEI 空值/空白导致的失败 MUST 不影响后端已成功导入的其他行。
|
||||
|
||||
#### Scenario: 混合成功与 IMEI 空值失败
|
||||
|
||||
- **WHEN** 任务详情返回某行原因「设备IMEI(imei)不能为空」和其他成功行
|
||||
- **THEN** 页面 MUST 展示该行号和原始失败原因，保留任务成功/失败计数
|
||||
- **AND** 前端 MUST NOT 因单行为空在提交前拒绝整个文件
|
||||
|
||||
#### Scenario: 全部失败
|
||||
|
||||
- **WHEN** 整个文件所有行失败，后端任务状态为失败
|
||||
- **THEN** 页面 MUST 展示后端失败状态及行级明细，不当作上传成功等于导入成功
|
||||
@@ -0,0 +1,34 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 核销审批提交失败终态与重提
|
||||
|
||||
核销申请 SHALL 识别业务状态 `4` 为「审批提交失败」终态，申请列表、详情及账单中的关联申请状态 MUST 一致。该状态不得恢复原审批，有原修改权限的用户 SHALL 通过既有修改表单重新提交申请。
|
||||
|
||||
#### Scenario: 显式失败申请
|
||||
|
||||
- **WHEN** 核销申请 `status=4`，或账单分摊记录 `application_status=4`
|
||||
- **THEN** 页面 MUST 以失败标签展示「审批提交失败」，申请筛选 MUST 包含值 4
|
||||
- **AND** MUST 隐藏恢复审批，即使陈旧数据仍返回 `recoverable=true`
|
||||
- **AND** 有原修改权限时 MUST 允许通过 `PUT /api/admin/employee-collection-applications/{id}` 重新提交
|
||||
- **AND** MUST 保留原表单、账单分摊与权限范围
|
||||
|
||||
#### Scenario: 金额释放与重提结果
|
||||
|
||||
- **WHEN** 核销申请失败后用户刷新账单，或通过既有接口重新提交申请
|
||||
- **THEN** 页面 MUST 从后端重新读取预占和可核销金额，不本地模拟释放金额
|
||||
- **AND** 成功重提后 MUST 刷新申请与关联账单
|
||||
|
||||
### Requirement: 核销真实审批提交状态
|
||||
|
||||
核销列表和详情 SHALL 根据真实 `approval_submission_status` 展示 `0 待提交 / 1 提交中 / 2 已提交 / 3 提交失败 / 4 结果未知`；后端名称为空时 MUST 按数值回退，不仅依赖名称字段。
|
||||
|
||||
#### Scenario: 无审批上下文
|
||||
|
||||
- **WHEN** 申请返回 `approval_submission_status=0`
|
||||
- **THEN** 列表和详情 MUST 展示「待提交」，不得因 0 为 falsy 而展示为缺失
|
||||
|
||||
#### Scenario: 提交结果未知
|
||||
|
||||
- **WHEN** 提交状态为 4，业务单并非失败终态，且后端返回 `recoverable=true`
|
||||
- **THEN** 有原恢复权限的用户 MUST 仍能看到恢复审批入口
|
||||
- **AND** 前端 MUST NOT 将结果未知自行当作审批提交失败或直接生成新审批
|
||||
@@ -0,0 +1,44 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 换货新资产手机号绑定冲突提示
|
||||
|
||||
后台创建换货和确认完成 SHALL 在错误码 `1202` 时读取错误业务响应的 `data.phone`，用一次文本弹窗提示解除关联的后台入口；处理 MUST 覆盖正常 HTTP 承载的业务失败和 HTTP 错误响应，不自动解绑、预查扫码记录或扩大权限。
|
||||
|
||||
#### Scenario: 1202 返回手机号
|
||||
|
||||
- **WHEN** `POST /api/admin/exchanges` 或 `POST /api/admin/exchanges/{id}/complete` 返回 `code=1202` 且含 `data.phone`
|
||||
- **THEN** 页面 MUST 提示「新资产已绑定手机号 {phone}，请先到『手机号资产关联』解除后再提交」
|
||||
- **AND** 默认错误提示与该弹窗 MUST NOT 重复展示
|
||||
- **AND** 手机号 MUST 只作为文本渲染，不写日志或持久化
|
||||
- **AND** 前端 MUST NOT 自动调用单条、批量或 CSV 解绑接口
|
||||
|
||||
#### Scenario: 号码缺失或无管理权限
|
||||
|
||||
- **WHEN** 1202 响应不含有效号码，或用户没有关联管理入口权限
|
||||
- **THEN** 页面 MUST 显示不含 `undefined` 的解除指引，无号码时不自行猜测
|
||||
- **AND** 无管理权限时 MUST 提示联系有权限人员，不暴露越权操作按钮
|
||||
|
||||
### Requirement: 换货冲突后保持数据并允许手动重试
|
||||
|
||||
1202 失败后后台 SHALL 保留当前创建表单或后端原完成状态，解除关联后允许用户手动再次提交。非 1202 错误 MUST 保留原统一反馈及业务判断。
|
||||
|
||||
#### Scenario: 创建失败保留表单
|
||||
|
||||
- **WHEN** 创建换货因 1202 被拒绝
|
||||
- **THEN** 当前新旧资产、原因、换货类型和其他表单值 MUST 保留
|
||||
- **AND** loading MUST 结束，取消提示 MUST NOT 被当作成功
|
||||
- **AND** 用户解除关联后 MUST 可手动再次提交原接口
|
||||
|
||||
#### Scenario: 确认完成被拒绝
|
||||
|
||||
- **WHEN** 确认完成接口因 1202 被拒绝
|
||||
- **THEN** 页面 MUST 刷新原换货单，并保持后端「已发货待确认」状态
|
||||
- **AND** MUST NOT 乐观标记换货完成或清空当前单据
|
||||
- **AND** 用户解除关联后 MUST 可手动重新确认
|
||||
|
||||
#### Scenario: 其他错误及原流程不变
|
||||
|
||||
- **WHEN** 换货接口返回非 1202 错误，包括退款拦截、权限失败、迁移失败或网络错误
|
||||
- **THEN** 页面 MUST 继续按原业务文案及统一错误分类反馈，不重复弹错
|
||||
- **AND** MUST NOT 新增依据扫码历史或退款状态的前置拒绝逻辑
|
||||
- **AND** 当前换货迁移字段、角色限制和接口成功行为 MUST 保持不变
|
||||
@@ -0,0 +1,36 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 后台订单在线支付摘要
|
||||
|
||||
后台订单公共类型 SHALL 接收 `third_party_trade_no`、`payment_channel`、`payment_merchant_name` 三个字符串字段；订单列表和详情 MUST 分别展示交易流水号、支付渠道和收款商户，不自行推断或补造后端未提供的值。
|
||||
|
||||
#### Scenario: 查看个人客户已支付在线订单
|
||||
|
||||
- **WHEN** 后台订单列表或详情收到个人客户微信/支付宝已支付订单的支付摘要
|
||||
- **THEN** 页面 MUST 展示后端返回的三个字段
|
||||
- **AND** `wechat`、`wechat_v2`、`fuiou` MUST 分别展示为微信直连 v3、微信直连 v2、富友
|
||||
- **AND** 未知非空渠道 MUST 保留原值，不错误映射成其他渠道
|
||||
- **AND** 已退款订单返回的原支付信息 MUST 继续展示
|
||||
|
||||
#### Scenario: 查看无在线支付摘要的订单
|
||||
|
||||
- **WHEN** 代理、钱包、线下或未支付订单的三个字段为空串
|
||||
- **THEN** 页面 MUST 统一展示 `-`，不得显示 `undefined` 或虚构渠道/商户
|
||||
- **AND** 列表和创建响应类型 MUST NOT 要求存在详情专有的 `payments`
|
||||
|
||||
### Requirement: 后台订单详情支付记录
|
||||
|
||||
后台订单详情 SHALL 使用独立于列表/创建响应的详情类型，接收并展示 `payments` 数组。支付单状态 MUST 使用独立映射 `0 待支付 / 1 已支付 / 2 已失败 / 3 已退款`，不得复用订单支付状态枚举。
|
||||
|
||||
#### Scenario: 展示多个支付尝试
|
||||
|
||||
- **WHEN** `GET /api/admin/orders/{id}` 返回多条支付记录
|
||||
- **THEN** 页面 MUST 按后端返回的创建时间倒序展示，不删除待支付或失败记录
|
||||
- **AND** MUST 展示支付单号、支付方式、渠道、商户、交易流水号、金额、状态、创建/支付/过期时间
|
||||
- **AND** 金额 MUST 从分转换为元，`paid_at`、`expire_at` 的 null 值 MUST 展示 `-`
|
||||
|
||||
#### Scenario: 无支付记录
|
||||
|
||||
- **WHEN** 订单详情返回 `payments=[]`
|
||||
- **THEN** 页面 MUST 显示支付记录空态，不报错或生成占位支付单
|
||||
- **AND** 页面 MUST NOT 为加载支付记录调用 C 端接口
|
||||
@@ -0,0 +1,41 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 预警规则不依赖已删除额度字段
|
||||
|
||||
后台预警规则 SHALL 按本批次响应字段展示规则，响应类型、列表、详情和列选项 MUST NOT 依赖 `real_data_mb`；套餐商品接口和套餐选项的同名额度字段 MUST 保留。
|
||||
|
||||
#### Scenario: 规则响应不含额度
|
||||
|
||||
- **WHEN** 后台加载规则列表或详情且后端不再返回 `real_data_mb`
|
||||
- **THEN** 页面 MUST 不展示规则的套餐流量额度列及详情字段
|
||||
- **AND** MUST 正常展示套餐、阈值百分比、启用状态、备注和更新时间
|
||||
- **AND** MUST NOT 因删除字段显示 `undefined` 或产生类型错误
|
||||
|
||||
#### Scenario: 套餐商品额度保留
|
||||
|
||||
- **WHEN** 规则表单从 `/api/admin/packages` 加载套餐候选
|
||||
- **THEN** 套餐类型及选项中 `real_data_mb` 的原用途 MUST 保留
|
||||
- **AND** 原规则创建/修改参数与阈值百分比校验 MUST 不变
|
||||
|
||||
### Requirement: 预警记录展示主套餐与加油包流量快照
|
||||
|
||||
后台预警列表和详情 SHALL 接收并展示后端 `threshold_mb`、`used_mb`、`limit_mb`，三者单位为 MB；阈值流量 MUST 使用触发时快照，不以当前套餐额度重新计算，已用和总量说明 MUST 标注包含加油包。
|
||||
|
||||
#### Scenario: 展示预警流量
|
||||
|
||||
- **WHEN** 预警列表或详情返回三项 MB 数值
|
||||
- **THEN** 页面 MUST 展示「阈值流量(MB)」「已用流量(MB，含加油包)」「总流量(MB，含加油包)」或同等明确标签
|
||||
- **AND** MUST 以两位小数展示，不混用规则百分比或 GB 数值
|
||||
- **AND** MUST NOT 使用当前套餐商品或前端计算覆盖 `threshold_mb`
|
||||
|
||||
#### Scenario: 零与缺失值
|
||||
|
||||
- **WHEN** 流量值为 0、null 或缺失
|
||||
- **THEN** 0 MUST 展示 `0.00`，null/缺失 MUST 展示 `-`
|
||||
- **AND** MUST NOT 把 0 显示为缺失或将缺失值当作 0
|
||||
|
||||
#### Scenario: 导出仍由后端生成
|
||||
|
||||
- **WHEN** 用户创建预警导出任务或下载历史文件
|
||||
- **THEN** 前端 MUST 复用原导出任务流程，不新增前端列模板或重写历史文件
|
||||
- **AND** 本批次验收 MUST 检查新任务最后一列阈值流量及历史任务原文件不变
|
||||
@@ -0,0 +1,36 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 退款审批提交失败状态与后台重提
|
||||
|
||||
退款后台 SHALL 识别业务状态 `7` 为「审批提交失败」终态，列表与详情 MUST 支持该状态展示和筛选。有原重提权限的用户 SHALL 使用原退款重提表单重新发起，不得恢复失败单的原审批。
|
||||
|
||||
#### Scenario: 显式提交失败
|
||||
|
||||
- **WHEN** 退款记录 `status=7`
|
||||
- **THEN** 列表和详情 MUST 展示失败标签，状态筛选 MUST 允许值 7
|
||||
- **AND** MUST 隐藏恢复及补发审批，不因陈旧 `approval_recoverable=true` 重新显示
|
||||
- **AND** 有重提权限时 MUST 通过 `POST /api/admin/refunds/{id}/resubmit` 重新发起
|
||||
- **AND** 成功后 MUST 刷新记录，不复用旧审批实例
|
||||
|
||||
#### Scenario: 不混淆原路退款失败
|
||||
|
||||
- **WHEN** 退款记录 `status=6`
|
||||
- **THEN** 页面 MUST 继续按原「原路退款失败」含义及 `anomaly_flag` 限制处理
|
||||
- **AND** MUST NOT 将该状态改成审批提交失败或放宽其原有异常限制
|
||||
|
||||
#### Scenario: 结果未知保留恢复资格
|
||||
|
||||
- **WHEN** 退款提交结果未知，业务状态不是 7，后端允许恢复且用户有原权限
|
||||
- **THEN** 页面 MUST 保留恢复审批入口
|
||||
- **AND** MUST NOT 直接把未知结果改成终态或创建重复申请
|
||||
|
||||
### Requirement: 退款企微结束后使用后台重新发起
|
||||
|
||||
后台退款页面 SHALL 对企微拒绝/撤销/删除后返回的 `status=3` 按「已拒绝」处理，允许符合原权限和规则的后台重提。页面 MUST NOT 引导用户在企微重新提交作为后台退款重提方式。
|
||||
|
||||
#### Scenario: 已拒绝退款重新发起
|
||||
|
||||
- **WHEN** 用户查看状态 3 的退款，且具备原重提权限
|
||||
- **THEN** 页面 MUST 保留后台重新发起入口并调用原 `resubmit` 接口
|
||||
- **AND** 若存在「在企微重新提交」文案，MUST 移除或改为后台重新发起指引
|
||||
- **AND** 换货资格 MUST 仍由换货接口判断，不新增退款状态前置拦截
|
||||
@@ -0,0 +1,19 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 业务员批量换绑使用平台登录手机号表头
|
||||
|
||||
后台业务员批量换绑页面 SHALL 将说明及已有前端内置模板（如有）统一为固定表头 `店铺编码,操作类型,平台登录账号,备注`，说明「平台登录账号」仅填写平台用户登录手机号。请求路径、结构、逐行结果和已有任务信息 MUST 保持不变。
|
||||
|
||||
#### Scenario: 换绑说明和清空规则
|
||||
|
||||
- **WHEN** 用户查看导入说明或下载已有前端模板
|
||||
- **THEN** 表头 MUST 使用「平台登录账号」，不得保留「业务员登录账号」
|
||||
- **AND** MUST 说明换绑时填写平台用户登录手机号而非用户名，清空时该列留空
|
||||
- **AND** MUST NOT 自动兼容/转换旧表头或把用户名转换为手机号
|
||||
|
||||
#### Scenario: 展示逐行失败
|
||||
|
||||
- **WHEN** 后端返回表头错误或行级格式不对、手机号不存在、非平台用户、账号禁用、多账号匹配等原因
|
||||
- **THEN** 页面 MUST 原样展示后端原因
|
||||
- **AND** 混合结果 MUST 保留成功行与失败行，不因部分失败改为前端整批拒绝
|
||||
- **AND** 接口 MUST 继续使用 `POST /api/admin/shops/business-owner-imports`
|
||||
Reference in New Issue
Block a user