生成时间: 2026-08-03 · 数据来源: xnybw平台需求及工作计划.xlsx(南网在线绿能云缺陷跟踪表)· 仅针对 backup730/730backup 分支代码

① 基本信息

问题描述外网侧用户在并网资料信息页面上传资料点击提交发送流程页面刷新之后,当前处理人显示的是自己(不应该显示处理人是自己),内网侧显示的处理人是正确的
一级模块并网资料流程
二级模块并网资料流程
涉及类型集中式新能源
严重性中等
当前状态2.1.待开发
研发处理人(台账未填写)

② 问题截图

互联网侧-当前处理人显示为提交人自己
截图1(gec.csg.cn 互联网/绿能云侧):第2行"当前处理人"显示为一串手机号(提交人自己)
内网侧-当前处理人显示为真实审核人
截图2(电网运行管理系统 内网侧):同一条记录第2行"当前处理人"正确显示"詹厚剑,黄崽,胡甲秋..."等真实专业审核人姓名

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

xnybw5b / src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/NePjInfoFlowAppService.java 第 413-545 行(sendTask 提交方法)
xnybw5f / src/approval/projectData/component/batchInfo.vue 第 4118-4188 行(submitFlow 方法,提交请求参数构造)

④ 代码现状与修复方案

这条与本批次第79行"并网资料撤回后重新提交,当前处理人显示自己"同一处代码缺陷的另一种触发路径:79行是"撤回→再提交",本行是"首次提交",两者都会命中 NePjInfoFlowAppService.sendTask() 里同一段问题代码。为避免重复展开,这里只概述核心结论,完整代码分析见第79行方案页。

核心问题:sendTask() 把流程真正推进到下一节点(flowService.sendFlow(...))之后,除了"归档"(SXSP)分支外,没有把 informationFlow.currentUserId/currentUserName 重新赋值为真正的下一节点处理人,最终 saveOrUpdateFlow(informationFlow) 落库时用的仍是前端提交请求里原样带来的旧值(互联网侧提交表单里,这个字段就是提交人自己):

flowService.sendFlow(FlowEnum.FlowType.项目资料流程, informationFlow.getId(), currentUserId, flowStatus
        , informationFlow.getCurrentUserId().split(","), informationFlow.getAdvice());
if (FlowConst.SXSP.equals(informationFlow.getTaskName())) {
    informationFlow.setCurrentUserId(currentUserId);   // 只有归档分支才重新赋值
} else {
    isDb = true;   // "编制→专业审核"等中间流转,没有重新计算currentUserId
}
...
saveOrUpdateFlow(informationFlow);   // 把提交人自己(旧值)落库为"当前处理人"
为什么内网侧(电网运行管理系统/OMS2.0)显示是正确的?内网侧是三区独立的系统,它展示"当前处理人"用的是自己一套按角色/专业动态解析审核人的逻辑(例如按"水新专业+地调/中调"实时查专业审核人员名单),并不直接读取互联网侧这条 NePjInfoFlowVO.CURRENT_USER_ID 记录字段,所以不受这个字段落库错误的影响,从侧面印证了问题确实出在互联网侧 sendTask() 没有正确回写这个字段,而不是流程引擎本身把任务分派错了人(内网侧的"专业审核"待办列表里,詹厚剑等人确实能看到并处理这条任务,只是互联网侧展示的字段没跟着更新)。

建议修复方式:与第79行一致——在 sendTask() 的中间节点分支里,也要用本次提交实际生效的下一节点处理人列表重新赋值 currentUserId/currentUserName,不能只在归档分支处理;前端 submitFlow() 也不应直接把 row.informationFlow.currentUserId(提交前的旧值)原样当作请求参数传给后端。详见 solution-79.html 中的完整修复代码示例。