cykj/hzdyjs

0 Fork 0

Files

T

weizhong e79bf5a26c “编译修改”

2025-10-14 16:41:19 +08:00

10 KiB

Raw Blame History

🎯 业务逻辑优化 - 行程变更选项卡

📋 优化内容

问题描述

原有问题：

❌ "变更申请"选项卡显示所有状态的数据（待审核、已通过、已拒绝）
❌ 已通过的数据出现在两个选项卡中（既在变更申请，又在变更记录）
❌ 业务逻辑不清晰，用户体验不佳

正确的业务逻辑：

✅ 变更申请选项卡：只显示**待审核（status=0）**的数据
✅ 变更记录选项卡：只显示**已通过（status=1）**的数据
✅ 已通过的数据会自动从"变更申请"流转到"变更记录"

✅ 修复内容

修改文件

文件路径：

web/src/views/rs/overseas/itinerary-change.vue

修改详情

1. 更新选项卡标签（更清晰）

修改位置：第 8 行和第 121 行

<!-- 修改前 -->
<el-tab-pane label="变更申请" name="all">
<el-tab-pane label="变更记录" name="my">

<!-- 修改后 -->
<el-tab-pane label="变更申请（待审核）" name="all">
<el-tab-pane label="变更记录（已通过）" name="my">

优势：

✅ 标签名称更明确，用户一眼就能看出数据范围
✅ 符合业务逻辑，避免混淆

2. 修改查询逻辑（核心）

修改位置：第 701-718 行

// 修改前（错误）
const getList = async () => {
  state.loading = true;
  try {
    const response = await listItineraryChange(state.queryParams);
    state.changeList = response.rows;
    state.total = response.total;
  } catch (error) {
    console.error('获取变更行程列表失败:', error);
  } finally {
    state.loading = false;
  }
};

// 修改后（正确）
const getList = async () => {
  state.loading = true;
  try {
    // 如果用户没有手动选择状态，默认只显示待审核的申请
    const params = { ...state.queryParams };
    if (!params.status) {
      params.status = '0'; // 默认只显示待审核状态
    }
    const response = await listItineraryChange(params);
    state.changeList = response.rows;
    state.total = response.total;
  } catch (error) {
    console.error('获取变更行程列表失败:', error);
  } finally {
    state.loading = false;
  }
};

核心逻辑：

✅ 当用户未选择状态时，默认 status='0'（待审核）
✅ 用户可以手动选择其他状态进行筛选
✅ 符合业务需求：变更申请默认只显示待审核数据

🔄 业务流程说明

完整流程

1️⃣ 用户提交变更申请
   ↓
   状态：待审核（status=0）
   显示位置：变更申请（待审核）选项卡
   ↓
2️⃣ 审批人审批
   ↓
   ├── 审批通过 → 状态：已通过（status=1）
   │   显示位置：变更记录（已通过）选项卡 ✅
   │
   └── 审批拒绝 → 状态：已拒绝（status=2）
       显示位置：变更申请（待审核）选项卡
       可操作：重新提交或删除

数据流转规则

状态	状态值	显示选项卡	可见按钮
待审核	0	变更申请（待审核）	查看、变更历史、撤回、删除
已通过	1	变更记录（已通过）	查看、变更历史
已拒绝	2	变更申请（待审核）*	查看、变更历史、重新提交、删除

注意：

已拒绝的数据默认不显示在"变更申请"中，需要手动选择状态="已拒绝"才能查看
用户可以通过搜索条件中的"变更状态"下拉框筛选不同状态的数据

📊 状态字典数据

rs_itinerary_change_status

字典值	字典标签	说明
0	待审核	刚提交的申请，等待审批
1	已通过	审批通过，变更生效
2	已拒绝	审批拒绝，需要重新提交
3	已撤回	用户主动撤回申请

🎯 用户体验优化

优化前 vs 优化后

优化前：

❌ 打开"变更申请"选项卡：显示所有状态的数据（混乱）
❌ 待审核和已通过的数据混在一起
❌ 用户需要手动筛选才能看到待审核的申请

优化后：

✅ 打开"变更申请（待审核）"选项卡：只显示待审核的数据（清晰）
✅ 打开"变更记录（已通过）"选项卡：只显示已通过的数据（明确）
✅ 数据自动分类，用户体验更好

搜索功能

变更申请（待审核）选项卡：

默认显示：待审核（status=0）
可选状态：待审核、已通过、已拒绝（支持手动筛选）
其他搜索条件：申请人姓名、目的地国家

变更记录（已通过）选项卡：

默认显示：已通过（status=1）
后端强制过滤：只返回已通过的数据
其他搜索条件：目的地国家

🚀 测试验证

验证步骤

步骤1：重启前端（1分钟）

操作：

# 在 web 目录下
npm run dev

