134 行
4.6 KiB
Markdown
134 行
4.6 KiB
Markdown
# 已配房修改需求后房务弹窗缺少替换和最终确认按钮（前端待处理）
|
||
|
||
- 日期：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
|
||
```
|
||
|