hl-api-changelog/changelogs-v2/2026-07/69_房务最终确认后修改配房按钮被旧前端隐藏-前端待处理.md

房务最终确认后修改配房按钮被旧前端隐藏（前端待处理）

目标前端

• 端类型：管理后台（Web）
• 目标仓库：mmg/hl-ui
• 仓库地址：https://git.1814.love:8443/mmg/hl-ui.git
• 前端本地测试环境：http://192.168.100.160:9527
• 小程序：无需处理

本通知应由管理后台前端负责人在 mmg/hl-ui 处理，不属于后端仓库 wx/HL，也不属于小程序前端。

现象

订单 HL20260719151313174 已最终确认、配房进度 2/2，房务详情配房行程只显示“询房”按钮；既有配房行未显示“替换”“改协议价”“移除”等修改入口。

业务要求：最终确认后房务仍可修改配房。发起修改时先将住宿需求从完成态解冻回配房中，再执行替换、移除、改价等操作。

已确认原因

192.168.100.160:9527 当前 Vite 服务实际返回的 OrderDetailModal.vue 仍包含旧门槛：

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 源码已经改为：

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 或对应写接口自动解冻，操作成功，房务状态回到配房中。
• 重新配房并逐日确认后，可再次最终确认。
• 非本人、驳回、作废及只读入口仍不显示写操作。