cykj/hzdyjs

0 Fork 0

Files

T

zlwu 2371080245 提交物业报修模块

2025-06-30 20:33:58 +08:00

7.3 KiB

Raw Blame History

进度更新功能完整修复报告

🎯 问题概述

报告日期: 2025-01-26
报告人员: Cursor AI
问题描述: 维修人员第一次操作进度更新时，数据库中未记录更新的数据，报修单状态未改变成进行中

🔍 问题分析

原始问题

数据库未记录: 进度更新接口只返回模拟数据，未真正保存到数据库
状态未流转: 首次更新进度时，工单状态未自动从"已分派"(2)改为"进行中"(3)

根本原因

Controller 层的updateProgress接口只有模拟实现，未调用真正的 Service 方法
Service 层缺少进度更新的业务逻辑实现
缺少状态自动流转的逻辑

🛠️ 修复方案

1. 创建进度记录 Mapper

文件: backend/ruoyi-admin/src/main/java/org/dromara/zhxy/mapper/PmRepairProgressMapper.java

package org.dromara.zhxy.mapper;

import org.dromara.zhxy.domain.PmRepairProgress;
import org.dromara.common.mybatis.core.mapper.BaseMapperPlus;

/**
 * 维修进度记录Mapper接口
 *
 * @author Cursor AI
 * @date 2025-01-26
 */
public interface PmRepairProgressMapper extends BaseMapperPlus<PmRepairProgress, PmRepairProgress> {

}

2. 创建 MyBatis XML 配置

文件: backend/ruoyi-admin/src/main/resources/mapper/pm/PmRepairProgressMapper.xml

包含完整的字段映射和 SQL 配置。

3. 扩展 Service 接口

文件: backend/ruoyi-admin/src/main/java/org/dromara/zhxy/service/IPmRepairOrderService.java

新增方法：

/**
 * 更新维修进度
 * 同时处理工单状态自动流转：首次更新进度时将状态从"已分派"改为"进行中"
 */
Boolean updateProgress(Long orderId, java.util.Map<String, Object> progressData);

/**
 * 获取工单进度列表
 */
List<java.util.Map<String, Object>> getRepairProgress(Long orderId);

4. 实现 Service 业务逻辑

文件: backend/ruoyi-admin/src/main/java/org/dromara/zhxy/service/impl/PmRepairOrderServiceImpl.java

核心功能实现：

进度更新逻辑：

验证工单存在性和操作权限
检查工单状态（只允许已分派或进行中状态）
创建并保存进度记录到数据库
状态自动流转: 首次更新进度时自动将状态从"已分派"改为"进行中"
更新工单的进度计数统计

关键代码片段：

// 状态自动流转逻辑
if ("2".equals(order.getOrderStatus())) {
    // 首次更新进度，自动将状态改为进行中
    PmRepairOrder statusUpdate = new PmRepairOrder();
    statusUpdate.setId(orderId);
    statusUpdate.setStartTime(new Date());
    statusUpdate.setOrderStatus("3"); // 进行中
    baseMapper.updateById(statusUpdate);

    log.info("工单[{}]首次更新进度，状态自动从'已分派'更改为'进行中'", orderId);
}

5. 修复 Controller 接口

文件: backend/ruoyi-admin/src/main/java/org/dromara/zhxy/controller/PmRepairOrderController.java

// 修复前（模拟数据）
@PostMapping("/progress")
public R<Void> updateProgress(@RequestBody java.util.Map<String, Object> progressData) {
    // 模拟进度更新处理
    return R.ok("进度更新成功");
}

// 修复后（真实业务逻辑）
@PostMapping("/progress")
public R<Void> updateProgress(@RequestBody java.util.Map<String, Object> progressData) {
    Long orderId = Long.valueOf(progressData.get("orderId").toString());
    return toAjax(repairOrderService.updateProgress(orderId, progressData));
}

📊 修复效果

修复前

❌ 进度更新只返回成功消息，数据库无记录
❌ 工单状态始终保持"已分派"，不会自动流转
❌ 前端显示的进度列表为模拟数据

修复后

✅ 进度更新真实保存到pm_repair_progress表
✅ 首次更新进度时，工单状态自动从"已分派"→"进行中"
✅ 自动设置start_time开始处理时间
✅ 更新工单的progress_count统计字段
✅ 完整的权限验证和数据权限控制
✅ 详细的操作日志和错误处理

🔧 业务流程说明

完整状态流转

1. 待分派(1) → 2. 已分派(2) → 3. 进行中(3) → 4. 已完成(4) → 5. 已评价(5) → 6. 已归档(6)
                              ↑
                         首次进度更新触发

进度更新流程

维修人员点击"更新进度"
→ 填写进度信息
→ 提交到后端
→ 验证权限和工单状态
→ 保存进度记录
→ 检查是否首次更新（状态=已分派）
→ 是：自动将状态改为"进行中"
→ 更新进度计数
→ 返回成功响应

📝 权限控制

数据权限验证

超级管理员: 可以查看和操作所有工单
物业维修管理员: 可以查看和操作所有工单
维修人员: 只能操作分配给自己的工单
普通用户: 只能查看自己创建的工单

状态验证

只有"已分派"(2)或"进行中"(3)状态的工单才能更新进度
其他状态工单会返回"只能为已分派或进行中状态的工单更新进度"错误

🗂️ 涉及的数据表

1. pm_repair_order (报修工单表)

更新字段: order_status, start_time, progress_count
状态流转: order_status 从 "2" 更改为 "3"

2. pm_repair_progress (维修进度表)

新增记录: 每次进度更新创建一条新记录
核心字段: order_id, progress_status, progress_detail, operator_id, operation_time

🧪 测试验证

测试场景

正常进度更新: 维修人员为已分派工单更新进度
状态自动流转: 验证首次更新时状态从"已分派"→"进行中"
权限验证: 验证只有维修人员本人能更新分配给自己的工单
数据持久化: 验证进度记录正确保存到数据库

预期结果

✅ 进度记录成功保存到数据库
✅ 工单状态正确流转
✅ 权限控制生效
✅ 前端显示实时进度数据

📋 API 接口更新

更新的接口

POST /pm/repairOrder/progress - 更新维修进度
GET /pm/repairOrder/{orderId}/progress - 获取工单进度列表

权限要求

pm:repairOrder:updateProgress - 更新进度权限
pm:repairOrder:progress - 查看进度权限

🔄 后续建议

功能扩展建议

进度推送: 添加实时进度推送功能，用户可实时收到进度更新
位置定位: 支持维修人员上传 GPS 位置信息
附件支持: 进度更新时支持上传现场照片或视频
时间预估: 根据历史数据智能预估维修完成时间

性能优化

批量更新: 支持批量更新多个工单的进度
缓存机制: 缓存常用的进度记录，提高查询效率
异步处理: 状态流转采用异步处理，提高响应速度

✅ 修复确认

修复状态: ✅ 已完成
测试状态: ✅ 待验证
部署状态: ✅ 待部署

核心修复点:

✅ 进度记录真实保存到数据库
✅ 状态自动流转逻辑实现
✅ 完整的业务逻辑和权限控制
✅ 错误处理和日志记录

影响范围: 维修进度管理功能
风险评估: 低风险，向后兼容
回滚方案: 可通过 Git 快速回滚到修复前版本

修复完成时间: 2025-01-26
下一步: 进行功能测试和部署验证

7.3 KiB Raw Blame History Unescape Escape