196 lines
5.8 KiB
Markdown
196 lines
5.8 KiB
Markdown
|
# 项目管理列表重新分析确认与刷新设计文档
|
||
|
|
|
||
|
|
## 背景
|
||
|
|
|
||
|
|
项目管理列表页已经接入“重新分析”真实调用链路：
|
||
|
|
|
||
|
|
- 前端通过 `POST /ccdi/project/tags/rebuild` 提交项目级重打标
|
||
|
|
- 成功后提示“已开始重新分析”
|
||
|
|
- 随后调用 `getList()` 刷新列表与状态统计
|
||
|
|
|
||
|
|
当前缺口主要有两个：
|
||
|
|
|
||
|
|
1. 用户点击“重新分析”后会立即发起请求，缺少二次确认
|
||
|
|
2. 需要明确本轮仍然沿用成功后的全列表刷新策略，不做局部行补丁更新
|
||
|
|
|
||
|
|
本次需求是在现有真实调用能力之上补齐交互确认，并保持最短路径实现。
|
||
|
|
|
||
|
|
## 目标
|
||
|
|
|
||
|
|
- 为项目列表中的“重新分析”按钮增加确认弹窗
|
||
|
|
- 用户确认后才触发 `rebuildProjectTags`
|
||
|
|
- 调用成功后继续刷新项目列表与顶部状态统计
|
||
|
|
- 保持现有失败提示、按钮提交态和状态驱动展示逻辑
|
||
|
|
|
||
|
|
## 范围
|
||
|
|
|
||
|
|
### In Scope
|
||
|
|
|
||
|
|
- `ruoyi-ui/src/views/ccdiProject/index.vue` 中“重新分析”交互链路补充确认弹窗
|
||
|
|
- 沿用现有 `reAnalyzeLoadingMap` 防重复点击
|
||
|
|
- 成功后沿用 `getList()` 刷新列表和状态统计
|
||
|
|
- 取消确认、调用成功、调用失败三类前端行为收口
|
||
|
|
- 补充对应前端验证与实施文档
|
||
|
|
|
||
|
|
### Out of Scope
|
||
|
|
|
||
|
|
- 不新增后端接口
|
||
|
|
- 不新增轮询、进度提示、消息推送
|
||
|
|
- 不做局部列表行更新或乐观更新
|
||
|
|
- 不调整“重新分析”按钮显示条件
|
||
|
|
- 不变更后端重打标、风险人数计算或状态流转逻辑
|
||
|
|
|
||
|
|
## 现状分析
|
||
|
|
|
||
|
|
### 前端现状
|
||
|
|
|
||
|
|
`ruoyi-ui/src/views/ccdiProject/index.vue` 中的 `handleReAnalyze(row)` 当前流程为：
|
||
|
|
|
||
|
|
1. 判断当前项目是否处于重新分析提交中
|
||
|
|
2. 设置按钮 loading
|
||
|
|
3. 调用 `rebuildProjectTags({ projectId })`
|
||
|
|
4. 成功提示“已开始重新分析”
|
||
|
|
5. 调用 `getList()` 刷新列表
|
||
|
|
6. 失败时弹出错误提示
|
||
|
|
|
||
|
|
当前缺少用户确认步骤，因此点击即执行。
|
||
|
|
|
||
|
|
### 后端现状
|
||
|
|
|
||
|
|
后端现有 `/ccdi/project/tags/rebuild` 能力已满足本轮需求：
|
||
|
|
|
||
|
|
- 支持按 `projectId` 提交项目级重打标
|
||
|
|
- 会按既有流程更新项目状态
|
||
|
|
- 完成后由现有链路刷新结果与风险人数
|
||
|
|
|
||
|
|
因此本轮仍然只做前端交互补充，不引入后端源码改造。
|
||
|
|
|
||
|
|
## 方案选择
|
||
|
|
|
||
|
|
### 推荐方案
|
||
|
|
|
||
|
|
在列表页现有 `handleReAnalyze(row)` 中补充确认弹窗，确认后继续执行当前请求和刷新逻辑。
|
||
|
|
|
||
|
|
执行顺序：
|
||
|
|
|
||
|
|
1. 用户点击“重新分析”
|
||
|
|
2. 前端弹出确认框
|
||
|
|
3. 用户点击“确定”后再进入接口调用
|
||
|
|
4. 调用成功后提示“已开始重新分析”
|
||
|
|
5. 继续调用 `getList()` 刷新列表与统计
|
||
|
|
|
||
|
|
采用该方案的原因：
|
||
|
|
|
||
|
|
- 改动最小，符合最短路径要求
|
||
|
|
- 保持 `ProjectTable.vue` 只负责事件透传，不下沉业务交互逻辑
|
||
|
|
- 与当前页面级操作风格一致，便于复用现有 loading 和刷新逻辑
|
||
|
|
|
||
|
|
### 不采用的方案
|
||
|
|
|
||
|
|
#### 方案一：在 `ProjectTable.vue` 内直接处理确认弹窗
|
||
|
|
|
||
|
|
不采用原因：
|
||
|
|
|
||
|
|
- 表格组件职责变重
|
||
|
|
- 确认逻辑与接口逻辑分散在父子组件之间
|
||
|
|
- 不利于后续维护同类页面级操作
|
||
|
|
|
||
|
|
#### 方案二：抽象通用确认执行器
|
||
|
|
|
||
|
|
不采用原因：
|
||
|
|
|
||
|
|
- 对当前需求属于过度设计
|
||
|
|
- 只为单个按钮增加抽象，收益低于额外复杂度
|
||
|
|
|
||
|
|
## 详细设计
|
||
|
|
|
||
|
|
## 1. 交互设计
|
||
|
|
|
||
|
|
点击“重新分析”后，前端先弹出确认框，文案为：
|
||
|
|
|
||
|
|
`确认对项目“{项目名称}”重新分析吗？重新分析将重新计算项目标签。`
|
||
|
|
|
||
|
|
交互约束：
|
||
|
|
|
||
|
|
- 点击“确定”才继续发起请求
|
||
|
|
- 点击“取消”直接结束，不提示失败，不刷新列表
|
||
|
|
- 弹窗只承担确认职责，不展示额外解释信息
|
||
|
|
|
||
|
|
## 2. 数据流与状态设计
|
||
|
|
|
||
|
|
确认后的请求链路保持现有实现：
|
||
|
|
|
||
|
|
1. 读取 `projectId`
|
||
|
|
2. 设置当前项目按钮 loading
|
||
|
|
3. 调用 `rebuildProjectTags({ projectId })`
|
||
|
|
4. 成功后提示 `已开始重新分析`
|
||
|
|
5. 调用 `getList()` 刷新列表和顶部统计
|
||
|
|
6. 在 `finally` 中清理 loading
|
||
|
|
|
||
|
|
说明：
|
||
|
|
|
||
|
|
- `getList()` 已并行请求项目列表和状态统计，继续复用即可保证界面一致性
|
||
|
|
- 不做局部行状态修改，避免列表和顶部统计出现时序不一致
|
||
|
|
|
||
|
|
## 3. 异常与边界设计
|
||
|
|
|
||
|
|
### 取消确认
|
||
|
|
|
||
|
|
- 用户主动取消时，不发请求
|
||
|
|
- 不设置 loading
|
||
|
|
- 不弹错误提示
|
||
|
|
|
||
|
|
### 接口失败
|
||
|
|
|
||
|
|
- 优先展示后端返回的 `error.message`
|
||
|
|
- 无明确业务文案时，统一提示 `重新分析失败，请稍后重试`
|
||
|
|
- 失败时不刷新列表，保持当前数据稳定
|
||
|
|
|
||
|
|
### 防重复提交
|
||
|
|
|
||
|
|
- 保持单项目维度的 `reAnalyzeLoadingMap`
|
||
|
|
- 只有在用户确认后才进入 loading
|
||
|
|
- 提交结束后恢复按钮状态
|
||
|
|
|
||
|
|
## 4. 测试设计
|
||
|
|
|
||
|
|
前端验证聚焦以下场景：
|
||
|
|
|
||
|
|
1. 点击“重新分析”先出现确认弹窗
|
||
|
|
2. 点击“取消”时不发请求、不刷新列表
|
||
|
|
3. 点击“确定”后发起接口调用
|
||
|
|
4. 请求成功时提示“已开始重新分析”并刷新列表
|
||
|
|
5. 请求失败时提示失败信息，按钮恢复可点击
|
||
|
|
|
||
|
|
回归重点：
|
||
|
|
|
||
|
|
- 重新分析按钮仍只在既有状态条件下显示
|
||
|
|
- 成功刷新后项目状态和顶部统计继续由后端返回结果驱动
|
||
|
|
|
||
|
|
## 5. 后端影响说明
|
||
|
|
|
||
|
|
本轮后端无需改造。
|
||
|
|
|
||
|
|
原因：
|
||
|
|
|
||
|
|
- 现有 `/ccdi/project/tags/rebuild` 已满足提交能力
|
||
|
|
- 现有 `getList()` 刷新结果已经满足页面回显需要
|
||
|
|
- 本次变更仅增加用户确认，不改变接口语义
|
||
|
|
|
||
|
|
## 6. 风险与约束
|
||
|
|
|
||
|
|
- 本轮仍然是“提交后刷新一次”的模式，不展示任务进度
|
||
|
|
- 如果后端异步处理时间较长，用户看到项目进入处理中状态属于预期
|
||
|
|
- 方案依赖现有后端重打标链路稳定可用，不额外建设旁路能力
|
||
|
|
|
||
|
|
## 7. 本次设计结论
|
||
|
|
|
||
|
|
本次需求采用“列表页现有重新分析链路上补确认弹窗，并在成功后继续全列表刷新”的方案。
|
||
|
|
|
||
|
|
该方案满足以下要求：
|
||
|
|
|
||
|
|
- 最短路径实现
|
||
|
|
- 不引入补丁式旁路方案
|
||
|
|
- 前后端职责边界清晰
|
||
|
|
- 列表数据与统计刷新保持一致
|