From 1eaff7273fe17284cdede0f76599b4c939bc6eb1 Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Tue, 11 Aug 2026 17:37:11 +0800 Subject: [PATCH] =?UTF-8?q?changelog(#5842):=20=E6=88=BF=E5=8A=A1=E6=9C=80?= =?UTF-8?q?=E7=BB=88=E7=A1=AE=E8=AE=A4=E6=94=BE=E5=BC=80=E9=83=A8=E5=88=86?= =?UTF-8?q?=E9=85=8D=E6=88=BF=20+=20=E6=9C=AA=E9=85=8D/=E6=9C=AA=E7=A1=AE?= =?UTF-8?q?=E8=AE=A4=E6=99=9A=E5=8F=B7=E5=AD=97=E6=AE=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...务最终确认放开部分配房-修改接口-管理后台.md | 97 +++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 changelogs-v2/2026-08/11_5842_房务最终确认放开部分配房-修改接口-管理后台.md diff --git a/changelogs-v2/2026-08/11_5842_房务最终确认放开部分配房-修改接口-管理后台.md b/changelogs-v2/2026-08/11_5842_房务最终确认放开部分配房-修改接口-管理后台.md new file mode 100644 index 0000000..9508a8a --- /dev/null +++ b/changelogs-v2/2026-08/11_5842_房务最终确认放开部分配房-修改接口-管理后台.md @@ -0,0 +1,97 @@ +--- +schema: "hl-changelog/v2" +ticket: "5842" +title: "房务最终确认取消「必须每晚配齐」限制：部分配房/未确认行放行 + 新增未配/未确认晚号字段" +consumer: "admin" +change_type: "修改接口" +author: "wx(GIT)" +backend_status: "deployed" +gateway_status: "not_required" +frontend_status: "pending" +frontend_owner: "mmg" +frontend_ref: "" +target_release: "" +verified_at: "2026-08-11" +status_note: "" +updated_at: "2026-08-11" +base: "dev-v3" +--- + +# 房务最终确认：取消「必须每晚配齐」限制（#5842） + +> **服务**: hl-order-service-v3 +> **PR**: #5860（已合并 dev-v3 并部署测试服） +> **日期**: 2026-08-11 +> **背景**: 房务「最终确认」原要求每一晚都配房且全部已确认，否则按钮灰掉并提示「配房与当前行程不一致，请调整后再确认」。现场 26-7666（6 天 5 晚）配了 DAY1/2、DAY3/4/5 待配 → 房务无法收口。wx 要求取消该限制，改为二次确认。 + +--- + +## 变更接口 + +### 1. `GET /admin/house/orders/{orderId}` —— `actions.canFinalize` 放开条件 + +**旧行为**：只有「每晚都配齐且全部已确认」或「一晚都没配（客人全程自住）」两种情况可最终确认；**部分配房一律禁用**。 + +**新行为**：**部分配房、存在未确认配房行，均可最终确认**。 + +| 情况 | 旧 | 新 | +|---|---|---| +| 每晚配齐且已确认 | ✅ | ✅ 不变 | +| 一晚都没配 | ✅ | ✅ 不变 | +| **部分晚没配房** | ❌ 禁用 | ✅ **放开** | +| **配了但还没确认** | ❌ 禁用 | ✅ **放开** | +| 配房日期与当前行程错位 | ❌ 禁用 | ❌ **仍禁用** | + +`disabledReason` 在放开后不再出现因部分配房产生的文案；日期错位时文案为「配房日期与当前行程不一致，请调整后再确认」。 + +> ⚠️ **日期错位仍然硬拦**：这是订单改期后残留的旧配房行，放行会把过期日期的房当成有效配房回传给定制师、直接坏数据（与 `pendingRescheduleAssignments` 互为兜底）。前端不要试图绕过。 + +### 2. `progress` 新增两个字段（供二次确认弹窗） + +```json +"progress": { + "arrangedCount": 1, + "totalCount": 5, + "unarrangedDayNumbers": [1, 2, 3, 5], // 【新增】还没配房的晚号 + "unconfirmedDayNumbers": [4] // 【新增】配了但还没确认的晚号 +} +``` + +| 字段 | 类型 | 说明 | +|---|---|---| +| `unarrangedDayNumbers` | `List` | 未配房的晚号，升序 | +| `unconfirmedDayNumbers` | `List` | 已配房但 `confirmStatus != CONFIRMED` 的晚号，升序 | + +两者**互斥**（同一晚不会同时出现在两个列表里），都为空数组时即配齐且全确认。 + +**为什么要加这两个字段**：`arrangedCount/totalCount` 只有数量，说不出「缺的是第 3、4、5 晚」，更完全无法表达「配了但酒店还没回复确认」——而这恰恰是本次放开的两类情况，二次确认文案必须分开说，否则房务不知道自己在确认什么。 + +--- + +## 前端要做 + +`canFinalize.enabled` 为 true 且 `unarrangedDayNumbers` 或 `unconfirmedDayNumbers` **非空**时，点「最终确认」先弹二次确认，文案把两类情况分开列，例如： + +``` +还有第 1、2、3、5 晚未配房，第 4 晚已配房但酒店尚未确认。 +确认要完成配房吗？ +``` + +两个列表都为空时（配齐且全确认）保持原有直接确认流程，不弹二次确认。 + +`disabledReason` 直接透传展示即可，不需要再针对「配房与当前行程不一致」做特殊分支——该文案现在只在真正的日期错位时出现。 + +--- + +## 验证证据 + +2026-08-11 测试服（网关 `https://api.test.1814.love:9443`，房务管理员 token）实测两个真实的部分配房订单： + +| 订单 | 进度 | `unarrangedDayNumbers` | `unconfirmedDayNumbers` | `disabledReason` | +|---|---|---|---|---| +| 26-3420 | 1/5 | `[1,2,3,5]` | `[4]` | 仅本人持有的订单可最终确认（权限原因，非覆盖度） | +| 26-3281 | 1/2 | `[2]` | `[1]` | 同上 | + +两单的 `disabledReason` 均已不再是「配房与当前行程不一致」，证明覆盖度拦截确已解除；字段互斥升序、数值与实际配房状态一致。 + +单测：`hl-order-service-v3` 全量 **586 类 / 7512 tests，0 failures 0 errors**，ArchTest 门禁 44 绿。核心逻辑通过**双向变异验证**：退回放开逻辑 → 7 个用例红（覆盖度层 2 / 读口 2 / 写口 3）；误把日期错位也放开 → 4 个用例红（含「未确认 + 旧日期」脏行场景）。