① 基本信息
| 问题描述 | 外网侧提交后，审核人是自己 |
|---|---|
| 一级模块 | 实际并网流程 |
| 二级模块 | 项目基本信息 |
| 涉及类型 | 中压分布式新能源 |
| 严重性 | 严重 |
| 当前状态 | 2.1.待开发 |
| 研发处理人 | （台账未填写） |
② 问题截图
③ 旧代码涉及的项目文件及行数（backup730 分支）
xnybw5f / src/views/projectNew/components/actualInfo/components/tabItem.vue
第 472-533 行（batchAuditFlow，用 cascadeQuery 返回的 todoUser 覆盖人员选择结果）
xnybw5f / src/views/projectNew/components/actualInfo/components/tabItem.vue
第 609-635 行（sendFlow 方法，中压分布式新能源"直连总调"时 flowstatus 直接置为 '2' 并打开 userSelect）
④ 代码现状与修复方案
本行现象与第85行（集中式新能源，"编制→中调审核"目标处理人显示自己）几乎一致，代码同样落在 tabItem.vue。batchAuditFlow() 内部在 oldFlowStatus == '2' 时，会用 cascadeQuery 接口返回的 todoUser/todoUserId（提交前该记录当前挂在谁的待办上——此时还是提交人自己）去覆盖用户在 userSelect 弹窗里手动选择的审核人列表，完整代码分析见 solution-85.html。
本行涉及的项目类型是"中压分布式新能源"，额外注意到 sendFlow() 方法里有一段按公司名称直接判定流转目标的逻辑：
sendFlow(bizId) {
let flowstatus = '1';
if (this.plantItem.company.indexOf('总调') != -1) {
flowstatus = '2'; // 第613行：公司名称含"总调"，直接把flowstatus设为'2'
}
...
this.$refs.userSelect.open({ params, callback: result => {
if (result.action == 'OK') {
let params = { ..., userList: result.users, ..., currentFlowStatus: "1" }; // 未设置oldFlowStatus字段
this.batchAuditFlow({ dataList: [params] });
}
}})
}
这里调用
batchAuditFlow 时传入的参数对象没有 oldFlowStatus 字段，按 batchAuditFlow() 内部 if (data.dataList[0].oldFlowStatus == '2') 的判断，理论上会走 else 分支，直接使用 userSelect 弹窗里选定的 result.users 提交，不会被 cascadeQuery 覆盖。但截图现象与"目标处理人=自己"完全吻合，说明本行触发的实际提交入口很可能不是这个 sendFlow()，而是同一组件里另一处会设置 oldFlowStatus:'2' 的提交入口（第438行 handleAuditClick 内的分支，与第85行代码位置相同）。受限于仅静态审查代码、未做运行时调试，未能 100% 确认本行截图具体命中的是哪一个提交入口，这里如实说明，两个入口都建议一并核查修复。
建议修复方式：
- 按 solution-85.html 的方案，去掉
batchAuditFlow()中用cascadeQuery.todoUser覆盖userList的逻辑，统一直接使用userSelect弹窗选择结果； - 核实
sendFlow()（第609-635行）与handleAuditClick（第415-465行）这两个提交入口是否被中压分布式新能源类型的实际提交流程共同复用，避免其中一个入口遗漏正确传递用户选择结果。