40 lines
2.3 KiB
Markdown
40 lines
2.3 KiB
Markdown
|
# 项目管理列表重新分析后端验证记录
|
|||
|
|
|
|||
|
|
## 验证范围
|
|||
|
|
|
|||
|
|
- 手动重打标接口可直接复用于列表页
|
|||
|
|
- 重打标开始后项目进入打标中
|
|||
|
|
- 重打标成功后自动重算项目风险人数
|
|||
|
|
- 运行中任务和归档项目保留既有后端保护
|
|||
|
|
|
|||
|
|
## 链路核验
|
|||
|
|
|
|||
|
|
- `POST /ccdi/project/tags/rebuild` 由 `CcdiBankTagController.rebuild(...)` 提供入口，并透传 `projectId`、`modelCode` 与操作人
|
|||
|
|
- `CcdiBankTagServiceImpl.submitRebuild(...)` 继续复用 `ProjectBankTagRebuildCoordinator.submitManual(...)`
|
|||
|
|
- `CcdiBankTagServiceImpl.rebuildProject(...)` 开始时调用 `projectService.updateProjectStatus(projectId, CcdiProjectStatusConstants.TAGGING, operator)`，满足“打标中”状态切换要求
|
|||
|
|
- `CcdiBankTagServiceImpl.rebuildProject(...)` 成功路径会调用 `projectOverviewService.refreshOverviewEmployeeResults(projectId, operator)`
|
|||
|
|
- `CcdiProjectOverviewServiceImpl.refreshOverviewEmployeeResults(...)` 会在重建员工结果后同步调用 `projectMapper.updateRiskCountsByProjectId(...)`，刷新高/中/低风险人数
|
|||
|
|
|
|||
|
|
## 验证命令
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
mvn -pl ccdi-project -Dtest=CcdiBankTagControllerTest,ProjectBankTagRebuildCoordinatorTest,CcdiBankTagServiceRiskCountRefreshTest test
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 验证结果
|
|||
|
|
|
|||
|
|
- 结果：通过
|
|||
|
|
- `CcdiBankTagControllerTest` 通过 2 个用例，覆盖手动重打标控制器入口
|
|||
|
|
- `ProjectBankTagRebuildCoordinatorTest` 通过 6 个用例，覆盖运行中防重提交流程、补跑标记与归档保护
|
|||
|
|
- `CcdiBankTagServiceRiskCountRefreshTest` 通过 2 个用例，覆盖成功后刷新员工结果与刷新失败时任务转失败分支
|
|||
|
|
- 总计 10 个用例全部通过，Surefire 结果为 `BUILD SUCCESS`
|
|||
|
|
- 测试日志中的 `refresh failed` 为失败分支测试主动构造的预期异常，不影响最终通过结论
|
|||
|
|
|
|||
|
|
## 关键结论
|
|||
|
|
|
|||
|
|
- 项目列表“重新分析”后端无需新增接口，直接复用现有 `POST /ccdi/project/tags/rebuild`
|
|||
|
|
- 现有链路已覆盖“重新打标并重新计算人数”的后端要求，不需要新增服务分支或补充额外人数重算调用
|
|||
|
|
- 手动重打标开始后会先切换项目状态为 `TAGGING`
|
|||
|
|
- 重打标成功后会同步刷新员工风险结果，并回写项目高/中/低风险人数
|
|||
|
|
- 运行中任务重复提交与不可启动项目的保护逻辑已存在，可继续沿用
|