363 lines
10 KiB
Markdown
363 lines
10 KiB
Markdown
# 🎯 业务逻辑优化 - 行程变更选项卡
|
||
|
||
## 📋 优化内容
|
||
|
||
### 问题描述
|
||
|
||
**原有问题**：
|
||
- ❌ "变更申请"选项卡显示**所有状态**的数据（待审核、已通过、已拒绝）
|
||
- ❌ 已通过的数据出现在两个选项卡中（既在变更申请，又在变更记录）
|
||
- ❌ 业务逻辑不清晰，用户体验不佳
|
||
|
||
**正确的业务逻辑**：
|
||
- ✅ **变更申请**选项卡：只显示**待审核（status=0）**的数据
|
||
- ✅ **变更记录**选项卡：只显示**已通过（status=1）**的数据
|
||
- ✅ 已通过的数据会自动从"变更申请"流转到"变更记录"
|
||
|
||
---
|
||
|
||
## ✅ 修复内容
|
||
|
||
### 修改文件
|
||
|
||
**文件路径**：
|
||
```
|
||
web/src/views/rs/overseas/itinerary-change.vue
|
||
```
|
||
|
||
### 修改详情
|
||
|
||
#### 1. 更新选项卡标签（更清晰）
|
||
|
||
**修改位置**：第 8 行和第 121 行
|
||
|
||
```vue
|
||
<!-- 修改前 -->
|
||
<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 行
|
||
|
||
```typescript
|
||
// 修改前（错误）
|
||
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分钟）
|
||
|
||
**操作**：
|
||
```bash
|
||
# 在 web 目录下
|
||
npm run dev
|
||
```
|
||
|
||
**等待**：
|
||
```
|
||
➜ Local: http://localhost/
|
||
➜ ready in xxx ms
|
||
```
|
||
|
||
#### 步骤2：打开浏览器测试（2分钟）
|
||
|
||
**操作**：
|
||
1. 访问：http://localhost
|
||
2. 登录系统
|
||
3. 进入：**人事管理** → **出国行程变更申请**
|
||
4. 查看两个选项卡
|
||
|
||
**预期结果**：
|
||
|
||
**变更申请（待审核）**选项卡：
|
||
- ✅ 默认只显示状态="待审核"的数据
|
||
- ✅ 如果没有待审核数据，显示空列表
|
||
- ✅ 可以手动选择其他状态进行筛选
|
||
|
||
**变更记录（已通过）**选项卡：
|
||
- ✅ 只显示状态="已通过"的数据
|
||
- ✅ 如果没有已通过数据，显示空列表
|
||
- ✅ 搜索条件中没有"申请人"字段（因为是当前登录用户的记录）
|
||
|
||
#### 步骤3：测试数据流转（3分钟）
|
||
|
||
**创建测试数据**（如果需要）：
|
||
|
||
```sql
|
||
-- 插入一条待审核的变更申请
|
||
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
|
||
);
|
||
```
|
||
|
||
**测试流程**：
|
||
|
||
1. **查看变更申请选项卡**
|
||
- ✅ 应该看到刚插入的待审核数据
|
||
|
||
2. **审批通过**（在审批页面操作）
|
||
- 进入：人事管理 → 出国行程变更审批
|
||
- 找到待审批记录
|
||
- 点击"通过"
|
||
|
||
3. **回到变更申请页面**
|
||
- **变更申请（待审核）**选项卡：
|
||
- ✅ 刚才的数据**消失**了（因为状态变为已通过）
|
||
- **变更记录（已通过）**选项卡：
|
||
- ✅ 刚才的数据**出现**了（因为是已通过状态）
|
||
|
||
**说明**：
|
||
- ✅ 数据自动流转，符合业务逻辑
|
||
- ✅ 已通过的数据只在"变更记录"中显示
|
||
|
||
---
|
||
|
||
## 📝 后端API说明
|
||
|
||
### 相关API接口
|
||
|
||
**查询变更申请列表**：
|
||
```
|
||
GET /rs/itinerary/change/list
|
||
参数：status (可选，0=待审核, 1=已通过, 2=已拒绝)
|
||
```
|
||
|
||
**查询我的变更记录列表**：
|
||
```
|
||
GET /rs/itinerary/change/my/list
|
||
说明：后端强制 status='1'，只返回已通过的数据
|
||
```
|
||
|
||
### 后端Service实现
|
||
|
||
**文件位置**：
|
||
```
|
||
backend/ruoyi-modules/ruoyi-rs/src/main/java/org/dromara/rs/service/impl/RsOverseasItineraryChangeServiceImpl.java
|
||
```
|
||
|
||
**核心方法**：
|
||
|
||
```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 参数
|
||
- ✅ 保证"变更记录"选项卡只显示已通过的数据
|
||
|
||
---
|
||
|
||
## 🎯 总结
|
||
|
||
### 修复内容
|
||
|
||
1. ✅ **选项卡标签优化**
|
||
- 变更申请 → 变更申请（待审核）
|
||
- 变更记录 → 变更记录（已通过）
|
||
|
||
2. ✅ **查询逻辑优化**
|
||
- 变更申请：默认只显示待审核（status=0）
|
||
- 变更记录：强制只显示已通过（status=1）
|
||
|
||
3. ✅ **业务流程明确**
|
||
- 待审核 → 变更申请选项卡
|
||
- 已通过 → 自动流转到变更记录选项卡
|
||
- 已拒绝 → 需要手动筛选才能看到
|
||
|
||
### 优化效果
|
||
|
||
- ✅ **业务逻辑清晰**：数据自动分类，符合业务流程
|
||
- ✅ **用户体验提升**：一眼就能看到待处理的申请
|
||
- ✅ **数据流转明确**：已通过的数据自动流转到变更记录
|
||
|
||
---
|
||
|
||
## 🚀 立即执行
|
||
|
||
### 操作步骤
|
||
|
||
1️⃣ **重启前端**
|
||
```bash
|
||
cd web
|
||
npm run dev
|
||
```
|
||
|
||
2️⃣ **测试验证**
|
||
- 打开浏览器：http://localhost
|
||
- 进入：人事管理 → 出国行程变更申请
|
||
- 查看两个选项卡的数据
|
||
|
||
3️⃣ **验证业务流程**
|
||
- 提交一条变更申请 → 应该出现在"变更申请（待审核）"
|
||
- 审批通过后 → 应该自动流转到"变更记录（已通过）"
|
||
|
||
---
|
||
|
||
**修复完成时间**：2025-10-14 00:50
|
||
**修复内容**：业务逻辑优化，选项卡数据分类
|
||
**影响范围**：前端查询逻辑，不影响后端
|
||
|
||
---
|
||
|
||
**🎯 现在就重启前端验证效果吧！** 🚀
|
||
|
||
|