hzdyjs/test/指派人员数据未更新问题诊断修复报告.md

指派人员数据未更新问题诊断修复报告

问题报告人: 用户反馈
问题描述: 指派人员时，维修人员等数据未更新到数据库
诊断时间: 2025-06-30 18:50:00
问题级别: 🔴 严重 - 核心业务功能异常

🔍 问题分析

问题现象

1. 前端表现: 用户在界面上选择维修人员并点击分派按钮后，工单状态没有更新
2. 数据库状态: 工单的assignee_id, assignee_name, assign_time, order_status等字段未被更新
3. API 响应: 分派接口可能返回成功，但实际数据未保存

技术问题定位

问题 1: 维修人员查询 SQL 错误 🚨

位置: backend/ruoyi-admin/src/main/resources/mapper/pm/PmRepairOrderMapper.xml

错误代码:

SELECT u.user_id as value, u.nick_name as label, u.user_name as userName, d.dept_name as deptName
FROM sys_user u
LEFT JOIN sys_dept d ON u.dept_id = d.dept_id
INNER JOIN sys_user_role ur ON u.user_id = ur.user_id
INNER JOIN sys_role r ON ur.role_id = r.role_id
WHERE r.role_name = '维修人员'  -- ❌ 错误：角色名称不匹配
AND u.status = '0'
AND u.del_flag = '0'
ORDER BY u.user_id

问题分析:

• SQL 中使用了r.role_name = '维修人员'条件
• 但系统中实际的角色名称是maintenance_worker或其他英文名称
• 导致查询不到任何维修人员，返回空数组
• 前端无法选择维修人员进行分派

问题 2: 可能的数据权限问题

位置: PmRepairOrderServiceImpl.assignOrder方法

潜在问题:

• 数据权限验证可能过于严格
• MyBatis-Plus 的更新操作可能受到租户或数据权限影响

🔧 解决方案

方案 1: 修复维修人员查询 SQL（推荐）

步骤 1: 查询系统中实际的维修相关角色名称

-- 查询系统中所有角色，找到维修相关的角色
SELECT role_id, role_name, role_key, status
FROM sys_role
WHERE role_name LIKE '%维修%'
   OR role_key LIKE '%maintenance%'
   OR role_key LIKE '%worker%'
   AND status = '0' AND del_flag = '0';

步骤 2: 更新 XML 中的 SQL 查询 根据实际角色名称修改查询条件，支持多种角色匹配：

SELECT u.user_id as value, u.nick_name as label, u.user_name as userName, d.dept_name as deptName
FROM sys_user u
LEFT JOIN sys_dept d ON u.dept_id = d.dept_id
INNER JOIN sys_user_role ur ON u.user_id = ur.user_id
INNER JOIN sys_role r ON ur.role_id = r.role_id
WHERE (r.role_key = 'maintenance_worker' OR r.role_name = '维修人员' OR r.role_id = 5)
  AND u.status = '0'
  AND u.del_flag = '0'
ORDER BY u.user_id

方案 2: 确保角色数据正确性

步骤 1: 检查维修人员角色是否存在

-- 检查维修人员角色
SELECT * FROM sys_role WHERE role_key = 'maintenance_worker' OR role_name = '维修人员';

-- 检查是否有用户分配了该角色
SELECT ur.*, u.user_name, r.role_name
FROM sys_user_role ur
JOIN sys_user u ON ur.user_id = u.user_id
JOIN sys_role r ON ur.role_id = r.role_id
WHERE r.role_key = 'maintenance_worker' OR r.role_name = '维修人员';

步骤 2: 如果角色不存在，创建维修人员角色

-- 创建维修人员角色（如果不存在）
INSERT INTO sys_role (role_id, tenant_id, role_name, role_key, role_sort, data_scope,
                      menu_check_strictly, dept_check_strictly, status, del_flag,
                      create_by, create_time, remark)
SELECT 5, '000000', '维修人员', 'maintenance_worker', 5, '1', 1, 1, '0', '0', 1, NOW(), '物业维修人员角色'
WHERE NOT EXISTS (SELECT 1 FROM sys_role WHERE role_key = 'maintenance_worker');

方案 3: 测试数据准备

创建测试维修人员:

-- 为测试用户zwc007分配维修人员角色
INSERT IGNORE INTO sys_user_role (user_id, role_id)
SELECT u.user_id, r.role_id
FROM sys_user u, sys_role r
WHERE u.user_name = 'zwc007'
  AND r.role_key = 'maintenance_worker';

-- 验证角色分配
SELECT u.user_name, r.role_name, r.role_key
FROM sys_user u
JOIN sys_user_role ur ON u.user_id = ur.user_id
JOIN sys_role r ON ur.role_id = r.role_id
WHERE u.user_name = 'zwc007';

🛠️ 修复步骤

第一步: 诊断当前状态

1. 运行角色查询 SQL，确认维修人员角色的实际名称
2. 检查是否有用户被分配了维修人员角色
3. 测试维修人员选项接口是否返回数据

第二步: 修复 SQL 查询

1. 根据实际角色信息更新PmRepairOrderMapper.xml中的 SQL
2. 重启后端服务
3. 测试维修人员接口是否正常返回数据

第三步: 验证分派功能

1. 使用修复后的维修人员列表进行工单分派
2. 检查数据库中工单记录是否正确更新
3. 验证前端界面显示是否正常

第四步: 完整功能测试

1. 创建测试工单
2. 执行完整的分派->接收->进度更新->完成流程
3. 确认所有状态流转正常

📋 验证清单

数据库验证

• 维修人员角色存在且正确配置
• 至少有一个用户拥有维修人员角色
• 维修人员查询 SQL 返回正确数据
• 分派后工单状态正确更新为"已分派"

接口验证

• /pm/repairOrder/maintenance-workers 接口返回维修人员列表
• PUT /pm/repairOrder/{id}/assign 接口执行成功
• 分派后重新查询工单，assignee 信息已更新

前端验证

• 分派对话框能正常显示维修人员选项
• 选择维修人员后能成功提交
• 分派成功后工单列表状态更新
• 维修人员能看到分派给自己的工单

🎯 预期结果

修复完成后：

1. 维修人员接口正常: 返回系统中所有维修人员的列表
2. 分派功能正常: 能够成功将工单分派给选定的维修人员
3. 数据库更新正确: 工单的 assignee_id、assignee_name、assign_time、order_status 字段正确更新
4. 前端显示正常: 分派后的工单在界面上显示正确的状态和维修人员信息

🚨 注意事项

1. 角色名称一致性: 确保数据库中的角色名称与代码中的匹配
2. 权限验证: 修复后确保权限验证逻辑仍然正常工作
3. 数据一致性: 分派操作应该是原子性的，要么全部成功，要么全部失败
4. 日志记录: 增加详细的日志记录，便于后续问题排查

📝 修复记录

执行人: Cursor AI
修复时间: 2025-06-30 18:50:00
修复文件:

• backend/ruoyi-admin/src/main/resources/mapper/pm/PmRepairOrderMapper.xml
• 可能涉及角色和权限相关 SQL 脚本

测试方法:

• 运行 test/指派人员数据更新验证脚本.js 进行完整验证
• 手工测试前端分派功能

---

状态: 🔄 待修复
优先级: 🔴 高优先级 - 影响核心业务流程