From 6f1945966e8166ee23b3929386e6d26f2361172c Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Tue, 7 Jul 2026 09:54:52 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E4=BF=AE=E6=AD=A3=E6=88=BF=E5=8A=A1?= =?UTF-8?q?=E6=97=A7=E9=9C=80=E6=B1=82=E5=90=8C=E5=B1=8F=E5=B1=95=E7=A4=BA?= =?UTF-8?q?=E5=8F=A3=E5=BE=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...订单详情旧住宿需求展示-前端待处理-管理后台.md | 23 +++++++++++-------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/changelogs-v2/2026-07/34_房务驳回后订单详情旧住宿需求展示-前端待处理-管理后台.md b/changelogs-v2/2026-07/34_房务驳回后订单详情旧住宿需求展示-前端待处理-管理后台.md index 2a4c90b..890c645 100644 --- a/changelogs-v2/2026-07/34_房务驳回后订单详情旧住宿需求展示-前端待处理-管理后台.md +++ b/changelogs-v2/2026-07/34_房务驳回后订单详情旧住宿需求展示-前端待处理-管理后台.md @@ -13,28 +13,32 @@ - `GET /v3/admin/order/{orderId}/itinerary` - 驳回后该接口里的 `hotelGroup.requirement = null` -所以前端不能因为 `hotelGroup.requirement` 为空，就直接展示“尚未提交房型需求”。如果该订单存在历史住宿需求，旧需求也必须展示出来，但只能只读展示。 +所以前端不能只依赖 `hotelGroup.requirement` 判断住宿需求展示。 + +最新修正：即使订单已经有新的 active 住宿需求，旧的历史需求也要展示。历史需求不是空态兜底，而是订单详情住宿卡片的固定只读历史区。 ## 前端需要调整 订单详情页「行程安排 / 住宿安排」卡片： 1. 继续优先展示当前生效住宿需求：`GET /v3/admin/order/{orderId}/itinerary` 的 `hotelGroup.requirement`。 -2. 当 `hotelGroup.requirement == null` 时，额外读取历史需求接口： +2. 无论 `hotelGroup.requirement` 是否为空，都要读取历史需求接口： ```http GET /admin/house/orders/{orderId}/requirement-history ``` -3. 如果历史接口返回 `list.length > 0`，住宿卡片不能只显示“尚未提交房型需求”，需要增加“历史需求”区域，展示旧版本需求内容。 -4. 历史需求使用 `list[].snapshot.days` 渲染，字段结构包含 `dayNumber / stayDate / city / segments / candidates / rooms`。 -5. 被驳回的旧需求必须只读，不允许出现以下动作： +3. 如果历史接口返回 `list.length > 0`，住宿卡片需要增加“历史需求”区域，展示旧版本需求内容。 +4. 历史区只展示旧版本：建议过滤掉 `isCurrent=true` 或 `snapshot.isActive=true` 的当前生效版本，避免当前需求重复显示。 +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` 字典展示。 - 驳回原因优先用 `returnReason`，没有时不展示原因行。 - 需求内容用 `snapshot.days`，不要把历史 `snapshot` 映射成当前 `roomRequest`，否则会误打开“修改需求”链路。 +- 当前 active 新需求和历史旧需求要能同屏出现；历史区可折叠，但不能完全不展示。 ## 验收口径 - 已驳回且无 active 需求的订单，住宿卡片仍能看到旧需求内容。 +- 已有 active 新需求的订单，住宿卡片仍能看到旧需求内容。 - 页面可继续展示“提交房型需求”，用于重新发起全新需求。 - 旧需求没有修改、删除、配房、替换、最终确认入口。 -- 当前 active 需求存在时，仍按原逻辑展示当前需求，不需要默认展开历史。 +- 当前 active 需求存在时，当前需求仍按原逻辑展示，同时展示旧需求历史区。 - 历史需求展示不影响房务抢单池；只有重新提交的新 active 需求才进入抢单池。 ## 测试环境实测样例 @@ -103,4 +109,3 @@ GET /admin/house/orders/{orderId}/requirement-history - `list.length = 1` - `list[0].status = REJECTED_TO_CONSULTANT` - `list[0].snapshot.days` 有原始 2 晚住宿需求 -