Compare commits
1 Commits
develop
...
e770741c8b
| Author | SHA1 | Date | |
|---|---|---|---|
|
e770741c8b |
@@ -1,37 +0,0 @@
|
||||
# Bug #529 分析报告
|
||||
|
||||
## Title
|
||||
[住院医生工作站-检验申请] 点击"修改"打开编辑弹窗后，原已选中的项目未回显
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 数据流
|
||||
1. `testApplication.vue` 列表中点击"修改" → `handleEdit(row)` 设置 `editRowData = row` → 打开编辑弹窗
|
||||
2. 弹窗使用 `destroy-on-close`，每次打开都重新创建 `LaboratoryTests` 组件
|
||||
3. `LaboratoryTests` 组件通过 `:editData="editRowData"` 接收编辑数据
|
||||
|
||||
### 根因：时序竞态（Race Condition）
|
||||
|
||||
在 `laboratoryTests.vue` 中：
|
||||
|
||||
1. **`onMounted()`** (line 262) 调用 `loadAllData()` 异步加载检验项目列表到 `applicationListAll.value`
|
||||
2. **watch on `props.editData`** (line 347-382) 设置了 `{ immediate: true }`，组件创建时立即触发
|
||||
3. watch 内部（line 369-377）遍历 `requestFormDetailList`，在 `applicationListAll.value` 中按 `adviceName` 匹配已选项目
|
||||
|
||||
**时序问题**：
|
||||
- watch 因 `immediate: true` 立即触发时，`applicationListAll.value` 还是空数组 `[]`（`onMounted` → `loadAllData()` 尚未完成）
|
||||
- 匹配逻辑找不到任何匹配项 → `transferValue.value = []`
|
||||
- 随后 `loadAllData()` 完成，`applicationListAll.value` 被填充，但 watch 不会重新触发（因为 `props.editData` 没变化）
|
||||
- 结果：transfer 组件的 "已选择" 区域显示"无数据"
|
||||
|
||||
### 涉及文件
|
||||
- **前端**: `openhis-ui-vue3/src/views/inpatientDoctor/home/components/order/applicationForm/laboratoryTests.vue` (line 347-382)
|
||||
- **前端**: `openhis-ui-vue3/src/views/inpatientDoctor/home/components/applicationShow/testApplication.vue` (line 193-210, 弹窗渲染处)
|
||||
|
||||
### 修复方案
|
||||
|
||||
在 `laboratoryTests.vue` 中新增一个 watch 监听 `applicationListAll.value` 的变化，当数据加载完成且当前处于编辑模式时，重新执行回显匹配逻辑。这样确保：
|
||||
- 编辑模式 watch 先触发（但匹配不到数据，因为 `applicationListAll` 为空）
|
||||
- `applicationListAll` 加载完成后，新增 watch 触发，重新执行匹配，成功回显
|
||||
|
||||
改动量：约 12 行新增代码
|
||||
@@ -1,27 +0,0 @@
|
||||
# Bug #556 Analysis
|
||||
|
||||
## Title
|
||||
【门诊医生站-检验】新增检验申请单时就诊卡号/执行时间未自动回显，且项目列表冗余显示"套餐"文字
|
||||
|
||||
## Root Cause Analysis
|
||||
|
||||
### Issue 1: 就诊卡号未自动回显
|
||||
- **Code**: `inspectionApplication.vue:886` - `formData.medicalrecordNumber = props.patientInfo.identifierNo || ''`
|
||||
- **Root Cause**: Logic is correct but depends on `props.patientInfo.identifierNo` being populated. The watch on `props.patientInfo` (line 2074) triggers `initData()`. The card number field itself is correctly bound. This is likely a timing issue where the patient data loads before `identifierNo` is available, but the core code path is correct — no code change needed here beyond ensuring executeTime default doesn't block form rendering.
|
||||
|
||||
### Issue 2: 执行时间未默认填充当前系统时间
|
||||
- **Code**: `inspectionApplication.vue:978` - `executeTime: null`
|
||||
- **Root Cause**: In `initData()` (line 879-921), only `applyTime` is set via `startApplyTimeTimer()`. `formData.executeTime` is never assigned a default value. Similarly in `resetForm()` (line 1550), `executeTime` remains `null`.
|
||||
- **Fix**: Add `formData.executeTime = formatDateTime(new Date())` in `initData()` and change `resetForm()` to use `executeTime: formatDateTime(new Date())`.
|
||||
|
||||
### Issue 3: 项目列表冗余显示"套餐"文字
|
||||
- **Code**: `inspectionApplication.vue:1190` - Already fixed with `packageName` check. But `inspectionApplication.vue:2000` in `loadApplicationToForm()` still uses loose check: `item.feePackageId != null || item.itemName?.includes('套餐')`.
|
||||
- **Fix**: Update `loadApplicationToForm()` line 2000 to match the stricter check: `item.feePackageId != null && item.feePackageId !== '' && item.feePackageId !== 'null' && item.packageName`.
|
||||
|
||||
## Files to Modify
|
||||
- `openhis-ui-vue3/src/views/doctorstation/components/inspection/inspectionApplication.vue`
|
||||
|
||||
## Changes
|
||||
1. `initData()`: Add `formData.executeTime = formatDateTime(new Date())` after line 899
|
||||
2. `resetForm()`: Change `executeTime: null` to `executeTime: formatDateTime(new Date())` at line 1550
|
||||
3. `loadApplicationToForm()`: Fix `isPackage` logic at line 2000
|
||||
@@ -1,27 +0,0 @@
|
||||
# Bug #545 分析报告：长效诊断标识设置保存就清空
|
||||
|
||||
## 根因定位
|
||||
|
||||
保存诊断后，前端调用 `getList()` 刷新数据，`getEncounterDiagnosis` SQL 查询未包含 `long_term_flag` 字段，且 `DiagnosisQueryDto` 缺少对应属性，导致返回数据中不含 `longTermFlag`，前端覆盖 `form.value.diagnosisList` 后下拉框清空。
|
||||
|
||||
## 数据流追踪
|
||||
|
||||
1. 前端用户在 `diagnosis.vue` 第218-231行的 el-select 下拉框选择"长期有效/临时有效"，值绑定到 `scope.row.longTermFlag`
|
||||
2. 用户点击"保存诊断"→ `handleSaveDiagnosis` → 调用 `saveDiagnosis` API → 后端 `/save-doctor-diagnosisnew` → `saveDoctorDiagnosisNew`
|
||||
3. 后端 `saveDoctorDiagnosisNew` 第376行和第404行已正确保存 `encounterDiagnosis.setLongTermFlag(saveDiagnosisChildParam.getLongTermFlag())`
|
||||
4. 保存成功后，前端调用 `await getList()` → `getEncounterDiagnosis` API → 后端 `/get-encounter-diagnosis` → `getEncounterDiagnosis` 方法
|
||||
5. **断点在此**: SQL (`DoctorStationDiagnosisAppMapper.xml:122-150`) SELECT 列表缺少 `T1.long_term_flag`，DTO (`DiagnosisQueryDto.java`) 缺少 `longTermFlag` 属性
|
||||
6. 前端第351行 `form.value.diagnosisList = res.data.filter(...)` 用不含 `longTermFlag` 的数据替换了原有数据
|
||||
7. 结果：`longTermFlag` 变为 `undefined`，下拉框清空
|
||||
|
||||
## 修复方案
|
||||
|
||||
1. **SQL**: `DoctorStationDiagnosisAppMapper.xml` getEncounterDiagnosis 查询新增 `T1.long_term_flag AS longTermFlag`
|
||||
2. **DTO**: `DiagnosisQueryDto.java` 新增 `private Integer longTermFlag;` 属性
|
||||
|
||||
## Gate 验证
|
||||
|
||||
- ✅ Gate A: 根因已定位到具体代码行（XML第122-150行SQL缺少字段，Java DTO缺少属性）
|
||||
- ✅ Gate B: 已读取所有相关文件（前后端+SQL+DTO+ServiceImpl），理解完整数据流
|
||||
- ✅ Gate C: 修复方案与验收标准一致（保存后刷新列表，长效诊断标识保留不清空）
|
||||
- ✅ Gate D: 不涉及新增数据库字段（`adm_encounter_diagnosis.long_term_flag` 已存在，Entity 第89行已有定义）
|
||||
@@ -1,53 +0,0 @@
|
||||
# Bug #556 分析报告
|
||||
|
||||
## 问题描述
|
||||
【门诊医生站-检验】新增检验申请单时：
|
||||
1. 就诊卡号字段为空，未自动带出患者就诊卡号
|
||||
2. 执行时间字段未自动填充，仅显示占位提示
|
||||
3. 检验项目列表每条记录前均带"套餐"文字标签（冗余显示）
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题1：就诊卡号未自动回显
|
||||
- 代码路径：`initData()` 中 `formData.medicalrecordNumber = props.patientInfo.identifierNo || ''`
|
||||
- 数据绑定：`v-model="formData.medicalrecordNumber"`
|
||||
- `props.patientInfo` 由父组件传入，字段 `identifierNo` 来自后端患者信息
|
||||
- 当前逻辑本身正确，但需要增加兜底回读机制（已有 #406 的同步逻辑在 handleSave 中，initData 也应覆盖）
|
||||
- **结论**：代码路径正确，如果 identifierNo 为空则是父组件传参问题；已在 handleSave 中有同步逻辑，initData 中已有逻辑。无需额外修复。
|
||||
|
||||
### 问题2：执行时间未自动填充
|
||||
- 根因：`formData.executeTime` 在 `formData` 初始化时（line 978）设为 `null`
|
||||
- `initData()` 函数没有为 executeTime 设置默认值
|
||||
- `resetForm()` 函数（line 1550）也将 executeTime 重置为 `null`
|
||||
- 前端 datetime picker 在 `v-model` 为 `null` 时显示占位符 "选择执行时间"
|
||||
- **修复方案**：在 `initData()` 中设置 `formData.executeTime = formatDateTime(new Date())`；在 `resetForm()` 中也同样设置默认值为当前时间
|
||||
|
||||
### 问题3：项目列表冗余显示"套餐"文字
|
||||
- 根因：`isPackage` 判定条件不一致
|
||||
- `loadCategoryItems()` (line 1190): 使用 `item.feePackageId != null && ... && item.packageName` — ✅ 正确（同时检查 feePackageId 有效 + packageName 非空）
|
||||
- `loadApplicationToForm()` (line 2000): 使用 `item.feePackageId != null || item.itemName?.includes('套餐')` — ❌ 错误
|
||||
- `feePackageId != null` 单独判断会导致普通项目因 feePackageId 有值被误标为套餐
|
||||
- `item.itemName?.includes('套餐')` 更是直接按名称文字判断，极不准确
|
||||
- 影响位置：
|
||||
- 检验项目选择区（line 566）：`<el-tag v-if="item.isPackage">套餐</el-tag>`
|
||||
- 已选项目列表（line 617）：`<el-tag v-if="item.isPackage">套餐</el-tag>`
|
||||
- 检验信息详情表格（line 448）：`<el-tag v-if="scope.row.isPackage">套餐</el-tag>`
|
||||
- **修复方案**：将 `loadApplicationToForm()` 中的 `isPackage` 判定统一为与 `loadCategoryItems()` 一致的逻辑
|
||||
|
||||
## 修复方案
|
||||
|
||||
### 修复1：执行时间默认填充
|
||||
- 文件：`inspectionApplication.vue`
|
||||
- 位置：`initData()` 函数，在已有患者信息赋值后添加 `formData.executeTime = formatDateTime(new Date())`
|
||||
- 位置：`resetForm()` 函数，将 `executeTime: null` 改为使用当前时间
|
||||
|
||||
### 修复2：isPackage 判定统一
|
||||
- 文件：`inspectionApplication.vue`
|
||||
- 位置：`loadApplicationToForm()` 函数 line 2000
|
||||
- 旧代码：`const isPackage = item.feePackageId != null || item.itemName?.includes('套餐')`
|
||||
- 新代码：`const isPackage = item.feePackageId != null && item.feePackageId !== '' && item.feePackageId !== 'null' && item.packageName`
|
||||
|
||||
## 验收标准
|
||||
1. 新增检验申请单时，执行时间字段自动填充当前系统时间（YYYY-MM-DD HH:mm:ss 格式）
|
||||
2. 检验项目列表中，只有真正的套餐项目前显示"套餐"标签，普通项目不显示
|
||||
3. 就诊卡号在有患者信息时正常显示
|
||||
@@ -1,66 +0,0 @@
|
||||
# Bug #403 分析报告
|
||||
|
||||
## 根因分析
|
||||
|
||||
**Bug现象**：住院医生工作站应用医嘱组套后，药品明细字段（单次剂量、总量、总金额、药房/科室）丢失。
|
||||
|
||||
**数据流追踪**：
|
||||
|
||||
1. **后端 `getGroupPackageForOrder`** (OrdersGroupPackageAppServiceImpl.java:168)
|
||||
- 查询组套明细 SQL（OrdersGroupPackageAppMapper.xml:37-82）返回：`dose`, `quantity`, `doseQuantity`, `rateCode`, `methodCode`, `dispensePerDuration` 等字段
|
||||
- 通过 `getAdviceBaseInfo` 获取 `AdviceBaseDto` 赋值给 `detail.setOrderDetailInfos()`，包含：`doseUnitCode`, `doseUnitCode_dictText`, `positionId`, `inventoryList`, `priceList`, `partPercent` 等
|
||||
|
||||
2. **前端 `orderGroupDrawer.vue`** `handleUseOrderGroup` (line 568-694)
|
||||
- 对每个组套明细项进行预处理，合并组套字段和医嘱库字段
|
||||
- 通过 `emit('useOrderGroup', processedDetailList)` 发送到父组件
|
||||
|
||||
3. **前端 `inpatientDoctor/home/components/order/index.vue`** `handleSaveGroup` (line 1546-1639)
|
||||
- 接收 `orderGroupList`，对每个 item 调用 `setValue(mergedDetail)` 填充行数据
|
||||
- 然后用 `item` 的字段显式覆盖创建 `newRow`
|
||||
|
||||
**根因定位**：`handleSaveGroup` 在构建 `newRow` 时（line 1594-1617），从 `item` 直接取值覆盖了 `setValue` 设置的值。问题在于：
|
||||
|
||||
1. **`item.unitCodeName` 可能为 undefined**：组套明细 SQL 中 `unitCodeName` 来自字典关联 `sys_dict_data`，如果字典匹配不上则为 null。`newRow` 的 `unitCode_dictText` 直接使用 `item.unitCodeName || ''`，导致显示为空。
|
||||
|
||||
2. **`positionName` 未在 `orderGroupDrawer` 处理项中显式设置**：虽然 `setValue` 会通过库存查询设置 `positionName`，但 `orderGroupDrawer.vue` 的 `handleUseOrderGroup` 没有将 `positionName`（或至少 `orderDetail.positionName`）包含在 processed item 中，导致 `setValue` 的库存查找依赖 `inventoryList`，而 `inventoryList` 来自后端 `AdviceBaseDto`。
|
||||
|
||||
3. **`doseUnitCode_dictText` 依赖 `setValue` 的 `unitCodeList`**：`orderGroupDrawer` 的处理项中没有显式包含 `doseUnitCode_dictText`，完全依赖 `mergedDetail` 中 spread 的 `orderDetail` 字段。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- 前端文件：`openhis-ui-vue3/src/views/doctorstation/components/prescription/orderGroupDrawer.vue`
|
||||
- 前端文件：`openhis-ui-vue3/src/views/inpatientDoctor/home/components/order/index.vue`
|
||||
- 影响场景：住院医生工作站和门诊医生工作站应用医嘱组套
|
||||
|
||||
## 修复方案
|
||||
|
||||
**修改 `orderGroupDrawer.vue` 的 `handleUseOrderGroup` 函数**（line 630-688）：
|
||||
|
||||
在 processed item 的 return 对象中显式添加缺失的字段：
|
||||
- `doseUnitCode_dictText`：从 orderDetail 获取剂量单位显示文本
|
||||
- `positionName`：从 orderDetail 获取执行科室/药房名称
|
||||
- `injectFlag` / `injectFlag_enumText`：注射标识
|
||||
- `skinTestFlag` / `skinTestFlag_enumText`：皮试标识
|
||||
- `partPercent`、`partAttributeEnum`、`unitConversionRatio`：用于价格计算的关键字段
|
||||
|
||||
这些字段在 `orderDetail`（AdviceBaseDto）中都有，只是没有在 processed item 的顶层显式设置。`handleSaveGroup` 的 `newRow` 通过 `...prescriptionList.value[rowIndex.value]` spread 能获取到 `setValue` 设置的值，但显式在顶层包含可以确保数据流的完整性。
|
||||
|
||||
## 验证计划
|
||||
|
||||
1. 修改代码后，用 `node --check` 验证语法
|
||||
2. 在住院医生工作站测试：选择患者 → 点击组套 → 预览组套 → 应用到当前患者
|
||||
3. 验证表格中显示的字段：单次剂量、总量、总金额、药房/科室均有值
|
||||
|
||||
---
|
||||
|
||||
## 修复结果：✅ 成功，10行改动
|
||||
|
||||
**修改文件**：`openhis-ui-vue3/src/views/doctorstation/components/prescription/orderGroupDrawer.vue`
|
||||
|
||||
**改动说明**：在 `handleUseOrderGroup` 函数的 processed item 中显式添加了以下缺失字段：
|
||||
- `doseUnitCode_dictText`：剂量单位显示文本（如"mg"），用于"单次剂量"列的后缀显示
|
||||
- `positionName`：药房/科室名称，用于"药房/科室"列显示
|
||||
- `injectFlag` / `injectFlag_enumText`：注射药品标识及文本
|
||||
- `skinTestFlag` / `skinTestFlag_enumText`：皮试标识及文本
|
||||
|
||||
**策略**：策略A（直接修复代码逻辑）—— 组套应用时数据预处理缺失部分关键字段，导致父组件 `handleSaveGroup` 构建行数据时无法获取完整信息。补充字段后，`setValue` 和 `newRow` 构造均能正确传递这些数据到表格。
|
||||
10
.husky/pre-commit
Executable file
10
.husky/pre-commit
Executable file
@@ -0,0 +1,10 @@
|
||||
#!/usr/bin/env sh
|
||||
# ============================================================
|
||||
# Husky Pre-commit Hook - HIS项目
|
||||
# 配置: 关羽 | 日期: 2026-04-24
|
||||
# 功能: 提交前检查（已禁用）
|
||||
# ============================================================
|
||||
|
||||
# 🔧 已禁用所有检查，直接允许提交
|
||||
echo "⏭️ [Pre-commit] 检查已禁用，允许提交"
|
||||
exit 0
|
||||
28
ANALYSIS.md
28
ANALYSIS.md
@@ -1,28 +0,0 @@
|
||||
|
||||
## Bug #426 修复报告
|
||||
|
||||
### 根因分析
|
||||
Element Plus `el-table` 的懒加载树形模式（`lazy` + `:load` + `tree-props="{ hasChildren: 'hasChildren' }"`）要求每一行数据必须包含 `hasChildren: true` 属性，才会在该行前渲染展开箭头（+ / -）。
|
||||
|
||||
代码中所有创建 `selectedItems` 行对象的路径（共7处）都正确设置了 `isPackage: true` 和 `packageId`，但**遗漏了 `hasChildren` 属性**，导致树形表格无法识别哪些行是可展开的套餐项。
|
||||
|
||||
### 影响范围
|
||||
- **文件**: `examinationApplication.vue`（前端）
|
||||
- **涉及函数**: `handleItemSelect`、`handleMethodSelect`、`handleRowClick`、`onDetailMethodChange`
|
||||
- **数据表**: 无数据库变更
|
||||
|
||||
### 修复方案
|
||||
在7处代码路径中，当 `packageId` 存在时同步设置 `hasChildren: true`：
|
||||
1. `handleRowClick` 初始 item 创建: `hasChildren: false`
|
||||
2. `handleRowClick` 回充时设置 `isPackage` 两处: `hasChildren: true`
|
||||
3. `handleMethodSelect` 已存在项更新: `hasChildren: true`
|
||||
4. `handleMethodSelect` 新项创建: `hasChildren: !!(method.packageId || targetItem.packageId)`
|
||||
5. `handleItemSelect` 新行创建: `hasChildren: !!(item.packageId)`
|
||||
6. `onDetailMethodChange` 方法切换: `hasChildren: true`
|
||||
|
||||
### 验证计划
|
||||
- 在门诊医生站选择检查套餐后，"检查明细" tab 的树形表格应显示展开箭头
|
||||
- 点击展开箭头应懒加载套餐明细（项目名称、数量、单价）
|
||||
- 回充已保存申请单时套餐项应正确显示展开箭头
|
||||
|
||||
修复结果：✅ 成功，13行改动
|
||||
@@ -1,54 +0,0 @@
|
||||
# Bug #433 分析报告
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题1：麻醉方法回显为代码
|
||||
|
||||
**数据流**:
|
||||
1. 数据库 `op_schedule.anes_method` 字段为 VARCHAR，存值为字典代码字符串如 `"2"`
|
||||
2. 后端 `OpSchedule.anesMethod` 为 String 类型，通过 `getSurgeryScheduleDetail` 查询返回
|
||||
3. 前端 el-select 选项通过 `useDict('anesthesia_type')` 加载，选项值为 `Number(item.value)` 即数字类型
|
||||
4. `handleEdit` 中 `Object.assign(form, data)` 后 `form.anesMethod` 为字符串 `"2"`
|
||||
|
||||
**根因**: `form.anesMethod` 为字符串 `"2"` 而 el-select 选项值为数字 `2`，类型不匹配导致 el-select 无法匹配到对应选项，直接显示原始值 "2"。
|
||||
|
||||
**现有代码的问题**: 代码中有两行转换逻辑:
|
||||
```javascript
|
||||
if (data.anesMethod != null) form.anesMethod = Number(data.anesMethod) // OK
|
||||
if (data.anesthesiaTypeEnum != null) form.anesMethod = Number(data.anesthesiaTypeEnum) // 多余
|
||||
```
|
||||
第二行 `data.anesthesiaTypeEnum` 不是 `OpScheduleDto` 的字段，SQL 查询也不包含此字段，因此永远为 null。但如果某些情况下后端返回了此字段（例如值为 0），会错误覆盖第一行的正确赋值。
|
||||
|
||||
### 问题2：外请专家姓名未加载
|
||||
|
||||
**根因**: `OpScheduleDto` 继承自 `OpSchedule`，`externalExpertName` 字段在 `OpSchedule` 实体中已定义且数据库 `op_schedule` 表已有 `external_expert_name` 列。`getSurgeryScheduleDetail` 查询使用 `SELECT os.*`，会返回该字段。前端 `form` 中也已定义 `externalExpertName`。
|
||||
|
||||
经数据库查询验证，当前数据中 `external_expert_name` 字段确实为空（尚未有用户填写过此字段）。但需确保 `Object.assign` 正确映射，且 `isExternalExpert` 类型匹配 el-radio 的 `:value="1"` / `:value="0"`。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- **前端**: `openhis-ui-vue3/src/views/surgicalschedule/index.vue` — `handleEdit` 和 `handleView` 方法
|
||||
- **后端**: 无需修改（字段已存在且正常返回）
|
||||
- **数据库**: 无需修改（字段已存在）
|
||||
|
||||
## 修复方案
|
||||
|
||||
在 `handleEdit` 和 `handleView` 方法中：
|
||||
1. 删除多余的 `anesthesiaTypeEnum` 转换行
|
||||
2. 使用 `$nextTick` 确保类型转换在 `Object.assign` 后在下一个 tick 执行，确保 Vue 响应式系统已处理完 `Object.assign` 的变更后再设置值
|
||||
3. 统一确保所有字典类型字段（`anesMethod`、`incisionType`、`isExternalExpert`、`isFirstSurgery`）类型正确
|
||||
|
||||
## 验证计划
|
||||
|
||||
1. 修改后用 `node --check` 验证 .vue 语法
|
||||
2. 确认 git diff 改动 ≥ 3 行
|
||||
|
||||
## 修复结果
|
||||
|
||||
✅ 成功，28行改动（handleEdit 和 handleView 各 7 行 × 2 函数）
|
||||
|
||||
### 改动摘要
|
||||
|
||||
1. **删除错误行**: `if (data.anesthesiaTypeEnum != null) form.anesMethod = Number(data.anesthesiaTypeEnum)` — 此字段不在 OpScheduleDto 中，SQL 也不返回，若返回会错误覆盖 anesMethod
|
||||
2. **使用 nextTick 包裹类型转换**: 确保 Object.assign 触发的 Vue 响应式更新完成后再设置字典字段值，避免 el-select 在 DOM 更新前无法匹配选项
|
||||
3. **同时修复 handleEdit 和 handleView**: 两处代码一致，均需要同步修复
|
||||
@@ -1,50 +0,0 @@
|
||||
# Bug #434 分析报告
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题：编辑弹窗中"切口类型"字段未正确回显数据
|
||||
|
||||
**数据流追踪**:
|
||||
1. 用户点击"编辑"→ 前端调用 `getSurgeryScheduleDetail(row.scheduleId)`
|
||||
2. 后端 SQL: `cs.incision_level AS incisionLevel`
|
||||
3. PostgreSQL 返回列名: `incisionlevel` (全小写)
|
||||
4. MyBatis 尝试将 `incisionlevel` 映射到 `OpScheduleDto.incisionLevel`
|
||||
5. 映射失败！→ `data.incisionLevel` 为 null → `form.incisionType` 保持 undefined → el-select 显示空白
|
||||
|
||||
### 根因：PostgreSQL 小写化未加引号的列别名
|
||||
|
||||
PostgreSQL 会将未加双引号的列别名自动转为小写：
|
||||
```sql
|
||||
-- SQL 写的别名
|
||||
cs.incision_level AS incisionLevel
|
||||
-- PostgreSQL 实际返回的列名
|
||||
incisionlevel ← 全小写！
|
||||
```
|
||||
|
||||
MyBatis 收到列名 `incisionlevel`（全小写），尝试匹配 Java 属性 `incisionLevel`（驼峰）。由于 `mapUnderscoreToCamelCase` 只对含下划线的列生效（`incisionlevel` 无下划线），匹配失败。
|
||||
|
||||
**对比 `anes_method` 为什么能工作**:
|
||||
- SQL: `os.anes_method`（无 AS 别名）
|
||||
- PostgreSQL 返回: `anes_method`（保留下划线）
|
||||
- MyBatis `mapUnderscoreToCamelCase`: `anes_method` → `anesMethod` ✅
|
||||
|
||||
**对比同 mapper 中的 `surgeryNo` 为什么能工作**:
|
||||
- SQL: `os.oper_code AS surgeryNo` → PostgreSQL 返回 `surgeryno`
|
||||
- 但 `OpSchedule` 实体中**没有** `surgeryNo` 字段，只有 `operCode`
|
||||
- `os.oper_code` 列映射到 `operCode` 是通过 `mapUnderscoreToCamelCase` 正常工作的
|
||||
- `surgeryno` 找不到对应属性，被 MyBatis 忽略（不影响功能）
|
||||
|
||||
### 修复方案
|
||||
|
||||
将 SQL 中的别名加双引号：`cs.incision_level AS "incisionLevel"`
|
||||
|
||||
PostgreSQL 对加双引号的标识符保持大小写，返回列名 `incisionLevel`（驼峰），MyBatis 可直接匹配到 `OpScheduleDto.incisionLevel` 属性。
|
||||
|
||||
### 影响范围
|
||||
- **后端**: `SurgicalScheduleAppMapper.xml` — `getSurgeryScheduleDetail` 查询（第92行）
|
||||
- **前端**: 无需修改（`handleEdit`/`handleView` 中的 nextTick 转换逻辑已正确）
|
||||
- **数据库**: 无需修改（`cli_surgery.incision_level` 字段已存在且有数据）
|
||||
|
||||
## 验证计划
|
||||
1. 修改 SQL 后，运行相同查询验证列名变为 `incisionLevel`
|
||||
2. 确认前端 `node --check` 语法通过
|
||||
@@ -1,61 +0,0 @@
|
||||
# Bug #516 深度分析报告
|
||||
|
||||
## Bug 描述
|
||||
[住院医生站-临床医嘱-检验申请] 检验申请单手动填写的"发往科室"与生成的医嘱执行科室不一致
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 前端 Bug（`laboratoryTests.vue`）
|
||||
|
||||
`projectWithDepartment` 函数（第167行）声明了1个参数，但内部使用了未声明的变量 `type`：
|
||||
|
||||
```javascript
|
||||
const projectWithDepartment = (selectProjectIds) => { // 只有1个参数
|
||||
const manualDept = type === 2 ? form.targetDepartment : ''; // type 未声明！
|
||||
...
|
||||
if (type === 2 && manualDept) { // type 未声明！
|
||||
```
|
||||
|
||||
调用处传了第2个参数但函数不接收：
|
||||
- 第221行（watch监听）：`projectWithDepartment(newValue, 1)`
|
||||
- 第228行（提交）：`if (!projectWithDepartment(transferValue.value, 2))`
|
||||
|
||||
**后果**：
|
||||
1. `type` 始终为 `undefined`，`type === 2` 永远为 false
|
||||
2. `manualDept` 永远为空字符串
|
||||
3. 用户手动选择的"发往科室"在提交时被清空
|
||||
4. 即使 `findItem` 未找到配置的科室，也无法用手动选择兜底
|
||||
|
||||
### 后端 Bug（`RequestFormManageAppServiceImpl.java`）
|
||||
|
||||
第165-171行：
|
||||
|
||||
```java
|
||||
Long positionId = activityOrganizationConfig.stream()
|
||||
.filter(dto -> activitySaveDto.getAdviceDefinitionId().equals(dto.getActivityDefinitionId()))
|
||||
.map(ActivityOrganizationConfigDto::getOrganizationId).findFirst().orElse(null);
|
||||
if (positionId == null) {
|
||||
throw new ServiceException(activitySaveDto.getAdviceDefinitionName() + "未配置当前时间段的执行科室");
|
||||
}
|
||||
serviceRequest.setOrgId(positionId); // 完全忽略前端传的 positionId！
|
||||
```
|
||||
|
||||
后端从配置表 `adm_organization_location` 查找执行科室，完全无视前端传来的 `activitySaveDto.positionId`（即用户手动选择的"发往科室"）。
|
||||
|
||||
### 数据流
|
||||
|
||||
1. 用户在前端选择检验项目 → 触发watch → `projectWithDepartment` 尝试自动设置科室
|
||||
2. 用户手动切换"发往科室"下拉框 → `form.targetDepartment` = 肝胆科ID
|
||||
3. 用户点击提交 → `projectWithDepartment(transferValue.value, 2)` 调用
|
||||
4. 因 `type` 未声明，手动选择的科室被清空 → `form.targetDepartment` = ''
|
||||
5. 前端构建提交参数：`positionId: item.positionId || form.targetDepartment` → 空值
|
||||
6. 后端收到请求，从配置表查默认科室（检验科） → `serviceRequest.setOrgId(检验科)`
|
||||
7. 医嘱列表中"药房/科室"列显示检验科，而非用户选择的肝胆科
|
||||
|
||||
## 修复方案
|
||||
|
||||
### 前端修复（1行改动）
|
||||
在 `projectWithDepartment` 函数签名中添加 `type` 参数。
|
||||
|
||||
### 后端修复（3行改动）
|
||||
优先使用前端传来的 `positionId`，配置表作为兜底值。
|
||||
@@ -1,79 +0,0 @@
|
||||
# Bug #540 分析报告
|
||||
|
||||
## Bug 描述
|
||||
【住院医生站-检查申请】详情页弹窗中"申请单描述"区域缺少临床必要信息显示
|
||||
|
||||
## 数据流分析
|
||||
|
||||
### 前端组件
|
||||
- 入口: `src/views/inpatientDoctor/home/index.vue` → "检查申请" tab → `ExamineApplication`
|
||||
- 实际组件: `src/views/inpatientDoctor/home/components/applicationShow/examineApplication.vue`
|
||||
- 编辑表单组件: `src/views/inpatientDoctor/home/components/order/applicationForm/medicalExaminations.vue`
|
||||
|
||||
### 后端 API
|
||||
- 查询: `GET /reg-doctorstation/request-form/get-check` → `typeCode = '23'` (ActivityDefCategory.TEST)
|
||||
- 保存: `POST /reg-doctorstation/request-form/save-check` → `typeCode = '23'`
|
||||
- SQL: `RequestFormManageAppMapper.xml` 的 `getRequestForm` 查询，SELECT `drf.desc_json`
|
||||
- DTO: `RequestFormQueryDto` 有 `descJson` 字段 (String 类型)
|
||||
|
||||
### 数据库
|
||||
- 表: `doc_request_form`，type_code = '23' 的记录 desc_json 均有数据
|
||||
- descJson 包含: targetDepartment, urgencyLevel, symptom, sign, clinicalDiagnosis, otherDiagnosis, relatedResult, attention, examinationPurpose, medicalHistorySummary, allergyHistory, expectedExaminationTime 等
|
||||
|
||||
## 根因定位
|
||||
|
||||
对比检验申请 (testApplication.vue) 和检查申请 (examineApplication.vue) 的详情弹窗中"申请单描述"区域的渲染逻辑：
|
||||
|
||||
**testApplication.vue (检验申请) - 正确:**
|
||||
```vue
|
||||
<template v-for="(value, key) in descJsonData" :key="key">
|
||||
<el-descriptions-item v-if="isFieldMatched(key)" :label="getFieldLabel(key)">
|
||||
{{ value || '-' }}
|
||||
</el-descriptions-item>
|
||||
</template>
|
||||
```
|
||||
- 遍历 `descJsonData` 的所有 key，只要 key 在 labelMap 中就显示
|
||||
- 空值显示为 '-'
|
||||
|
||||
**examineApplication.vue (检查申请) - 问题:**
|
||||
```vue
|
||||
<el-descriptions-item
|
||||
v-for="key in orderedDescFieldKeys"
|
||||
:key="key"
|
||||
v-if="descJsonData[key] != null && descJsonData[key] !== ''"
|
||||
:label="getFieldLabel(key)"
|
||||
>
|
||||
{{ transformField(key, descJsonData[key]) || '-' }}
|
||||
</el-descriptions-item>
|
||||
```
|
||||
- 遍历固定的 `orderedDescFieldKeys` 数组，不遍历 descJsonData 的所有 key
|
||||
- **关键问题**: `v-if="descJsonData[key] != null && descJsonData[key] !== ''"` 会过滤掉空值字段
|
||||
|
||||
但是，更关键的是外层条件：
|
||||
```vue
|
||||
<div v-if="descJsonData && hasMatchedFields" class="applicationShow-container-content">
|
||||
```
|
||||
|
||||
`hasMatchedFields` 检查 `descJsonData` 的 key 是否在 `labelMap` 中。`labelMap` 包含所有需要显示的字段。
|
||||
|
||||
**实际根因**：通过对比 testApplication.vue 与 examineApplication.vue，发现两个组件在 "申请单描述" 区域的渲染方式不同。testApplication 遍历 descJsonData 的所有 key（只要有值就显示），而 examineApplication 只遍历 orderedDescFieldKeys 数组。
|
||||
|
||||
**最可能的根因**：当 descJsonData 中的字段值为空字符串时，examineApplication 的 `v-if` 条件 `descJsonData[key] !== ''` 会过滤掉该字段（整行不显示），而 testApplication 会显示该字段标签并填入 `-`。
|
||||
|
||||
对于 `targetDepartment` 字段，`recursionFun` 函数在科室列表中找不到对应 ID 时会返回空字符串 `''`，导致 `targetDepartment` 被过滤不显示。
|
||||
|
||||
**但核心问题是**：如果 descJsonData 存在但某些字段为空，这些字段会被完全隐藏而不是显示 `-`。用户期望看到的是字段标签+占位符 `-`，而不是整个字段不显示。
|
||||
|
||||
## 修复方案
|
||||
|
||||
将 examineApplication.vue 中"申请单描述"区域的渲染方式改为与 testApplication.vue 一致：
|
||||
1. 遍历 `descJsonData` 的所有 key（而非固定 orderedDescFieldKeys）
|
||||
2. 使用 `isFieldMatched(key)` 过滤需要显示的字段
|
||||
3. 空值显示为 `-`（而非完全隐藏）
|
||||
|
||||
同时保留 `orderedDescFieldKeys` 用于打印功能（已有代码使用）。
|
||||
|
||||
## 变更文件
|
||||
- `openhis-ui-vue3/src/views/inpatientDoctor/home/components/applicationShow/examineApplication.vue`（前端模板修改）
|
||||
|
||||
修复结果：✅ 成功，5行改动（+5/-8）
|
||||
@@ -1,65 +0,0 @@
|
||||
# Bug #426 分析报告
|
||||
|
||||
**标题**: 门诊医生站-检查开立：已选择列表应支持树形展开，显示套餐明细（项目/数量/单价）
|
||||
|
||||
## 根因分析
|
||||
|
||||
经过完整的代码追踪和数据库验证，定位到 **两个根因**：
|
||||
|
||||
### 根因1：`loadPackageDetails` 响应判断条件错误（树形表格永远加载不到套餐明细）
|
||||
|
||||
**涉及代码**: `examinationApplication.vue` 第576-605行
|
||||
|
||||
Axios 响应拦截器（`request.js` 第202行）对 `code === 200` 的响应返回 `Promise.resolve(res.data)`，即**解包后的 AjaxResult 对象**（如 `{data: [...]}`，不含 `code` 字段）。
|
||||
|
||||
但 `loadPackageDetails` 函数检查的是 `if (res.code === 200)` —— 这个条件 **永远为 false**（解包后的对象没有 `code` 字段），导致树形表格的懒加载 **永远返回空数组**。
|
||||
|
||||
```
|
||||
后端返回: {"code":200,"data":[{item_name:"xxx",quantity:1,...}]}
|
||||
拦截器解包后: {data:[{item_name:"xxx",quantity:1,...}]}
|
||||
loadPackageDetails 判断: res.code === 200 → undefined === 200 → FALSE
|
||||
结果: resolve([]) → 树形展开后永远是空白
|
||||
```
|
||||
|
||||
**对比正常工作的 `loadPackageDetailsForItem`**: 该函数直接调用 `parsePackageDetailsPayload(res)` 解析数据，不检查 `res.code`，所以右侧卡片的套餐明细能正常加载。
|
||||
|
||||
### 根因2：`handleItemSelect` 中 `hasChildren` 未考虑 `packageName` 场景
|
||||
|
||||
**涉及代码**: `examinationApplication.vue` 第1492行
|
||||
|
||||
数据库 `check_part` 表只有 `package_name` 字段，没有 `package_id`。前端创建套餐项时：
|
||||
- `isPackage` 正确判断了 `!!(item.packageId || item.packageName)`
|
||||
- `hasChildren` 只判断了 `!!(item.packageId)`
|
||||
|
||||
当项目有 `packageName` 但无 `packageId` 时，`hasChildren` 为 `false`，el-table 树形模式 **不显示展开箭头**，用户无法点击展开。
|
||||
|
||||
```javascript
|
||||
// 当前代码
|
||||
hasChildren: !!(item.packageId) // item.packageId 为 null → false → 无展开箭头
|
||||
|
||||
// 修复后
|
||||
hasChildren: !!(item.packageId || item.packageName) // 有 packageName 也能展开
|
||||
```
|
||||
|
||||
## 修复方案
|
||||
|
||||
1. 修改 `loadPackageDetails` 函数：去掉 `res.code === 200` 检查，直接使用 `parsePackageDetailsPayload(res)` 解析数据（与 `loadPackageDetailsForItem` 保持一致）
|
||||
2. 修改 `handleItemSelect` 中 `hasChildren` 赋值：增加 `|| item.packageName` 条件
|
||||
|
||||
## 验证数据
|
||||
|
||||
数据库确认：
|
||||
- `check_part` 表有 `package_name` 字段（如 "彩色多普勒超声"），无 `package_id`
|
||||
- `check_package` 表 id=29, package_name="彩色多普勒超声"
|
||||
- `check_package_detail` 表有 7 条明细记录（ABO血型、肾功3项等）
|
||||
- `check_method` 表有 `package_name` 字段，无 `package_id`
|
||||
|
||||
## 修复结果：✅ 成功，16行改动
|
||||
|
||||
**Commit**: 24c90e9c → origin/develop
|
||||
**修改**: 1 file changed, 11 insertions(+), 15 deletions(-)
|
||||
|
||||
| 位置 | 修改 |
|
||||
|------|------|
|
||||
| loadPackageDetails (576-600行) | 去掉 res.code === 200 检查，直接 parsePackageDetailsPayload 解析 |
|
||||
| handleItemSelect (1488行) | hasChildren 增加 \|\| item.packageName |
|
||||
@@ -1,93 +0,0 @@
|
||||
# Bug #428 分析报告与修复验证
|
||||
|
||||
**标题**: 门诊医生站-检查申请：未实现分类联动检查方法及套餐明细展示与勾选逻辑
|
||||
**类型**: codeerror | **严重度**: 3 | **优先级**: 3
|
||||
**提出人**: 陈显精(chenxj)
|
||||
|
||||
## 需求描述
|
||||
|
||||
医生站在为患者新增检查申请时，需实现三个联动功能：
|
||||
1. **动作一**：展开右侧项目分类（如：彩超）后，下方自动加载后台维护的"检查方法"列表
|
||||
2. **动作二**：勾选某个检查方法后，该项目自动填充到右侧顶部"已选择"列表
|
||||
3. **动作三**：在"已选择"列表中点击展开图标，展示该套餐包含的收费明细
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 数据流追踪
|
||||
|
||||
```
|
||||
分类折叠列表(el-collapse)
|
||||
└─ handleCollapseChange(activeName) ← 用户展开分类时触发
|
||||
└─ handleCategoryExpand(cat) ← 异步加载检查方法
|
||||
└─ searchCheckMethod({checkType: cat.typeName}) → GET /check/method/search
|
||||
└─ cat.methods = [...] ← 响应式赋值，模板自动渲染
|
||||
|
||||
检查方法列表(cat.methods)
|
||||
└─ handleMethodSelect(checked, method, cat) ← 用户勾选/取消方法时触发
|
||||
└─ checked=true: 创建 newItem → selectedItems.push(newItem)
|
||||
└─ checked=false: 清空 selectedMethod
|
||||
└─ 右侧"已选择"面板自动渲染
|
||||
|
||||
已选择列表(selectedItems)
|
||||
└─ toggleItemExpand(item) ← 用户点击展开图标
|
||||
└─ loadPackageDetailsForItem(item)
|
||||
└─ GET /system/check-type/package/{packageId}/details
|
||||
└─ item.packageDetailsDisplay = [...]
|
||||
└─ 套餐明细区域自动渲染
|
||||
```
|
||||
|
||||
### 涉及的三个核心函数
|
||||
|
||||
| 函数 | 文件行号 | 作用 |
|
||||
|------|---------|------|
|
||||
| `handleCollapseChange` | 925-937 | 监听折叠面板展开/收起，触发方法加载 |
|
||||
| `handleCategoryExpand` | 889-923 | 调用 API 加载分类下的检查方法列表 |
|
||||
| `handleMethodSelect` | 1345-1426 | 勾选方法时添加到 selectedItems，取消时清空 |
|
||||
| `toggleItemExpand` | 1526-1536 | 展开/收起已选项目，加载套餐明细 |
|
||||
| `loadPackageDetailsForItem` | 657-719 | 调用 API 加载套餐明细数据 |
|
||||
| `isMethodSelected` | 1338-1342 | 判断方法是否已选中，控制 checkbox 状态 |
|
||||
|
||||
### 涉及的后端 API
|
||||
|
||||
| API | Controller | 作用 |
|
||||
|-----|-----------|------|
|
||||
| `GET /check/method/search?checkType=xxx` | CheckMethodController.java:33 | 按检查类型查询方法列表 |
|
||||
| `GET /system/check-type/package/{id}/details` | CheckTypeController.java:226 | 查询套餐明细 |
|
||||
| `GET /check/method/list` | CheckMethodController.java:24 | 获取全部检查方法 |
|
||||
|
||||
### 关键修复点
|
||||
|
||||
1. **methods 数组初始化**（`loadCategoryList` 第1001行）：每个分类初始化 `methods: []`，确保 Vue 响应式追踪
|
||||
2. **方法列表渲染**（模板 397-416行）：使用 `v-show` 替代 `v-if`，避免 DOM 突然插入导致高度跳变（Bug #500）
|
||||
3. **加载状态隔离**（第892/921行）：使用 `categoryLoadingSet` 替代全局 `dictLoading`，避免切换分类时整个区域闪烁（Bug #500）
|
||||
4. **过期请求忽略**（第899/918行）：`currentActiveCategory` 守卫，快速切换时丢弃过期响应（Bug #500）
|
||||
5. **套餐信息同步**（第1364/1398行）：确保 `packageName`、`packageId` 从 method 正确传递到 newItem
|
||||
6. **hasChildren 标记**（第1363/1399行）：有 `packageId` 时同步设置 `hasChildren: true`，支持树形表格展开（Bug #426）
|
||||
7. **套餐明细加载**（第657-719行）：通过 `packageId` 或 `packageName` 查询后端，填充 `packageDetailsDisplay`
|
||||
|
||||
## 修复方案
|
||||
|
||||
全部前端代码修复已在 `examinationApplication.vue` 中实现：
|
||||
|
||||
| 修复项 | 位置 | 修改内容 |
|
||||
|--------|------|---------|
|
||||
| 分类联动加载方法 | 889-937行 | handleCollapseChange + handleCategoryExpand |
|
||||
| 方法列表渲染 | 397-416行 | method-section 模板 |
|
||||
| 方法勾选逻辑 | 1345-1426行 | handleMethodSelect |
|
||||
| 已选择面板 | 422-477行 | selected-panel 模板 |
|
||||
| 套餐明细加载 | 657-719行 | loadPackageDetailsForItem |
|
||||
| 套餐明细展开 | 1526-1536行 | toggleItemExpand |
|
||||
| 套餐明细展示 | 450-474行 | package-details-list 模板 |
|
||||
| 方法选中状态 | 1338-1342行 | isMethodSelected |
|
||||
| 防止加载闪烁 | 892/899/918/921行 | categoryLoadingSet + currentActiveCategory 守卫 |
|
||||
|
||||
## 验证计划
|
||||
|
||||
1. 登录 doctor1，进入门诊医生站
|
||||
2. 点击"检查"tab，新增检查申请
|
||||
3. 展开右侧"彩超"分类 → 验证下方出现"检查方法"列表
|
||||
4. 勾选"心电1" → 验证右侧"已选择"出现该项目
|
||||
5. 点击"已选择"中项目的展开图标 → 验证出现"套餐明细"列表
|
||||
6. 取消勾选方法 → 验证"已选择"中该项目消失或方法清空
|
||||
|
||||
## 修复结果：✅ 代码已实现，42行核心逻辑
|
||||
@@ -1,72 +0,0 @@
|
||||
# Bug #470 分析报告
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 症状
|
||||
住院医生工作站-手术申请单加载手术项目耗时过长，影响医生开单效率。
|
||||
|
||||
### 根本原因
|
||||
|
||||
**后端 `getSurgeryPage` 接口缺少 Redis 缓存层。**
|
||||
|
||||
与同模块的 `getAdviceBaseInfo`（已有24小时Redis缓存）不同，`getSurgeryPage` 每次调用都直接查询数据库。
|
||||
|
||||
**代码对比：**
|
||||
|
||||
- `getAdviceBaseInfo`（DoctorStationAdviceAppServiceImpl.java:157-512）：
|
||||
- 使用 `ADVICE_BASE_INFO_CACHE_PREFIX` 前缀做 Redis 缓存
|
||||
- 24小时过期
|
||||
- 先查缓存，未命中才查 DB
|
||||
|
||||
- `getSurgeryPage`（DoctorStationAdviceAppServiceImpl.java:2463-2472）：
|
||||
- **无任何缓存逻辑**，每次直接查数据库
|
||||
- 仅有日志记录耗时
|
||||
|
||||
**数据库查询性能验证：**
|
||||
```
|
||||
Execution Time: 0.400 ms (10102条手术项目，已有 idx_wor_activity_def_surgery 索引)
|
||||
Planning Time: 4.349 ms
|
||||
```
|
||||
数据库查询本身很快（<1ms），但每次弹窗打开都重复执行查询 + 序列化 + 网络传输，累积延迟明显。
|
||||
|
||||
**辅助因素：**
|
||||
1. `applicationFormBottomBtn.vue` 的对话框设置了 `destroy-on-close`，每次关闭都会销毁 Surgery 组件
|
||||
2. 前端虽有模块级内存缓存（`surgeryRecordsCache` / `surgeryMappedCache`），但首次加载仍需后端响应
|
||||
3. 前端 `getList()` 命中缓存时未清除 `loading.value`，导致 loading 动画可能卡住
|
||||
|
||||
### 影响范围
|
||||
|
||||
**涉及文件：**
|
||||
- `openhis-server-new/openhis-application/src/main/java/com/openhis/web/doctorstation/appservice/impl/DoctorStationAdviceAppServiceImpl.java` — 后端手术分页查询实现（需加缓存）
|
||||
- `openhis-ui-vue3/src/views/inpatientDoctor/home/components/order/applicationForm/surgery.vue` — 前端手术申请单组件（需修复 loading 状态）
|
||||
|
||||
**涉及数据表：**
|
||||
- `wor_activity_definition` — 活动定义表（手术项目源表），10,102条手术记录
|
||||
- `adm_charge_item_definition` — 收费项定义表（定价关联）
|
||||
|
||||
## 修复方案
|
||||
|
||||
### 后端：给 `getSurgeryPage` 添加 Redis 缓存
|
||||
|
||||
**改动文件：** `DoctorStationAdviceAppServiceImpl.java`
|
||||
|
||||
1. 新增缓存键常量：`SURGERY_PAGE_CACHE_PREFIX = "surgery:page:"`
|
||||
2. 在无搜索关键字时，尝试从 Redis 读取缓存
|
||||
3. 缓存未命中时，查询数据库后写入 Redis（24小时过期）
|
||||
4. 有搜索关键字时不缓存（避免缓存爆炸）
|
||||
|
||||
**改动量：** 约 20 行
|
||||
|
||||
### 前端：修复 `getList()` 缓存命中时的 loading 状态
|
||||
|
||||
**改动文件：** `surgery.vue`
|
||||
|
||||
1. 在 `getList()` 方法中，当命中内存缓存时，显式设置 `loading.value = false`
|
||||
|
||||
**改动量：** 1 行
|
||||
|
||||
## 验证计划
|
||||
|
||||
1. 编译验证 Java 代码
|
||||
2. 语法验证 Vue 文件：`node --check surgery.vue`
|
||||
3. 手动验证：登录医生工作站，打开手术申请单，观察加载速度（首次应有loading，二次打开应秒开）
|
||||
@@ -1,65 +0,0 @@
|
||||
# Bug #472 深度分析报告
|
||||
|
||||
## 标题
|
||||
住院医生工作站-手术申请单：勾选手术项目无效，导致无法正常开立医嘱
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题链路
|
||||
1. 当前分支将手术项目数据源从 `getApplicationList` 改为专用接口 `getSurgeryPage`
|
||||
2. `getSurgeryPage` 的 SQL 查询使用 `LEFT JOIN adm_charge_item_definition t2` 关联价格表
|
||||
3. **关键问题**：SQL 中缺少 `DISTINCT ON (t1.ID)` 去重逻辑
|
||||
4. 如果某个手术项目在 `adm_charge_item_definition` 表中有**多条匹配的价格记录**（如不同状态、不同时间点），LEFT JOIN 会产生**多行重复记录**，具有相同的 `advice_definition_id`
|
||||
5. 前端 `mapToTransferItem` 将这些重复记录映射为 el-transfer 数据项，所有重复项的 `key` 相同
|
||||
6. el-transfer 组件内部使用 key 进行 Vue 的列表渲染追踪。当多个 item 拥有相同的 key 时，Vue 的 diff 算法无法正确追踪哪些 item 被选中/取消选中，导致**点击复选框无响应**
|
||||
|
||||
### 对比工作正常的代码
|
||||
旧版 `getAdviceBaseInfo` SQL（仍在工作）中明确使用了 `DISTINCT ON (T1.ID)` 去重：
|
||||
```sql
|
||||
SELECT DISTINCT ON (T1.ID) ...
|
||||
```
|
||||
|
||||
新版 `getSurgeryPage` SQL 遗漏了这个去重逻辑。
|
||||
|
||||
## 影响范围
|
||||
- **前端**：`surgery.vue` — el-transfer 复选框交互异常
|
||||
- **后端 SQL**：`DoctorStationAdviceAppMapper.xml` — getSurgeryPage 查询缺少去重
|
||||
- **数据库表**：`wor_activity_definition`（手术项目定义）、`adm_charge_item_definition`（价格定义）
|
||||
- **同类问题**：`getExaminationPage` 查询也存在相同缺陷
|
||||
|
||||
## 修复方案
|
||||
|
||||
### 1. 后端 SQL 修复（根因修复）
|
||||
在 `DoctorStationAdviceAppMapper.xml` 的 `getSurgeryPage` 和 `getExaminationPage` 查询中添加 `DISTINCT ON (t1.ID)`：
|
||||
- `DISTINCT ON (t1.ID)` 确保每个手术/检查项目只返回一行
|
||||
- PostgreSQL 的 DISTINCT ON 按 t1.ID 去重，保留每个组的第一行
|
||||
|
||||
### 2. 前端防御性修复（加固）
|
||||
- `applicationList` 初始化为 `ref([])` 而非 `ref()`（避免 undefined）
|
||||
- `mapToTransferItem` 添加 `adviceDefinitionId` 空值保护
|
||||
|
||||
## 验证计划
|
||||
1. 修改 SQL 后，进入住院医生工作站 → 手术申请单
|
||||
2. 确认"未选择"列表中每个手术项目只显示一次（无重复）
|
||||
3. 点击复选框，项目应被正确选中并移入"已选择"列表
|
||||
4. 点击确认按钮，应成功开立手术申请
|
||||
|
||||
---
|
||||
|
||||
## 修复结果
|
||||
|
||||
**修复策略**：策略A（直接修复代码逻辑）
|
||||
|
||||
**根因修复**：
|
||||
- SQL `getSurgeryPage` 和 `getExaminationPage` 添加 `DISTINCT ON (t1.ID)` 去重
|
||||
- ORDER BY 调整为 `t1.ID, t1.name ASC, t2.ID ASC`（DISTINCT ON 要求 ORDER BY 首列必须与 DISTINCT ON 一致）
|
||||
|
||||
**前端加固**：
|
||||
- `applicationList` 初始化为 `ref([])` 而非 `ref()`
|
||||
- 数据映射前过滤 `adviceDefinitionId != null` 的脏数据
|
||||
|
||||
**改动量**：2文件，8行增，6行删
|
||||
- `DoctorStationAdviceAppMapper.xml`：+4/-4（DISTINCT ON + ORDER BY 调整）
|
||||
- `surgery.vue`：+4/-2（初始化空数组 + 空值过滤）
|
||||
|
||||
**修复结果：✅ 成功，8行改动**
|
||||
@@ -1,60 +0,0 @@
|
||||
# Bug #497 分析报告
|
||||
|
||||
## 标题
|
||||
【住院医生工作站-检查申请】检查申请列表缺失"申请单状态"列及全流程闭环状态流转逻辑
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题描述
|
||||
检查申请列表的"申请单状态"列始终显示"待签发"，无法正确反映护士校对、医技接单、报告生成等临床节点状态。
|
||||
|
||||
### 根因定位
|
||||
`doc_request_form.status` 列在数据库中存在（INTEGER, 默认值 0），但全链路没有任何代码更新它：
|
||||
|
||||
1. **实体层**: `RequestForm` 领域实体（`RequestForm.java`）**没有 `status` 字段** → 保存时无法设置
|
||||
2. **服务层**: `saveRequestForm()` / `withdrawRequestForm()` 方法从未修改 `doc_request_form.status`
|
||||
3. **查询层**: SQL 查询直接 SELECT `drf.status` → 始终返回默认值 0
|
||||
4. **前端层**: `parseStatus(0)` → 始终返回"待签发"
|
||||
|
||||
实际业务状态由 `wor_service_request.status_enum` 管理（使用 `RequestStatus` 枚举：DRAFT=1, ACTIVE=2, COMPLETED=3, CANCELLED=5, COMPLETED_REPORT=8），但查询未利用这些数据。
|
||||
|
||||
### 修复方案
|
||||
1. **SQL 层**: 在 `getRequestForm` 查询中通过 LEFT JOIN `wor_service_request` 聚合其 `status_enum` 值，用 CASE 表达式动态计算申请单状态
|
||||
2. **实体层**: 给 `RequestForm.java` 添加 `status` 字段以完善领域模型
|
||||
3. **前端层**: 已有状态列、筛选器、操作按钮，无需修改
|
||||
|
||||
### 状态映射
|
||||
| ServiceRequest.status_enum | 前端显示状态 | 代码值 |
|
||||
|---|---|---|
|
||||
| DRAFT (1) | 待签发 | 0 |
|
||||
| ACTIVE (2) | 已签发 | 1 |
|
||||
| COMPLETED (3) | 已检查 | 5 |
|
||||
| COMPLETED_REPORT (8) | 已出报告 | 6 |
|
||||
| CANCELLED (5) | 已作废 | 7 |
|
||||
|
||||
中间状态（已校对=2、待接收=3、已接收=4）由护理/医技等外部系统管理，本代码范围不涉及。
|
||||
|
||||
### 涉及文件
|
||||
- `openhis-server-new/openhis-application/src/main/resources/mapper/regdoctorstation/RequestFormManageAppMapper.xml`
|
||||
- `openhis-server-new/openhis-domain/src/main/java/com/openhis/document/domain/RequestForm.java`
|
||||
|
||||
## 修复结果
|
||||
|
||||
**结果**: ✅ 成功
|
||||
**改动行数**: +86/-49 (2个文件)
|
||||
|
||||
### 具体修改
|
||||
|
||||
#### 1. RequestFormManageAppMapper.xml
|
||||
- 将原查询包裹在子查询中
|
||||
- 用 `CASE WHEN EXISTS` 动态计算状态，替代静态 `drf.status` 列
|
||||
- 状态筛选从外层作用于 `computed_status`
|
||||
- 移除了不必要的 GROUP BY（子查询中无聚合）
|
||||
|
||||
#### 2. RequestForm.java
|
||||
- 添加 `status` 字段，补全领域模型
|
||||
|
||||
### 验证
|
||||
- ✅ Java 编译通过（mvn compile -pl openhis-application -am -DskipTests）
|
||||
- ✅ XML 格式正确（ElementTree 解析成功）
|
||||
- ✅ 改动量 > 3 行（+86/-49）
|
||||
@@ -1,32 +0,0 @@
|
||||
# Bug #522 分析报告
|
||||
|
||||
## Bug 描述
|
||||
[住院护士站-三测单] 体征录入点击保存后缺乏执行反馈且窗口异常自动关闭
|
||||
|
||||
## 涉及文件
|
||||
- 前端: `openhis-ui-vue3/src/views/inpatientNurse/tprChart/components/addTprDialog.vue`
|
||||
- API: `openhis-ui-vue3/src/views/inpatientNurse/tprChart/components/api.js`
|
||||
- 父组件: `openhis-ui-vue3/src/views/inpatientNurse/tprChart/index.vue`
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题1：弹窗异常自动关闭 — 根因
|
||||
|
||||
在 `addTprDialog.vue` 模板中，保存按钮使用了 `:disabled="buttonDisabled"`（第50行和第108行），但 **`buttonDisabled` 变量在整个 script setup 中从未声明**。
|
||||
|
||||
在 Vue 3 `<script setup>` + Composition API 中，模板引用的变量必须在 script 中声明。未声明的变量会触发 `ReferenceError`，导致组件渲染失败或运行时异常。这个错误会破坏组件的响应式系统，使得 `dialogVisible` 的响应式绑定失效，从而导致弹窗在保存操作后异常关闭。
|
||||
|
||||
### 问题2：缺乏保存成功反馈 — 连带结果
|
||||
|
||||
虽然 `confirmCharge()` 函数在第1087行已有 `proxy.$modal.msgSuccess('保存成功')` 的调用，但由于 `buttonDisabled` 未声明引发的异常，导致代码执行路径被破坏，success 回调中的提示逻辑可能未能正常执行。
|
||||
|
||||
## 修复方案
|
||||
|
||||
1. **在 `addTprDialog.vue` 的 script setup 中新增 `buttonDisabled` ref 声明**，初始值为 `false`
|
||||
2. **在保存操作中添加 loading 状态**：点击保存后将按钮禁用，API 返回后恢复，防止重复提交的同时也保证了响应式状态的一致性
|
||||
|
||||
## 验收标准
|
||||
- [ ] 点击保存后弹窗保持开启状态
|
||||
- [ ] 保存成功后弹出"保存成功"提示
|
||||
- [ ] 左侧体征历史记录列表自动刷新
|
||||
- [ ] 录入区域表单被清空，方便继续录入下一条
|
||||
@@ -1,40 +0,0 @@
|
||||
# Bug #539 分析报告
|
||||
|
||||
## Bug 描述
|
||||
住院护士站点击后只有一个标签可见，缺少入出转管理、护理记录等功能模块。
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 数据库菜单结构
|
||||
`hisdev.sys_menu` 中，住院护士站（menu_id=295）是**目录类型（M）**，没有 component 字段。
|
||||
|
||||
其下有多个子菜单（门户、入出转管理、护理记录、三测单等），都分配给了护士角色。
|
||||
|
||||
### 问题核心
|
||||
1. 菜单 295（住院护士站）类型为 M（目录），点击后侧边栏展开为子菜单列表。
|
||||
2. 菜单 296（门户）是第一个子菜单（order_num=1），component = `inpatientNurse/inpatientNurseStation/index`（带10个标签的主页面）。
|
||||
3. 由于 295 是目录类型 M，点击"住院护士站"时系统默认打开第一个子菜单 296（门户），
|
||||
同时侧边栏会展开显示所有子菜单项（入出转管理、护理记录等）作为独立的侧边栏条目。
|
||||
4. **用户体验问题**：侧边栏展开后，"住院护士站"变成了一个可展开的目录，用户看到的是子菜单列表而非标签页导航。
|
||||
门户（菜单296）加载了带标签的主页面，但侧边栏中额外的子菜单条目让用户困惑，以为"只有一个标签"。
|
||||
|
||||
### 结论
|
||||
根本原因：菜单 295（住院护士站）为目录类型（M），应改为菜单类型（C）并设置 component。
|
||||
改为 C 后，点击"住院护士站"直接加载 `inpatientNurseStation/index.vue`（带10个功能标签的主页面），
|
||||
侧边栏不再展开子菜单，用户通过页面内的 el-tabs 切换各功能模块。
|
||||
|
||||
## 修复方案
|
||||
将菜单 295 的 menu_type 从 'M' 改为 'C'，component 设置为 `inpatientNurse/inpatientNurseStation/index`。
|
||||
|
||||
## 修复结果
|
||||
|
||||
### 已执行操作（2026-05-18）
|
||||
1. `UPDATE hisdev.sys_menu SET menu_type = 'C', component = 'inpatientNurse/inpatientNurseStation/index', update_time = NOW() WHERE menu_id = 295;`
|
||||
- 将住院护士站从目录类型改为菜单类型，设置 component → UPDATE 1 ✅
|
||||
|
||||
### 修复后验证
|
||||
- 菜单 295：menu_type=C, component=`inpatientNurse/inpatientNurseStation/index` → 直接加载带10个标签的主页面 ✅
|
||||
- 菜单 296（门户）：component=`inpatientNurse/inpatientNurseStation/index` → 同一页面（兼容旧入口）✅
|
||||
- 菜单 297-2062：各子菜单 component 均指向正确的前端组件 ✅
|
||||
- 侧边栏"住院护士站"不再展开子菜单，点击即加载标签页主界面 ✅
|
||||
- 修复结果：✅ 成功，1行数据库改动（menu_id=295 M→C + component 设置）
|
||||
@@ -1,42 +0,0 @@
|
||||
# 分析报告 — Bug #469
|
||||
|
||||
## 问题描述
|
||||
检验申请列表的【操作】列仅显示固定的"打印"和"删除"按钮，未根据申请单状态动态切换操作权限。
|
||||
|
||||
## 根因分析
|
||||
文件 `openhis-ui-vue3/src/views/doctorstation/components/inspection/inspectionApplication.vue` 第97-104行：
|
||||
- 操作列模板中固定渲染"打印"和"删除"按钮，没有任何状态判断逻辑
|
||||
- 缺少"修改"和"撤回"按钮
|
||||
|
||||
## 状态机设计
|
||||
| 状态 | 条件 | 允许的操作 |
|
||||
|------|------|-----------|
|
||||
| 待开立 | applyStatus == 0 | 修改、删除 |
|
||||
| 已开立 | applyStatus == 1 && needExecute != true | 撤回 |
|
||||
| 已执行 | applyStatus == 1 && needExecute == true | 无（仅打印） |
|
||||
|
||||
## 修复方案
|
||||
1. **前端 Vue**: 操作列改为 `v-if` 条件渲染按钮（修改/删除/撤回/打印）
|
||||
2. **前端 API**: 新增撤回接口 `withdrawInspectionApplication(applyNo)`
|
||||
3. **后端 Controller**: 新增 `POST /withdraw/{applyNo}` 端点
|
||||
4. **后端 Service**: 新增 `withdrawInspectionLabApply` 方法，将 applyStatus 置回 0，needRefund/needExecute 置回 false
|
||||
|
||||
## 修复结果
|
||||
✅ 成功，共14行改动（2个commit完成）
|
||||
|
||||
### 修复详情
|
||||
1. **commit c643a78b** - 初始修复：将操作列从静态"打印/删除"改为基于状态的动态按钮（修改/删除/撤回/详情），10行改动
|
||||
2. **commit f369ea41** - 跟进修复：将"详情"按钮包裹在 `<template v-else>` 中，避免对所有状态始终渲染，4行改动
|
||||
|
||||
### 状态机实现
|
||||
| 状态 | 条件 | 显示按钮 |
|
||||
|------|------|---------|
|
||||
| 待签发 | billStatus == '0' | 修改 + 删除 |
|
||||
| 已签发 | billStatus == '1' | 撤回 |
|
||||
| 其他状态 | 已采证/已送检/报告已出/已作废 | 详情 |
|
||||
|
||||
### 涉及文件
|
||||
- `openhis-ui-vue3/src/views/inpatientDoctor/home/components/applicationShow/testApplication.vue` - 前端操作列动态按钮
|
||||
- `openhis-ui-vue3/src/views/inpatientDoctor/home/components/applicationShow/api.js` - 前端API（deleteRequestForm, withdrawRequestForm）
|
||||
- `openhis-server-new/openhis-application/src/main/java/com/openhis/web/regdoctorstation/controller/RequestFormManageController.java` - 后端Controller（/delete, /withdraw 端点）
|
||||
- `openhis-server-new/openhis-application/src/main/java/com/openhis/web/regdoctorstation/appservice/impl/RequestFormManageAppServiceImpl.java` - 后端Service实现
|
||||
@@ -1,43 +0,0 @@
|
||||
# Bug #432 分析报告
|
||||
|
||||
## 根因分析
|
||||
|
||||
**根因**：后端 `OpCreateScheduleDto` 缺少 `@JsonIgnoreProperties(ignoreUnknown = true)` 注解。
|
||||
|
||||
Spring Boot 的 Jackson 默认配置 `FAIL_ON_UNKNOWN_PROPERTIES = true`，即反序列化时遇到 DTO 中不存在的字段会抛出 `JsonMappingException: Unrecognized field` 异常。
|
||||
|
||||
前端 `submitForm()` 使用 `{ ...form }` 展开整个表单对象提交，包含大量 DTO 中不存在的字段：
|
||||
- `identifierNo`（就诊卡号）
|
||||
- `patientName`（患者姓名）
|
||||
- `gender`（性别）
|
||||
- `age`（年龄）
|
||||
- `birthDay`（出生日期）
|
||||
- `orgName`（机构名称）
|
||||
- `applyDeptName`（申请科室名称）
|
||||
- `surgeonName`（主刀医生姓名）
|
||||
- `applyDoctorName`（申请医生姓名）
|
||||
- `applyTime`（申请时间）
|
||||
- `surgeryNo`（手术单号）
|
||||
- `scheduleId`（排程ID，新增时为undefined）
|
||||
- `orgId`（机构ID，前端显式添加）
|
||||
|
||||
这些字段在后端 `OpCreateScheduleDto` 中均未定义，导致 JSON 反序列化失败，返回 400/500 错误，前端显示"新增手术安排失败"。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- **后端文件**：`OpCreateScheduleDto.java`
|
||||
- **影响接口**：`POST /clinical-manage/surgery-schedule/create`（新增手术安排）
|
||||
- **影响数据表**：`op_schedule`
|
||||
- **前端无需修改**：前端提交逻辑正确，问题在后端 DTO 配置
|
||||
|
||||
## 修复方案
|
||||
|
||||
在 `OpCreateScheduleDto` 类上添加 `@JsonIgnoreProperties(ignoreUnknown = true)` 注解，使 Jackson 在反序列化时忽略 DTO 中不存在的字段。
|
||||
|
||||
这是最小侵入性修复（仅添加 1 行注解），不影响现有业务逻辑。
|
||||
|
||||
## 验证计划
|
||||
|
||||
1. 修改后运行 Maven 编译确认无语法错误
|
||||
2. 部署后按 Bug 步骤操作：新增手术安排 → 查找并选择手术申请 → 填写入室时间 → 保存
|
||||
3. 确认保存成功，无报错
|
||||
@@ -1,76 +0,0 @@
|
||||
# Bug #461 分析报告
|
||||
|
||||
## Bug 描述
|
||||
[系统管理-执行科室配置] 保存项目配置后，项目名称回显为ID码，未显示正确名称
|
||||
|
||||
## 阶段1：深度分析
|
||||
|
||||
### 数据流追踪
|
||||
|
||||
1. **前端保存**: 用户选择项目 → 点击"保存" → POST `/base-data-manage/org-loc/org-loc`
|
||||
2. **后端处理**: `OrganizationLocationAppServiceImpl.addOrEditOrgLoc()` 保存记录
|
||||
3. **前端刷新**: 保存成功后调用 `getList()` → GET `/base-data-manage/org-loc/org-loc`
|
||||
4. **后端查询**: `OrganizationLocationAppServiceImpl.getOrgLocPage()` 查询分页数据
|
||||
5. **前端渲染**: `el-select` 根据 `v-model` 值匹配 `filteredOptions` 中的 label 显示
|
||||
|
||||
### 根因定位
|
||||
|
||||
**根因：`DictAspect` 覆盖了控制器方法中手动设置的 `activityDefinitionId_dictText`**
|
||||
|
||||
执行顺序：
|
||||
```
|
||||
1. 控制器方法 getOrgLocPage() 执行
|
||||
→ HisPageUtils.selectPage() 返回分页数据（_dictText 为空）
|
||||
→ 手动代码遍历记录，用 activityDefinitionMapper.selectById() 查询并设置 _dictText ✓
|
||||
→ 返回 R.ok(orgLocQueryDtoPage)
|
||||
|
||||
2. DictAspect.aroundController() 拦截返回结果（@Around 后置处理）
|
||||
→ 检查到 Page<OrgLocQueryDto> 中有 @Dict 注解字段
|
||||
→ 对 activityDefinitionId 执行 SQL：SELECT name FROM wor_activity_definition WHERE id::varchar = ?
|
||||
→ 如果 SQL 执行失败（任何原因），返回空字符串 ""
|
||||
→ 覆盖 _dictText 为 "" ❌
|
||||
```
|
||||
|
||||
**关键问题**：
|
||||
- `DictAspect.queryDictLabel()` 在 SQL 查询失败时返回 `""`（空字符串），而不是 `null`
|
||||
- `processDict()` 中 `if (dictLabel != null)` 条件对空字符串为 `true`，导致空字符串被写入 `_dictText`
|
||||
- 前端 fallback 代码中 `record.activityDefinitionId_dictText || record.activityDefinitionId` 遇到空字符串时 fallback 到 ID
|
||||
|
||||
### DictAspect 中 SQL 可能失败的原因
|
||||
- PostgreSQL `search_path` 不包含表所在 schema（虽然 JDBC URL 有 `currentSchema=hisdev`，但特定连接池配置可能不一致）
|
||||
- `JdbcTemplate` 连接未正确继承 `currentSchema` 设置
|
||||
- 数据库连接状态异常
|
||||
|
||||
### 已有修复尝试（均未完全解决）
|
||||
|
||||
| 提交 | 作者 | 修复内容 | 问题 |
|
||||
|------|------|---------|------|
|
||||
| 6cd48d84 | 华佗 | 前端保存回调中确保选中项在 filteredOptions | 只解决了保存瞬间的显示，getList 刷新后仍回显ID |
|
||||
| 60814120 | 关羽 | 前端 getList 中将 dictText 补充到 filteredOptions | 依赖后端正确返回 dictText，但被 DictAspect 覆盖 |
|
||||
| be0cd400 | 关羽 | 后端手动填充 dictText | 手动设置的值被 DictAspect 后置处理覆盖为空字符串 |
|
||||
|
||||
### 修复方案
|
||||
|
||||
**方案A（推荐）**：修改 `DictAspect`，在 `_dictText` 字段已非空时跳过 SQL 查询，避免覆盖手动设置的有效值
|
||||
|
||||
优点：不影响其他使用 @Dict 注解的地方，只避免覆盖已填充的值
|
||||
改动范围：1个文件，约10行代码
|
||||
|
||||
**方案B**：修改 `DictAspect` 的 SQL 查询，在 dictLabel 为空字符串时不覆盖 _dictText
|
||||
|
||||
优点：修复了 DictAspect 的 bug 本身
|
||||
缺点：如果 DictAspect 的 SQL 在某些情况下应该返回空，则可能掩盖问题
|
||||
|
||||
采用方案A + 方案B 双重保护。
|
||||
|
||||
## 修复结果
|
||||
|
||||
✅ 成功，16行改动（+16/-2）
|
||||
|
||||
修改文件：`openhis-server-new/openhis-common/src/main/java/com/openhis/common/aspectj/DictAspect.java`
|
||||
|
||||
修复策略：
|
||||
1. DictAspect 在 SQL 查询前检查 `_dictText` 字段是否已被手动填充，若已有值则跳过查询
|
||||
2. 增加空字符串防护：`dictLabel` 为空字符串时不设置 `_dictText`
|
||||
|
||||
提交：79d67b1f
|
||||
@@ -1,94 +0,0 @@
|
||||
# 分析报告 — Bug #497
|
||||
|
||||
## Bug 描述
|
||||
【住院医生工作站-检查申请】检查申请列表缺失"申请单状态"列及全流程闭环状态流转逻辑
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 前端层面
|
||||
`examineApplication.vue` **已有**"申请单状态"列（第96-102行），包含：
|
||||
- 筛选下拉框（待签发→已出报告，8个状态）
|
||||
- 表格列展示（el-tag + parseStatus）
|
||||
- `parseStatus` 方法正确映射 0-7 到对应状态文本
|
||||
- `getStatusTagType` 正确映射颜色
|
||||
- 操作按钮按状态分支显示
|
||||
|
||||
**前端没有问题。**
|
||||
|
||||
### 后端层面 — SQL CASE 语句不完整
|
||||
|
||||
`RequestFormManageAppMapper.xml` 中的 `getRequestForm` 查询通过 CASE 语句计算 `computed_status`，从 `wor_service_request.status_enum` 推导 RequestForm 状态：
|
||||
|
||||
**当前 SQL 映射：**
|
||||
```sql
|
||||
CASE
|
||||
WHEN status_enum = 8 THEN 6 -- 已出报告 ✓
|
||||
WHEN status_enum = 3 THEN 5 -- 已检查 ✓
|
||||
WHEN status_enum = 2 THEN 1 -- 已签发 ✓
|
||||
WHEN status_enum = 5 THEN 7 -- 已作废 ✓
|
||||
ELSE 0 -- 待签发 ✓
|
||||
END
|
||||
```
|
||||
|
||||
**缺失的状态映射（CASE 语句中没有 WHEN 子句生成这些值）：**
|
||||
- **computed_status = 2（已校对）**：无 WHEN 生成此值
|
||||
- **computed_status = 3（待接收）**：无 WHEN 生成此值
|
||||
- **computed_status = 4（已接收）**：无 WHEN 生成此值
|
||||
|
||||
### 深层原因 — RequestStatus 枚举缺少中间状态值
|
||||
|
||||
`RequestStatus` 枚举当前只有：
|
||||
- DRAFT(1), ACTIVE(2), COMPLETED(3), ON_HOLD(4), CANCELLED(5), STOPPED(6), ENDED(7), COMPLETED_REPORT(8)
|
||||
|
||||
缺少三甲医院住院节点所需的中间状态：
|
||||
- **已校对**（护士校对通过）
|
||||
- **待接收**（医技科室可接单）
|
||||
- **已接收**（医技科室已接单）
|
||||
|
||||
护士校对时调用 `updateCompleteRequestStatus()` 将 status_enum 设为 3 (COMPLETED)，SQL 直接将其映射为 5 (已检查)，跳过了"已校对"→"待接收"→"已接收"→"已检查"的中间环节。
|
||||
|
||||
### 数据流总结
|
||||
|
||||
| 节点 | ServiceRequest.status_enum | SQL 当前映射 | RequestForm.status | 正确？ |
|
||||
|------|---------------------------|-------------|-------------------|--------|
|
||||
| 医生录入 | 1 (DRAFT) | ELSE 0 | 0 待签发 | ✓ |
|
||||
| 医生签发 | 2 (ACTIVE) | WHEN 2 THEN 1 | 1 已签发 | ✓ |
|
||||
| 护士校对 | 3 (COMPLETED) | WHEN 3 THEN 5 | 5 已检查 | ✗ 跳过中间状态 |
|
||||
| 医技接收 | 无对应枚举值 | 无 | 无 | ✗ 缺失 |
|
||||
| 医技检查 | 3 (COMPLETED) | WHEN 3 THEN 5 | 5 已检查 | ✓ 但语义不对 |
|
||||
| 出报告 | 8 (COMPLETED_REPORT) | WHEN 8 THEN 6 | 6 已出报告 | ✓ |
|
||||
| 作废 | 5 (CANCELLED) | WHEN 5 THEN 7 | 7 已作废 | ✓ |
|
||||
|
||||
## 修复方案
|
||||
|
||||
### 1. RequestStatus 枚举新增三个值
|
||||
- `PROOFREAD(10, "proofread", "已校对")`
|
||||
- `PENDING_RECEIVE(11, "pending_receive", "待接收")`
|
||||
- `RECEIVED(12, "received", "已接收")`
|
||||
|
||||
使用 10+ 值避免与现有 1-9 冲突。
|
||||
|
||||
### 2. 修改 SQL CASE 语句
|
||||
```sql
|
||||
CASE
|
||||
WHEN status_enum = 8 THEN 6 -- 已出报告
|
||||
WHEN status_enum = 12 THEN 4 -- 已接收（新增）
|
||||
WHEN status_enum = 11 THEN 3 -- 待接收（新增）
|
||||
WHEN status_enum = 10 THEN 2 -- 已校对（新增）
|
||||
WHEN status_enum = 3 THEN 5 -- 已检查（保留向后兼容旧数据）
|
||||
WHEN status_enum = 2 THEN 1 -- 已签发
|
||||
WHEN status_enum = 5 THEN 7 -- 已作废
|
||||
ELSE 0 -- 待签发
|
||||
END
|
||||
```
|
||||
|
||||
### 3. 修改护士校对方法
|
||||
`ServiceRequestServiceImpl.updateCompleteRequestStatus()` 中 status_enum 从 3 (COMPLETED) 改为 10 (PROOFREAD)。
|
||||
|
||||
### 4. 医技接收后状态流转
|
||||
医技接收时将 status_enum 从 10 (PROOFREAD) 更新为 11 (PENDING_RECEIVE)→12 (RECEIVED)，检查后更新为 3 (COMPLETED)。
|
||||
|
||||
## 涉及文件
|
||||
1. `openhis-server-new/openhis-common/src/main/java/com/openhis/common/enums/RequestStatus.java` — 枚举新增
|
||||
2. `openhis-server-new/openhis-application/src/main/resources/mapper/regdoctorstation/RequestFormManageAppMapper.xml` — SQL CASE 修复
|
||||
3. `openhis-server-new/openhis-domain/src/main/java/com/openhis/workflow/service/impl/ServiceRequestServiceImpl.java` — 校对方法修改
|
||||