# 已配房修改需求后房务弹窗缺少替换和最终确认按钮（前端待处理）

- 日期：2026-07-06
- 端：管理后台
- 页面：房务订单详情弹窗 / 订单详情进入的房务查看弹窗
- 示例订单：`HL20260703140009570`
- 订单 ID：`2072923330129653762`
- 当前结论：不是后端状态没改全。后端已返回待最终确认、可编辑、可最终确认；前端弹窗没有显示“配房/替换”和“最终确认”按钮，需要检查只读入口或动作渲染门控。

## 复现场景

完成配房的订单再次修改住宿需求后：

- 订单详情住宿安排已显示“房控处理中”。
- 房务详情弹窗顶部流程显示“待最终确认”。
- 但配房行右侧没有“配房/替换”入口。
- 底部没有“最终确认”按钮。

业务期望：

- 修改需求后，历史配房不自动消失，保留给房务人工核对。
- 房务可以在当前配房基础上重新进入“配房”弹窗替换酒店/房型。
- 房务核对完成后可以点“最终确认”回传定制师。

## 后端接口核对

### 订单行程接口

```http
GET /v3/admin/order/2072923330129653762/itinerary
```

关键返回：

| 字段 | 值 |
|------|----|
| `hotelGroup.requirement.requirementId` | `2074011712880607234` |
| `hotelGroup.requirement.status` | `PROCESSING` |
| `hotelGroup.houseStatus` | `PENDING_FINALIZE` |
| `hotelGroup.houseStatusLabel` | `待最终确认` |
| `hotelGroup.finalized` | `false` |
| `hotelGroup.returnStatusLabel` | `待最终确认` |
| `hotelGroup.assignments.length` | `2` |

### 房务详情接口

```http
GET /admin/house/orders/2072923330129653762
```

关键返回：

| 字段 | 值 |
|------|----|
| `requirement.current.requirementId` | `2074011712880607234` |
| `requirement.current.version` | `2` |
| `requirement.current.isActive` | `true` |
| `requirement.current.status` | `PROCESSING` |
| `progress.houseStatus` | `PENDING_FINALIZE` |
| `progress.houseStatusLabel` | `待最终确认` |
| `progress.arrangedCount / totalCount` | `2 / 2` |
| `claim.isMine` | `true` |
| `permissions.canEdit` | `true` |
| `actions.canFinalize.enabled` | `true` |
| `actions.canFinalize.endpoint` | `POST /admin/house/assignments/requirements/2074011712880607234/finalize` |

按天数据也正常带当前需求 ID：

| day | `itinerary[].requirementId` | `arrange` | `assignments.length` |
|-----|-----------------------------|-----------|----------------------|
| 1 | `2074011712880607234` | `confirmed` | `1` |
| 2 | `2074011712880607234` | `confirmed` | `1` |

结论：后端已把新版本住宿需求设为 active，房务状态已回到 `PENDING_FINALIZE`，并且返回了可编辑与可最终确认动作。不是状态没改全。

## 前端排查方向

本地 `v2.1` 前端代码中，房务详情弹窗会通过 `isReadonly` 隐藏所有写操作：

```js
const isReadonly = computed(
  () => isLead.value || props.readonly || (!isPool.value && detail.value?.claim?.isMine === false),
)
```

配房/替换入口：

```vue
<n-button v-if="!isReadonly && !isException" ...>
  配房
</n-button>
```

最终确认入口：

```vue
<n-tooltip v-if="!isReadonly" ...>
  <n-button :disabled="!canFinalize">最终确认</n-button>
</n-tooltip>
```

如果截图入口来自订单详情查看、房务日历、组长视角、非本人订单，前端现有逻辑会按只读处理，按钮被隐藏。

如果入口来自房务“我的订单/待办”，当前接口已经返回：

- `claim.isMine=true`
- `permissions.canEdit=true`
- `actions.canFinalize.enabled=true`
- `progress.houseStatus=PENDING_FINALIZE`

这种情况下仍不显示按钮，则属于前端只读门控或动作渲染没有跟接口状态对齐。

## 前端处理要求

1. 在房务“我的订单/待办”等可处理入口中，`PENDING_FINALIZE` 且 `claim.isMine=true` / `permissions.canEdit=true` 时，应显示按天“配房”按钮，用于替换当前酒店/房型。
2. 同一状态下应显示“最终确认”按钮；可优先使用 `actions.canFinalize.enabled` 和 `actions.canFinalize.endpoint`，避免前端自行推导错。
3. 如果从订单详情或日历进入确实只读，需要在 UI 上明确区分“只读查看”和“房务处理入口”，避免测试误以为状态不可操作。
4. 不要要求后端删除旧配房；历史配房应作为当前待核对数据保留，房务通过配房弹窗提交替换。

## 相关接口

替换/重新提交某天配房：

```http
POST /v3/admin/order/hotel-requirements/{requirementId}/assignments
```

最终确认：

```http
POST /admin/house/assignments/requirements/{requirementId}/finalize
```