3.0 KiB
Context
退款和代理充值已经接入企微审批，但部分历史记录在审批流程上线前创建，列表中的 approval_status 为空。这些记录需要由运营人员手动触发一次审批补发，才能进入企微审批链路。
Goals / Non-Goals
- Goals: 提供代理充值和退款的历史审批补发入口。
- Goals: 通过路径参数指定目标记录，并复用后端返回的完整记录与审批状态。
- Goals: 由明确的状态规则控制入口展示，后端做最终资格校验。
- Non-Goals: 不在前端实现审批提交、审批回调或审批引擎。
- Non-Goals: 不修改历史记录的业务字段、金额或支付/退款结果。
- Non-Goals: 不提供批量自动补发。
Decisions
-
Decision: 两个模块分别新增
triggerApproval(id)服务方法，返回完整业务记录并保留审批字段。 -
Rationale: 两个接口契约一致，成功后页面需要立即展示最新审批状态，完整记录可直接用于刷新。
-
Decision: 代理充值仅在
approval_status为空且status不属于已完成、已驳回、已关闭时显示补发入口；退款仅在status=待审批且approval_status为空时显示补发入口。 -
Rationale: 与业务规则一致，避免对已进入审批或已终结的记录重复补发；后端仍做最终资格校验。
-
Decision: 引入独立按钮权限
agent_recharge:trigger_approval和refund:trigger_approval。 -
Rationale: 补发审批是财务相关敏感操作，需与现有确认支付、拒绝、重新申请权限区分。
-
Decision: 补发审批与现有“确认支付/拒绝”和“重新申请”操作共存。
-
Rationale: 它们承担不同职责；补发审批只是把历史记录推进企微审批，不改变后续人工确认或重新申请的流程。
Risks / Trade-offs
-
Risk: 代理充值中
status=已支付、已退款等非终态记录是否允许补发，需要后端最终确认。 -
Mitigation: 前端按约定的审批状态与状态排除规则展示入口，后端对不允许的记录返回错误并稳定展示。
-
Risk: 接口可能对部分状态返回拒绝。
-
Mitigation: 前端处理后端错误信息，不将失败记录标记为已补发。
-
Risk: 重复点击可能触发多次审批提交。
-
Mitigation: 提交期间锁定按钮并禁用重复触发；后端应保证幂等或返回明确的已存在审批提示。
Migration Plan
- 确认两个
trigger-approval接口的响应字段与现有AgentRecharge、Refund类型一致。 - 新增服务方法和按钮权限。
- 在列表接入补发审批入口及资格判断。
- 联调补发成功、接口拒绝、权限缺失、审批状态为空与状态不符合条件等场景。
- 验证与现有确认支付、拒绝、重新申请操作不冲突。
Open Questions
- 后端对可补发记录的最终状态校验以及幂等性需确认。
- 两个接口是否都需要独立权限码，还是复用现有审批/财务权限，需与后端权限配置对齐。