|
|
@@ -1,7 +1,7 @@
|
|
|
# Story 004.001: 创建多租户信用额度模块
|
|
|
|
|
|
## Status
|
|
|
-✅ Completed
|
|
|
+⚠️ Needs Fix (发现设计缺陷：额度支付API没有联动订单服务修改订单状态)
|
|
|
|
|
|
## Story
|
|
|
**As a** 系统管理员，
|
|
|
@@ -55,6 +55,27 @@
|
|
|
- [x] `POST /api/credit-balance/checkout` - 结账恢复额度
|
|
|
- [x] 添加数据验证Schema (参考：`packages/advertisements-module-mt/src/schemas/`)
|
|
|
- [x] 添加权限控制和认证中间件
|
|
|
+ - [ ] **补充：在额度支付API中添加订单状态更新逻辑** (新发现的设计缺陷修复)
|
|
|
+ - [ ] **分析发现**：微信支付模块使用`updateOrderPaymentStatus`方法直接更新订单表，而不是调用订单服务
|
|
|
+ - [ ] **方案调整**：额度支付应遵循相同模式，直接操作订单表，保持一致性
|
|
|
+ - [ ] 修改`payment.mt.ts`路由文件，在额度扣减成功后直接更新订单支付状态
|
|
|
+ - [ ] 添加订单实体导入：`import { OrderMt } from '@d8d/orders-module-mt'`
|
|
|
+ - [ ] 添加支付状态和类型枚举导入：`import { PayStatus, PayType } from '@d8d/orders-module-mt'`
|
|
|
+ - [ ] 在额度扣减成功后调用：`await this.updateOrderPaymentStatus({...})`（参考微信支付实现）
|
|
|
+ - [ ] 更新订单支付状态为`PayStatus.SUCCESS`（支付成功），支付类型为`PayType.CREDIT`（额度支付）
|
|
|
+ - [ ] **注意**：需要同时更新`payState`和`payType`字段
|
|
|
+ - [ ] 添加事务处理，确保额度扣减和订单状态更新的一致性
|
|
|
+ - [ ] 添加错误处理，如果订单状态更新失败，回滚额度扣减操作
|
|
|
+
|
|
|
+ - [ ] **补充：修复微信支付模块的不足** (新发现的微信支付设计缺陷)
|
|
|
+ - [ ] **问题发现**：微信支付模块只更新`payState`字段，没有更新`payType`字段
|
|
|
+ - [ ] **更深层问题**：支付类型枚举(`PayType`)中没有微信支付类型，订单实体注释中也没有微信支付
|
|
|
+ - [ ] **修复方案**：
|
|
|
+ - [ ] 在支付类型枚举(`PayType`)中添加微信支付类型：`WECHAT: 4`
|
|
|
+ - [ ] 更新订单实体`pay_type`字段注释：添加"4微信支付"
|
|
|
+ - [ ] 修改微信支付模块的`updateOrderPaymentStatus`方法，同时更新`payState`和`payType`字段
|
|
|
+ - [ ] 微信支付成功时设置：`payState: PayStatus.SUCCESS`, `payType: PayType.WECHAT`
|
|
|
+ - [ ] 修复微信支付使用硬编码数字的问题，改为使用`PayStatus`枚举
|
|
|
|
|
|
|
|
|
- [x] **编写测试** (AC: 6)
|
|
|
@@ -62,6 +83,31 @@
|
|
|
- [x] **API集成测试**：测试端点功能和验证 (参考：`packages/advertisements-module-mt/tests/integration/advertisements.integration.test.ts`)
|
|
|
- [x] 添加边界条件测试：额度不足、重复操作等场景
|
|
|
- [x] 确保测试覆盖率 ≥ 80%
|
|
|
+ - [ ] **补充：在额度支付API集成测试中添加完整的订单创建→支付→状态更新流程测试**
|
|
|
+ - [ ] 在`credit-balance-routes.integration.test.ts`中添加新的测试用例
|
|
|
+ - [ ] 测试完整流程：创建测试订单→调用额度支付API→验证额度扣减→验证订单状态更新
|
|
|
+ - [ ] 模拟订单服务调用，验证`updatePaymentStatus`方法被正确调用
|
|
|
+ - [ ] 测试异常场景：订单状态更新失败时的回滚处理
|
|
|
+ - [ ] 测试事务一致性：额度扣减和订单状态更新必须在同一事务中
|
|
|
+
|
|
|
+ - [ ] **补充：更新微信支付模块集成测试，验证支付类型字段更新**
|
|
|
+ - [ ] 在微信支付集成测试中（如`payment.integration.test.ts`）添加测试用例
|
|
|
+ - [ ] 测试微信支付回调成功后，订单的`payType`字段是否正确设置为`PayType.WECHAT`
|
|
|
+ - [ ] 验证`payState`字段使用`PayStatus`枚举而不是硬编码数字
|
|
|
+ - [ ] 测试同时更新`payState`和`payType`字段的正确性
|
|
|
+ - [ ] 验证微信支付模块使用枚举而不是硬编码数字
|
|
|
+
|
|
|
+ - [ ] **补充：修复支付类型枚举和实体注释**
|
|
|
+ - [ ] 验证支付类型枚举(`PayType`)包含所有支付方式
|
|
|
+ - [ ] 在`PayType`枚举中添加微信支付类型：`WECHAT: 4`
|
|
|
+ - [ ] 验证订单实体`pay_type`字段注释包含所有支付类型
|
|
|
+ - [ ] 更新订单实体`pay_type`字段注释：添加"4微信支付"
|
|
|
+
|
|
|
+ - [ ] **补充：测试取消订单时的支付恢复逻辑**
|
|
|
+ - [ ] 测试取消订单时，额度支付订单的额度恢复逻辑
|
|
|
+ - [ ] 验证订单模块正确调用额度支付模块的`restoreBalanceForCancelOrder()`方法
|
|
|
+ - [ ] 测试取消订单时，微信支付订单的退款逻辑（如果存在）
|
|
|
+
|
|
|
|
|
|
- [x] **配置包依赖和导出** (AC: 3, 4)
|
|
|
- [x] 配置package.json依赖关系（TypeORM、Hono等） (参考：`packages/advertisements-module-mt/package.json`)
|
|
|
@@ -314,6 +360,22 @@ packages/
|
|
|
- **类型验证测试**：在集成测试中添加响应数据类型验证，确保金额字段为数字类型
|
|
|
- **测试验证**：所有24个测试通过，新增类型验证测试确认修复有效
|
|
|
|
|
|
+18. ⚠️ **发现额度支付API设计缺陷**：额度支付API没有联动订单服务修改订单状态
|
|
|
+ - **问题发现**：额度支付API只做额度扣减，没有更新订单的支付状态
|
|
|
+ - **影响**：订单创建后支付状态仍为"未支付"，与实际支付成功状态不一致
|
|
|
+ - **正确流程**：额度支付成功后，订单支付状态应更新为`PayStatus.SUCCESS`，支付类型为`PayType.CREDIT`
|
|
|
+ - **对比分析**：查看了微信支付模块的实现，发现微信支付使用`updateOrderPaymentStatus`方法直接更新订单表（硬编码数字），而不是调用订单服务
|
|
|
+ - **更深层发现**：微信支付模块也有设计缺陷：
|
|
|
+ 1. 只更新`payState`字段，没有更新`payType`字段
|
|
|
+ 2. 支付类型枚举(`PayType`)中没有微信支付类型
|
|
|
+ 3. 订单实体`pay_type`字段注释中也没有微信支付
|
|
|
+ 4. 使用硬编码数字而不是`PayStatus`枚举
|
|
|
+ - **方案调整**：额度支付应遵循相同模式，直接操作订单表，保持一致性
|
|
|
+ - **修复方案**：
|
|
|
+ - 在额度支付API中添加订单状态更新逻辑，参考微信支付实现直接更新订单表
|
|
|
+ - **同时修复微信支付的不足**：添加微信支付类型到枚举，更新微信支付模块同时设置`payState`和`payType`
|
|
|
+ - **测试补充**：需要在集成测试中添加完整的订单创建→额度支付→订单状态更新流程测试
|
|
|
+
|
|
|
### File List
|
|
|
**创建的文件：**
|
|
|
1. `packages/credit-balance-module-mt/package.json` - 包配置
|
yourname