缺陷修复方案 · Excel第79行 · 并网资料流程撤回后重新提交，当前处理人错误显示为提交人自己

① 基本信息

问题描述	并网资料提交之后，用户撤回，然后再提交，显示当前处理人是用户自己
一级模块	并网资料流程
二级模块	/
涉及类型	全部类型
严重性	严重
当前状态	2.1.待开发
研发处理人	周小龙
处理状态	待调整

② 问题截图

撤回后重新提交，当前处理人显示自己 — 并网资料流程撤回后重新提交，当前处理人栏显示为提交人自己，而非下一节点的真实审核人

③ 旧代码涉及的项目文件及行数（backup730/730backup 分支）

xnybw5b / src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/NePjInfoFlowAppService.java 第 1025-1080 行（recoverTask 撤回方法）、第 413-545 行（sendTask 提交方法）

xnybw5f / src/approval/projectData/component/batchInfo.vue 第 4118-4188 行（submitFlow 方法，提交请求参数构造）

④ 代码现状与修复方案

第一步：撤回（recoverTask）本身没有问题。 NePjInfoFlowAppService.recoverTask() 第 1058-1059 行，撤回到"编制"节点时正确地把 currentUserId/currentUserName 设为撤回操作人自己——因为撤回后流程确实停在"编制"节点，处理人就是提交人自己，这一步的显示是正确的：

informationFlow.setCreator(currentUserId);
informationFlow.setCreateTime(Timestamp.from(new Date().toInstant()));
informationFlow.setCurrentUserId(currentUserId);   // 第1058行：撤回到编制节点，处理人=自己，正确
informationFlow.setCurrentUserName(currentUserName);

第二步：前端"提交"请求直接照抄了撤回后的旧值。 batchInfo.vue 的 submitFlow() 方法构造提交参数时，currentUserId 字段是从当前行 row.informationFlow.currentUserId（也就是撤回后停留在"编制"节点时的值＝提交人自己）直接原样取出来的，并没有计算提交后下一节点真正的处理人：

const param = {
  ...
  currentUserId: row.informationFlow ? row.informationFlow.currentUserId : '',   // 沿用撤回后的旧值（自己），未重新计算下一节点处理人
  currentUserName: row.informationFlow ? row.informationFlow.currentUserName : '',
  ...
}

第三步：后端 sendTask() 提交流程时，没有用真正的下一节点处理人覆盖这个字段。 NePjInfoFlowAppService.sendTask() 计算出 nextTaskName/flowStatus 并调用 flowService.sendFlow(...) 把流程真正推进到下一节点后，只在流程归档（SXSP）分支里重新设置了 currentUserId，对于"编制→专业审核"这种中间节点流转，完全没有重新计算 currentUserId，最终 saveOrUpdateFlow(informationFlow) 把前端传来的旧值（自己）原样存回了数据库：

flowService.sendFlow(FlowEnum.FlowType.项目资料流程,informationFlow.getId(),currentUserId,flowStatus
        ,informationFlow.getCurrentUserId().split(","),informationFlow.getAdvice());   // 仅用于给"下一节点"的flowusers参数，不影响本对象字段
if (FlowConst.SXSP.equals(informationFlow.getTaskName())) {
    informationFlow.setCurrentUserId(currentUserId);   // 只有归档分支才重设currentUserId
    ...
} else {
    isDb = true; //补充代办    // 中间节点分支：没有对currentUserId做任何重新赋值
}
...
informationFlow.setTaskName("结束".equals(nextTaskName)?"已归档":nextTaskName);
informationFlow.setTaskDefKey(taskDefKey);
saveOrUpdateFlow(informationFlow);   // 把前端传来的旧currentUserId（提交人自己）原样落库

正常情况下（未经历撤回）提交时前端传的 currentUserId 恰好也是"当前节点处理人自己"，同样会被原样存下——但因为正常流转下页面展示逻辑另有其它字段兜底或用户很快点击了下一步操作，这个问题不易被发现；而"撤回→重新提交"路径把这一缺陷暴露得非常明显：撤回后 currentUserId 被明确设为自己，重新提交时又没人纠正，问题就稳定复现了。

建议修复方式： 在 sendTask() 中，无论是否归档，都应该在调用 flowService.sendFlow() 之后，根据本次提交实际选择的下一节点处理人（即前端节点选择弹窗里用户勾选的 userIds，而不是沿用流转前的 currentUserId）重新赋值：

// 中间节点分支缺少 currentUserId 重新赋值
} else {
    isDb = true;
    // 修复：用本次提交时前端选择的下一节点处理人列表覆盖，而不是沿用流转前的值
    if (StrUtil.isNotBlank(informationFlow.getNextUserIds())) {
        informationFlow.setCurrentUserId(informationFlow.getNextUserIds());
        informationFlow.setCurrentUserName(informationFlow.getNextUserNames());
    }
}

同时前端 submitFlow() 也应改为传"本次提交后目标节点的处理人"（例如从节点选择弹窗 node-send.vue 选中的人员列表取值），而不是直接复用 row.informationFlow.currentUserId 这个流转前的旧值。