From 5d65d2c241a5fbec5b23f5316846c16519faa6ed Mon Sep 17 00:00:00 2001
From: API Changelog Bot <changelog@hulalv.com>
Date: Wed, 1 Jul 2026 17:03:56 +0800
Subject: [PATCH] =?UTF-8?q?docs(changelog-v2):=20=E6=88=BF=E5=8A=A1?=
 =?UTF-8?q?=E8=AE=A2=E5=8D=95=E8=AF=A6=E6=83=85=E6=96=B0=E5=A2=9E=20canReo?=
 =?UTF-8?q?pen=20=E6=A0=87=E5=BF=97=EF=BC=8C=E5=89=8D=E7=AB=AF=E5=81=9C?=
 =?UTF-8?q?=E7=94=A8=E5=9B=9E=E9=85=8D=E5=90=AF=E5=8F=91=E5=BC=8F=20(#4706?=
 =?UTF-8?q?)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

后端 PR #4707 修 bug.docx「未最终确认却显示回配」：GET /admin/house/orders/{orderId}
的 data.actions 新增 canReopen（enabled 仅当 house_status=CONFIRMED 且本人持有），
前端「回配」按钮改读 actions.canReopen.enabled，停用基于共享 PROCESSING/CLAIMING 列的
启发式。附带告知同批红点/待办后端修复(前端无需改)。已测试服 API 实测。
---
 ...��回配按钮canReopen标志-修改接口-管理后台.md | 44 +++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 changelogs-v2/2026-07/07_4706_房务回配按钮canReopen标志-修改接口-管理后台.md

diff --git a/changelogs-v2/2026-07/07_4706_房务回配按钮canReopen标志-修改接口-管理后台.md b/changelogs-v2/2026-07/07_4706_房务回配按钮canReopen标志-修改接口-管理后台.md
new file mode 100644
index 0000000..929c297
--- /dev/null
+++ b/changelogs-v2/2026-07/07_4706_房务回配按钮canReopen标志-修改接口-管理后台.md
@@ -0,0 +1,44 @@
+# 房务订单详情新增显式「回配」动作标志 `canReopen`——前端停用启发式判断
+
+> 模块：管理后台 · 房控台 · 房务订单详情
+> 类型：**后端修改(已合并 dev-v3 + 部署测试服 + API 实测)** + 前端接入
+> 日期：2026-07-01 · 关联 PR #4707 / 工单 #4706
+> 背景：反馈「还没最终确认的订单为什么显示回配」。根因是后端原先**不产任何『已确认可回配』信号**，前端只能靠 `house_status=CLAIMING` / `status=PROCESSING` 等**共享状态列启发式**判断「回配」——而 reopen 把已确认单退回后与「首次配房中」逐列一致，故这些共享列对**未最终确认的普通配房中订单同样命中**，必然误显回配。现后端补显式标志，前端改读它。
+
+## 【前端 · 房控台】需改动
+
+### 房务订单详情 `actions` 新增 `canReopen`
+`GET /admin/house/orders/{orderId}` → `data.actions` 现在除 `canTransfer` / `canFinalize` 外，**新增 `canReopen`**（与前两者同结构）：
+
+```json
+"actions": {
+  "canTransfer": { "enabled": ..., "code": "TRANSFER", "label": "转单", ... },
+  "canFinalize": { "enabled": ..., "code": "FINALIZE", "label": "最终确认", ... },
+  "canReopen":   {
+    "enabled": true,
+    "code": "REOPEN",
+    "label": "回配",
+    "disabledReason": null,
+    "endpoint": "POST /admin/order/hotel-requirements/{requirementId}/reopen"
+  }
+}
+```
+
+- **`enabled`**：`true` **当且仅当** `house_status=CONFIRMED`（已最终确认）**且**当前登录人是该单房务持有人（claimer）。与 reopen 接口服务端守卫同源。
+- **`disabledReason`**：`enabled=false` 时给禁用文案——非已确认→「仅已最终确认的订单可回配」；已确认但非本人持有→「仅本人持有的订单可回配」。
+- **`label`**：固定「回配」。
+
+### 前端改法（关键）
+1. 「回配」按钮的**显隐 / 可点**改为**只读 `actions.canReopen.enabled`**，按钮文案用 `actions.canReopen.label`，禁用态可展示 `disabledReason`。
+2. **停用**原先基于 `house_status==CLAIMING` / `status==PROCESSING` / `room_control_status==PROCESSING` 的「回配」启发式判断——这是本次误显的根因（未最终确认的配房中订单会被误判成回配）。
+3. 点击「回配」仍调既有接口（**未变**）：`POST /v3/admin/order/hotel-requirements/{requirementId}/reopen`（requirementId 取详情 `current.requirementId`，或直接用 `canReopen.endpoint` 提示的路径）。
+
+## 已验证（测试服 API 实测）
+- `GET /admin/house/orders/2071784830965620737`（house_status=CONFIRMED 且本人持有）→ `actions.canReopen = {enabled:true, code:"REOPEN", label:"回配", disabledReason:null, endpoint:".../reopen"}`。
+- 未确认（配房中）/ 非本人持有 → `enabled=false` + 对应 `disabledReason`（单测覆盖）。
+- 操作日志 opTypeLabel：`REOPEN` 现显示中文「回配」（原显示英文 REOPEN）。
+
+## 同批后端修复（无需前端改动，告知即可）
+本批 PR #4707 一并修了另外两项房务缺陷，**前端无需改**：
+1. **房务主动给定制师发起会话 → 定制师端「联系房务」红点现会点亮**：原房务发起时消息落留言池、从不累加定制师未读，现已修（后端 `open-house` 以订单定制师为锚判定开会话方）。前端红点仍读原有 `unreadMessageCount`，**自动生效**。
+2. **已完成配房（CONFIRMED）的订单不再滞留房务待办列表**：finalize 兜底 RESOLVE 相关待办 + 待办「定制师消息未读」派生项跳过已确认单。待办列表接口/字段**不变**。