等待：

  ➜  Local:   http://localhost/
  ➜  ready in xxx ms

步骤2：打开浏览器测试（2分钟）

操作：

访问：http://localhost
登录系统
进入：人事管理 → 出国行程变更申请
查看两个选项卡

预期结果：

**变更申请（待审核）**选项卡：

✅ 默认只显示状态="待审核"的数据
✅ 如果没有待审核数据，显示空列表
✅ 可以手动选择其他状态进行筛选

**变更记录（已通过）**选项卡：

✅ 只显示状态="已通过"的数据
✅ 如果没有已通过数据，显示空列表
✅ 搜索条件中没有"申请人"字段（因为是当前登录用户的记录）

步骤3：测试数据流转（3分钟）

创建测试数据（如果需要）：

-- 插入一条待审核的变更申请
INSERT INTO rs_overseas_itinerary_change (
    change_id, record_id, application_id, applicant_id, applicant_name,
    department, original_destination, new_destination,
    original_start_date, original_end_date, new_start_date, new_end_date,
    change_reason, status, tenant_id, deleted, create_time, create_by
) VALUES (
    1848100000000000000,  -- 变更申请ID
    1848000000000000001,  -- 出国记录ID（需要是真实存在的recordId）
    1847000000000000001,  -- 原出国申请ID
    1,                    -- 申请人ID（当前登录用户ID）
    '测试用户',           -- 申请人姓名
    '测试部门',           -- 部门
    '美国',               -- 原目的地
    '英国',               -- 新目的地
    '2025-01-01',         -- 原开始日期
    '2025-01-10',         -- 原结束日期
    '2025-01-05',         -- 新开始日期
    '2025-01-15',         -- 新结束日期
    '因公务需要调整行程', -- 变更原因
    '0',                  -- 待审核状态
    '000000',             -- 租户ID
    0,                    -- 未删除
    NOW(),                -- 创建时间
    1                     -- 创建人ID
);

测试流程：

查看变更申请选项卡
- ✅ 应该看到刚插入的待审核数据
审批通过（在审批页面操作）
- 进入：人事管理 → 出国行程变更审批
- 找到待审批记录
- 点击"通过"
回到变更申请页面
- **变更申请（待审核）**选项卡：
  - ✅ 刚才的数据消失了（因为状态变为已通过）
- **变更记录（已通过）**选项卡：
  - ✅ 刚才的数据出现了（因为是已通过状态）

说明：

✅ 数据自动流转，符合业务逻辑
✅ 已通过的数据只在"变更记录"中显示

📝 后端API说明

后端Service实现

文件位置：

backend/ruoyi-modules/ruoyi-rs/src/main/java/org/dromara/rs/service/impl/RsOverseasItineraryChangeServiceImpl.java

核心方法：

/**
 * 查询我的变更记录列表（当前登录用户的已通过变更申请）
 * 说明：变更记录Tab只显示已通过审批的变更申请，这些是真正生效的变更记录
 */
@Override
public TableDataInfo<RsOverseasItineraryChangeVo> queryMyChangeList(RsOverseasItineraryChangeQuery query) {
    Long userId = LoginHelper.getUserId();
    query.setApplicantId(userId);
    query.setStatus("1"); // 只查询已通过的变更申请
    return queryPageList(query);
}

说明：

✅ 后端强制设置 status='1'
✅ 前端无需传递 status 参数
✅ 保证"变更记录"选项卡只显示已通过的数据

🎯 总结

修复内容

✅ 选项卡标签优化
- 变更申请 → 变更申请（待审核）
- 变更记录 → 变更记录（已通过）
✅ 查询逻辑优化
- 变更申请：默认只显示待审核（status=0）
- 变更记录：强制只显示已通过（status=1）
✅ 业务流程明确
- 待审核 → 变更申请选项卡
- 已通过 → 自动流转到变更记录选项卡
- 已拒绝 → 需要手动筛选才能看到

优化效果

✅ 业务逻辑清晰：数据自动分类，符合业务流程
✅ 用户体验提升：一眼就能看到待处理的申请
✅ 数据流转明确：已通过的数据自动流转到变更记录

🚀 立即执行

操作步骤

1️⃣ 重启前端

cd web
npm run dev

2️⃣ 测试验证

打开浏览器：http://localhost
进入：人事管理 → 出国行程变更申请
查看两个选项卡的数据

3️⃣ 验证业务流程

提交一条变更申请 → 应该出现在"变更申请（待审核）"
审批通过后 → 应该自动流转到"变更记录（已通过）"

修复完成时间：2025-10-14 00:50
修复内容：业务逻辑优化，选项卡数据分类
影响范围：前端查询逻辑，不影响后端

🎯 现在就重启前端验证效果吧！ 🚀

10 KiB Raw Blame History Unescape Escape