docs: 修正房务旧需求同屏展示口径
这个提交包含在:
父节点
162c0ca6d8
当前提交
6f1945966e
@ -13,28 +13,32 @@
|
|||||||
- `GET /v3/admin/order/{orderId}/itinerary`
|
- `GET /v3/admin/order/{orderId}/itinerary`
|
||||||
- 驳回后该接口里的 `hotelGroup.requirement = null`
|
- 驳回后该接口里的 `hotelGroup.requirement = null`
|
||||||
|
|
||||||
所以前端不能因为 `hotelGroup.requirement` 为空,就直接展示“尚未提交房型需求”。如果该订单存在历史住宿需求,旧需求也必须展示出来,但只能只读展示。
|
所以前端不能只依赖 `hotelGroup.requirement` 判断住宿需求展示。
|
||||||
|
|
||||||
|
最新修正:即使订单已经有新的 active 住宿需求,旧的历史需求也要展示。历史需求不是空态兜底,而是订单详情住宿卡片的固定只读历史区。
|
||||||
|
|
||||||
## 前端需要调整
|
## 前端需要调整
|
||||||
|
|
||||||
订单详情页「行程安排 / 住宿安排」卡片:
|
订单详情页「行程安排 / 住宿安排」卡片:
|
||||||
|
|
||||||
1. 继续优先展示当前生效住宿需求:`GET /v3/admin/order/{orderId}/itinerary` 的 `hotelGroup.requirement`。
|
1. 继续优先展示当前生效住宿需求:`GET /v3/admin/order/{orderId}/itinerary` 的 `hotelGroup.requirement`。
|
||||||
2. 当 `hotelGroup.requirement == null` 时,额外读取历史需求接口:
|
2. 无论 `hotelGroup.requirement` 是否为空,都要读取历史需求接口:
|
||||||
|
|
||||||
```http
|
```http
|
||||||
GET /admin/house/orders/{orderId}/requirement-history
|
GET /admin/house/orders/{orderId}/requirement-history
|
||||||
```
|
```
|
||||||
|
|
||||||
3. 如果历史接口返回 `list.length > 0`,住宿卡片不能只显示“尚未提交房型需求”,需要增加“历史需求”区域,展示旧版本需求内容。
|
3. 如果历史接口返回 `list.length > 0`,住宿卡片需要增加“历史需求”区域,展示旧版本需求内容。
|
||||||
4. 历史需求使用 `list[].snapshot.days` 渲染,字段结构包含 `dayNumber / stayDate / city / segments / candidates / rooms`。
|
4. 历史区只展示旧版本:建议过滤掉 `isCurrent=true` 或 `snapshot.isActive=true` 的当前生效版本,避免当前需求重复显示。
|
||||||
5. 被驳回的旧需求必须只读,不允许出现以下动作:
|
5. 历史需求使用 `list[].snapshot.days` 渲染,字段结构包含 `dayNumber / stayDate / city / segments / candidates / rooms`。
|
||||||
|
6. 被驳回或失效的旧需求必须只读,不允许出现以下动作:
|
||||||
- 修改需求
|
- 修改需求
|
||||||
- 删除需求
|
- 删除需求
|
||||||
- 配房
|
- 配房
|
||||||
- 替换房型
|
- 替换房型
|
||||||
- 最终确认
|
- 最终确认
|
||||||
6. 当前无 active 需求但存在驳回历史时,“提交房型需求”仍可展示,用于定制师重新提交全新需求版本。
|
7. 当前无 active 需求但存在驳回历史时,“提交房型需求”仍可展示,用于定制师重新提交全新需求版本。
|
||||||
|
8. 当前有 active 新需求时,仍然展示当前需求的“修改需求/加急/联系房务”等正常动作;历史旧需求只读,不影响当前需求操作。
|
||||||
|
|
||||||
## 历史接口字段口径
|
## 历史接口字段口径
|
||||||
|
|
||||||
@ -75,17 +79,19 @@ GET /admin/house/orders/{orderId}/requirement-history
|
|||||||
|
|
||||||
展示建议:
|
展示建议:
|
||||||
|
|
||||||
- 标题:`历史需求` / `已驳回需求`
|
- 标题:`历史需求` / `已驳回需求` / `旧需求`
|
||||||
- 徽章优先用 `currentBadge.label`,没有时按 `status` 字典展示。
|
- 徽章优先用 `currentBadge.label`,没有时按 `status` 字典展示。
|
||||||
- 驳回原因优先用 `returnReason`,没有时不展示原因行。
|
- 驳回原因优先用 `returnReason`,没有时不展示原因行。
|
||||||
- 需求内容用 `snapshot.days`,不要把历史 `snapshot` 映射成当前 `roomRequest`,否则会误打开“修改需求”链路。
|
- 需求内容用 `snapshot.days`,不要把历史 `snapshot` 映射成当前 `roomRequest`,否则会误打开“修改需求”链路。
|
||||||
|
- 当前 active 新需求和历史旧需求要能同屏出现;历史区可折叠,但不能完全不展示。
|
||||||
|
|
||||||
## 验收口径
|
## 验收口径
|
||||||
|
|
||||||
- 已驳回且无 active 需求的订单,住宿卡片仍能看到旧需求内容。
|
- 已驳回且无 active 需求的订单,住宿卡片仍能看到旧需求内容。
|
||||||
|
- 已有 active 新需求的订单,住宿卡片仍能看到旧需求内容。
|
||||||
- 页面可继续展示“提交房型需求”,用于重新发起全新需求。
|
- 页面可继续展示“提交房型需求”,用于重新发起全新需求。
|
||||||
- 旧需求没有修改、删除、配房、替换、最终确认入口。
|
- 旧需求没有修改、删除、配房、替换、最终确认入口。
|
||||||
- 当前 active 需求存在时,仍按原逻辑展示当前需求,不需要默认展开历史。
|
- 当前 active 需求存在时,当前需求仍按原逻辑展示,同时展示旧需求历史区。
|
||||||
- 历史需求展示不影响房务抢单池;只有重新提交的新 active 需求才进入抢单池。
|
- 历史需求展示不影响房务抢单池;只有重新提交的新 active 需求才进入抢单池。
|
||||||
|
|
||||||
## 测试环境实测样例
|
## 测试环境实测样例
|
||||||
@ -103,4 +109,3 @@ GET /admin/house/orders/{orderId}/requirement-history
|
|||||||
- `list.length = 1`
|
- `list.length = 1`
|
||||||
- `list[0].status = REJECTED_TO_CONSULTANT`
|
- `list[0].status = REJECTED_TO_CONSULTANT`
|
||||||
- `list[0].snapshot.days` 有原始 2 晚住宿需求
|
- `list[0].snapshot.days` 有原始 2 晚住宿需求
|
||||||
|
|
||||||
|
|||||||
正在加载...
x
在新工单中引用
屏蔽一个用户