3.6 KiB
3.6 KiB
房务驳回后订单详情旧住宿需求展示(前端待处理)
背景
房务驳回住宿需求后,旧需求不会删除。后端会把旧版本保留为历史证据:
order_hotel_requirement.is_active = 0order_hotel_requirement.status = REJECTED_TO_CONSULTANT或REJECTED_TO_ADMIN- 原始
days、候选酒店、房型、备注、特殊诉求仍保留
当前订单详情行程 Tab 只读取当前 active 住宿需求:
GET /v3/admin/order/{orderId}/itinerary- 驳回后该接口里的
hotelGroup.requirement = null
所以前端不能因为 hotelGroup.requirement 为空,就直接展示“尚未提交房型需求”。如果该订单存在历史住宿需求,旧需求也必须展示出来,但只能只读展示。
前端需要调整
订单详情页「行程安排 / 住宿安排」卡片:
- 继续优先展示当前生效住宿需求:
GET /v3/admin/order/{orderId}/itinerary的hotelGroup.requirement。 - 当
hotelGroup.requirement == null时,额外读取历史需求接口:
GET /admin/house/orders/{orderId}/requirement-history
- 如果历史接口返回
list.length > 0,住宿卡片不能只显示“尚未提交房型需求”,需要增加“历史需求”区域,展示旧版本需求内容。 - 历史需求使用
list[].snapshot.days渲染,字段结构包含dayNumber / stayDate / city / segments / candidates / rooms。 - 被驳回的旧需求必须只读,不允许出现以下动作:
- 修改需求
- 删除需求
- 配房
- 替换房型
- 最终确认
- 当前无 active 需求但存在驳回历史时,“提交房型需求”仍可展示,用于定制师重新提交全新需求版本。
历史接口字段口径
接口:
GET /admin/house/orders/{orderId}/requirement-history
关键字段:
{
"list": [
{
"version": 1,
"isCurrent": false,
"status": "REJECTED_TO_CONSULTANT",
"currentBadge": {
"label": "已驳回",
"color": "red",
"tooltip": "本版已被房务驳回, 仅作为历史需求保留"
},
"submittedAt": "2026-07-07 09:24:39",
"returnReason": "驳回原因",
"returnedAt": "2026-07-07 09:34:28",
"snapshot": {
"requirementId": "2074303548706701314",
"version": 1,
"isActive": false,
"status": "REJECTED_TO_CONSULTANT",
"days": []
}
}
]
}
展示建议:
- 标题:
历史需求/已驳回需求 - 徽章优先用
currentBadge.label,没有时按status字典展示。 - 驳回原因优先用
returnReason,没有时不展示原因行。 - 需求内容用
snapshot.days,不要把历史snapshot映射成当前roomRequest,否则会误打开“修改需求”链路。
验收口径
- 已驳回且无 active 需求的订单,住宿卡片仍能看到旧需求内容。
- 页面可继续展示“提交房型需求”,用于重新发起全新需求。
- 旧需求没有修改、删除、配房、替换、最终确认入口。
- 当前 active 需求存在时,仍按原逻辑展示当前需求,不需要默认展开历史。
- 历史需求展示不影响房务抢单池;只有重新提交的新 active 需求才进入抢单池。
测试环境实测样例
订单:
orderId = 2074303545149980674orderNo = HL20260707092437709
现象:
GET /v3/admin/order/2074303545149980674/itineraryhotelGroup.requirement = null
GET /admin/house/orders/2074303545149980674/requirement-historylist.length = 1list[0].status = REJECTED_TO_CONSULTANTlist[0].snapshot.days有原始 2 晚住宿需求