docs: 通知完成态配房按钮被隐藏
这个提交包含在:
父节点
319cc684ac
当前提交
bf138d29d3
@ -0,0 +1,56 @@
|
||||
# 房务最终确认后修改配房按钮被旧前端隐藏(前端待处理)
|
||||
|
||||
## 现象
|
||||
|
||||
订单 `HL20260719151313174` 已最终确认、配房进度 `2/2`,房务详情配房行程只显示“询房”按钮;既有配房行未显示“替换”“改协议价”“移除”等修改入口。
|
||||
|
||||
业务要求:最终确认后房务仍可修改配房。发起修改时先将住宿需求从完成态解冻回配房中,再执行替换、移除、改价等操作。
|
||||
|
||||
## 已确认原因
|
||||
|
||||
`192.168.100.160:9527` 当前 Vite 服务实际返回的 `OrderDetailModal.vue` 仍包含旧门槛:
|
||||
|
||||
```js
|
||||
const canMutateRequirement = computed(
|
||||
() =>
|
||||
canEditHouseOrder.value &&
|
||||
!requirementReadOnly.value &&
|
||||
(merged.value?.finalized !== true || merged.value?.reopenAction?.enabled === true)
|
||||
)
|
||||
```
|
||||
|
||||
后端详情当前有意将 `reopenAction` 设为 disabled,不再把“回配”作为单独按钮;后端各直接编辑入口会调用 `reopenIfFinalizedForDirectEdit()` 自动解冻。因此旧前端条件在 `finalized=true` 时恒为 false,连真正的修改按钮也全部隐藏。
|
||||
|
||||
当前 `D:/work2/hl-ui` 源码已经改为:
|
||||
|
||||
```js
|
||||
const canMutateRequirement = computed(
|
||||
() => canEditHouseOrder.value && !requirementReadOnly.value
|
||||
)
|
||||
```
|
||||
|
||||
并由 `ensureRequirementEditable(reqId)` 在写操作前调用 `reopenRequirement(reqId)`,与后端自动解冻语义一致。
|
||||
|
||||
## 前端处理要求
|
||||
|
||||
1. 同步当前 `D:/work2/hl-ui` 正确实现到 `192.168.100.160:9527` 实际运行工作树,重启 Vite 服务。
|
||||
2. `canMutateRequirement` 不得用 `finalized` 或 `reopenAction.enabled` 隐藏配房修改入口。
|
||||
3. 最终确认后,只要订单属于当前房务、需求仍生效且未驳回/作废,应继续显示:
|
||||
- 当晚“替换”;
|
||||
- 已确认配房行“改协议价”;
|
||||
- 已确认配房行“移除”。
|
||||
4. 写操作前沿用 `ensureRequirementEditable()`;不得要求用户先点击一个独立“回配”按钮。
|
||||
5. 驳回需求、作废需求、非本人订单、组长只读入口仍保持只读,不得放宽权限边界。
|
||||
|
||||
## 后端依据
|
||||
|
||||
- `HouseAssignmentService.reopenIfFinalizedForDirectEdit()`:最终确认后的直接编辑自动解冻。
|
||||
- 替换、移除、改协议价等多个写入口均已调用该方法。
|
||||
- `HouseDetailAggregator` 不暴露独立 reopen action 属预期行为,不需要后端恢复该按钮。
|
||||
|
||||
## 验收
|
||||
|
||||
- 打开订单 `HL20260719151313174`,完成态仍可看到“替换”“改协议价”“移除”。
|
||||
- 点击修改后 Network 先出现 reopen 或对应写接口自动解冻,操作成功,房务状态回到配房中。
|
||||
- 重新配房并逐日确认后,可再次最终确认。
|
||||
- 非本人、驳回、作废及只读入口仍不显示写操作。
|
||||
正在加载...
x
在新工单中引用
屏蔽一个用户