6.8 KiB
6.8 KiB
订单详情住宿需求任何房务阶段都应保留“修改需求”入口（前端待处理）
- 日期：2026-07-03
- 端：管理后台
- 页面：订单详情 v2 / 住宿安排卡片
- 示例订单：
HL20260703140009401 - 订单 ID：
2072923329412427777 - 当前状态：住宿已回配，流程节点展示“配房已完成”
- 当前结论：后端已支持住宿需求在任意房务阶段继续提出修改，前端需要保留或补回入口。
现象
在订单详情页的「行程安排」页签中，住宿安排进入房务处理后，页面不应隐藏“修改需求”按钮。
已观察到的问题包括：
- 配房中/询房中：前端容易只展示“联系房务”，隐藏“修改需求”。
- 已配房/已回配/配房已完成：前端容易认为流程完成后不可再改，隐藏“修改需求”。
截图复现口径：
- 订单：
HL20260703140009401 - 页面 URL：
/order-v2/detail/2072923329412427777 - 当前卡片只看到「联系房务」和「查看已配房」等入口。
- 业务期望：只要订单有住宿需求，定制师在配房中、询房中、待最终确认、已配房、已回配等房务阶段都可以再次发起“修改需求”。
业务口径
住宿需求任何房务阶段都可以提出修改需求。
“配房中 / 询房中 / 待最终确认 / 已配房 / 配房已完成 / 已回配”都不代表需求不可再调整。前端不要用房务状态判断是否隐藏入口；修改需求入口应作为住宿安排的常驻动作，由提交接口和后端状态机处理后续分支。
2026-07-05 补充复现
新增复现订单：
- 订单：
HL20260703140009570 - 订单 ID：
2072923330129653762 - 页面 URL：
/order-v2/detail/2072923330129653762 - 页面现象：顶部流程节点展示“配房-已完成”，住宿安排卡片只有“联系房务”，没有“修改需求/调整需求”入口。
后端接口复验：
GET /v3/admin/order/2072923330129653762/itinerary
关键返回：
| 字段 | 值 |
|---|---|
hotelGroup.requirement.status |
DONE |
hotelGroup.houseStatus |
CONFIRMED |
hotelGroup.houseStatusLabel |
已完成 |
hotelGroup.finalized |
true |
hotelGroup.returnStatusLabel |
已回配 |
这正是“配房已完成/已回配”场景。该状态下仍允许定制师修改住宿需求，前端不能因为上述状态隐藏入口。
补充口径：不只是完成态可以改，配房中也可以改。后端会按最新 active 需求状态自动判断是草稿编辑还是完成后调整。
2026-07-06 定位补充：不是数据问题，是前端锁定门控误挡按钮
复查订单 HL20260703140009570 / 2072923330129653762：
GET /v3/admin/order/2072923330129653762/itinerary
关键返回确认：
| 字段 | 值 |
|---|---|
hotelGroup.requirement.requirementId |
2072923330259677186 |
hotelGroup.requirement.status |
DONE |
hotelGroup.houseStatus |
CONFIRMED |
hotelGroup.finalized |
true |
hotelGroup.returnStatusLabel |
已回配 |
hotelGroup.assignments.length |
2 |
结论：接口数据中住宿需求没有丢，已配房记录也存在，所以不是后端数据问题。
本地前端 v2.1 代码辅助定位到隐藏原因：
// src/views/order-v2/detail/_shared/v3Adapter.js
lockedAt: m.confirmedAt
// src/views/order-v2/detail/components/RoomArrangeCard.vue
const isLocked = computed(() => !!props.order.lockedAt)
const action = computed(() => {
if (isLocked.value) return null
// ...
})
同一订单主详情返回：
| 字段 | 值 |
|---|---|
main.confirmedAt |
2026-07-03 14:00:09 |
main.flowStatus |
RESOURCE_PREPARING |
main.orderStatus |
CUSTOMIZING |
因此前端把“订单已确认时间 confirmedAt”映射成 lockedAt 后，住宿安排卡片 action 直接返回 null，即使 roomRequest 已存在也不会显示“修改需求”。
前端处理建议：
- 住宿安排卡片不要用
confirmedAt -> lockedAt隐藏“提交/修改需求”入口。 - 只要
order.roomRequest存在，应显示“修改需求”；已配房、已回配、待最终确认都一样。 - 如确实存在整单不可编辑状态，请使用明确的终态/作废/结算完成字段单独判断，不要把
confirmedAt当成住宿需求不可编辑标志。 - 最小修复点可以是移除或替换
RoomArrangeCard.vue中action的if (isLocked.value) return null门控。
前端处理要求
请在订单详情住宿安排模块把“修改需求”作为常驻入口：
- 当订单存在住宿需求时，住宿卡片应显示“修改需求”按钮。
- 点击“修改需求”后复用现有需求编辑/调整弹窗或跳转逻辑。
- 提交后走现有后端需求提交/调整接口，不需要新增后端接口。
- 不要因为
roomControlStatus=PROCESSING/DONE、requirement.status=PROCESSING/DONE、houseStatus=CLAIMING/PENDING_FINALIZE/CONFIRMED、页面展示“配房中/询房中/配房已完成/已回配”就隐藏修改需求入口。
后端接口说明
本次无后端接口变更。
后端已有兼容接口支持提交/修改/调整房型需求：
PUT /v3/admin/order/{id}/hotel-requirement
接口语义：
- 无 active 需求：首次提交。
- active 需求待处理：编辑当前需求。
- 配房中/已抢单/已发询房/已配房/已回配需求：提交修改需求，生成新版本或触发房务重新处理。
前端只需要恢复入口和调用现有提交流程。
源码契约中该接口的说明为：
提交/修改/调整房型需求（三分支自动判断：无 active=INIT_SUBMIT，PENDING=PENDING_EDIT，DONE=DONE_ADJUST）
源码实际分支：
| 当前 active 需求状态 | 后端分支 | 前端理解 |
|---|---|---|
| 无 active | INIT_SUBMIT |
首次提交住宿需求 |
PENDING / PENDING_REVIEW |
PENDING_EDIT |
待处理需求编辑 |
DONE / PROCESSING / REJECTED_* |
DONE_ADJUST |
配房中或完成后调整 |
如果前端已经迁移到统一订单调整接口，也可以继续复用现有的“修改需求”提交流程提交 updates.hotelRequirement；关键是页面入口不要因任何房务子流程状态被隐藏。
验收标准
HL20260703140009401这类已配房订单，在住宿安排卡片可看到“修改需求”入口。HL20260703140009570这类requirement.status=DONE、页面显示“配房-已完成”的订单，也能看到“修改需求”入口。requirement.status=PROCESSING或页面显示“配房中/询房中”的订单，也能看到“修改需求”入口。- 点击后可打开现有需求编辑/调整弹窗。
- 提交修改后页面能看到新需求/修改记录，房务侧进入重新处理链路。
- “联系房务”“查看已配房”等已有按钮不受影响。