From 4a38a8d4926f67fee0afcd6adfe186d9b54cb51f Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Tue, 22 Sep 2026 22:26:18 +0800 Subject: [PATCH] =?UTF-8?q?docs(user):=20=E5=9B=A2=E6=9C=9F=E6=88=BF?= =?UTF-8?q?=E5=8A=A1=E4=B8=89=E4=BA=8B=E4=BB=B6=E8=A1=A5=E7=AB=99=E5=86=85?= =?UTF-8?q?=E4=BF=A1=E9=85=8D=E7=BD=AE=E8=A1=8C=EF=BC=8C=E7=AE=A1=E7=90=86?= =?UTF-8?q?=E5=90=8E=E5=8F=B0=E6=96=B0=E5=A2=9E=E4=B8=89=E7=B1=BB=E6=B6=88?= =?UTF-8?q?=E6=81=AF=20(#8193)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 三个 GROUP_BATCH_* 事件一直在发但 notification_event_config 无配置行， 分发器因此零产出。补齐后房管角色(ROOM_MANAGER)收件箱新增三类消息， link 落 /housekeeper/grab-pool-group，hl-ui 已有通用 link 分支可直接跳， mmg 零改动 => frontend_status=not_required。 同时记录三处前端看不见的配置变更(删两条无发布方的询房行、换店两条 inapp 关闭、TRAVELER_INCOMPLETE_DAILY 企微关闭)，以免被误读为回归。 Co-Authored-By: Claude Opus 5 (1M context) --- ...件补站内信配置行与询房残留清理-修复-管理后台.md | 114 ++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 changelogs-v2/2026-09/22_8193_团期房务三事件补站内信配置行与询房残留清理-修复-管理后台.md diff --git a/changelogs-v2/2026-09/22_8193_团期房务三事件补站内信配置行与询房残留清理-修复-管理后台.md b/changelogs-v2/2026-09/22_8193_团期房务三事件补站内信配置行与询房残留清理-修复-管理后台.md new file mode 100644 index 00000000..4d1e548e --- /dev/null +++ b/changelogs-v2/2026-09/22_8193_团期房务三事件补站内信配置行与询房残留清理-修复-管理后台.md @@ -0,0 +1,114 @@ +--- +schema: "hl-changelog/v2" +ticket: "8193" +title: "通知中心: 团期房务三个事件补齐配置行，管理后台站内信新增三类消息；两条已无发布方的询房配置行删除" +consumer: "admin" +author: "wx(GIT)" +change_type: "修复" +backend_status: "deployed" +gateway_status: "not_required" +frontend_status: "not_required" +frontend_owner: "" +frontend_ref: "" +target_release: "" +verified_at: "" +status_note: "本条不改变 AdminMessageRespVO / AdminMessagePageReqVO 的字段结构，也不新增任何端点；只在 notification_event_config 里补三行、删两行、关两处通道。frontend_status=not_required 的依据是实证而不是估计：三类新消息的 link 落在 /housekeeper/grab-pool-group，hl-ui(origin/v2.1) 的 src/views/notification/MyMessages/jumpBiz.js 对 link 的处理是通用的(非 /pages/ 前缀即直接 router.push)，src/router 已注册该路由且 src/views/housekeeper/grab-pool-group/index.vue 真实存在，V20260922_210 已把该路由纳入白名单 ⇒ 这三类消息在当前已交付的前端代码上直接可点可跳，mmg 零改动。gateway_status=not_required：零新增路由，受影响的 GET /admin/message/list 是既有端点。backend_status=deployed：hl-user-service 已滚动到测试服，Flyway 20260922.211 success=1(installed_on 2026-09-22 21:59:35)，并在自建团期夹具(groupBatchId=2102401449357197314)上走完「整体确认需求 / 房务认领 / 房务释放 → 站内信产出 → GET /admin/message/list 读回」全链路，三个事件各 18 条 ADMIN_INAPP 且 status 全为成功，实测读数见正文第五节。⚠️ admin_message 是快照表：link 在 createMessage 落库那一刻按当时模板一次性渲染写进行内，不是按需渲染 ⇒ 本条只影响生效后新产生的消息，历史行不回刷。" +updated_at: "2026-09-22" +base: "dev-v3" +--- + +# 通知中心: 团期房务三个事件补齐配置行，管理后台站内信新增三类消息；两条已无发布方的询房配置行删除 + +> **存放目录**: 二期（order-v3）→ `changelogs-v2/2026-09/` +> +> **服务**: hl-user-service（通知分发 / 站内信收件箱 / 配置表；Flyway `V20260922_211`）+ hl-order-service-v3（通知发布方，本次仅注释） +> **PR**: [#8203](https://git.1814.love:8443/wx/HL/pulls/8203) +> **Issue**: [#8193](https://git.1814.love:8443/wx/HL/issues/8193) +> **日期**: 2026-09-22 +> **影响范围**: 管理后台站内信中心（`GET /admin/message/list`）里 HOUSE 类通知的**条目数量与种类**，不涉及字段结构 + +--- + +## 一、一句话 + +团期房务的三个事件此前**一直在发**，但 `notification_event_config` 里没有对应配置行，分发器因此不产出任何消息。本次补齐配置行，房管角色（`ROOM_MANAGER`）的站内信收件箱从此会新增三类消息。 + +## 二、新增的三类消息（前端看得见） + +| `event_code` | 触发时机 | 标题形态 | +|---|---|---| +| `GROUP_BATCH_REQUIREMENT_CONFIRMED` | 团期需求整体确认放行 | 整团房需求已确认：{团期名} | +| `GROUP_BATCH_HOUSE_CLAIMED` | 团期房务被认领（含接管） | 团期房务已认领：{团期名} | +| `GROUP_BATCH_HOUSE_RELEASED` | 团期房务被释放回池 | 团期房务已释放：{团期名} | + +三类消息在 `GET /admin/message/list` 里的字段取值（**实测报文**，非推断）： + +```json +{ + "messageId": "2102401964484829186", + "categoryCode": "SYSTEM", + "title": "整团房需求已确认：Q202612082102401392893431809", + "content": "团期 Q202612082102401392893431809 的房需求已整体确认，放行 1 户、跳过 0 户，可开始配房。", + "link": "/housekeeper/grab-pool-group?groupBatchId=2102401449357197314", + "bizId": "2102401449357197314", + "bizType": "HOUSE", + "isRead": 0, + "messageType": "NORMAL", + "messageTypeLabel": "普通消息", + "kind": "NOTIFY", + "senderName": null, + "conversationKey": null, + "teamMessage": false +} +``` + +**收件人**：`wework_receiver_type=HOUSE_TEAM` ⇒ 分发器取 `ROOM_MANAGER` 角色下 `status='ACTIVE'` 的全部管理员，测试库当前 18 个账号，每个事件各落 18 行 `admin_message`。 + +## 三、跳转行为：前端零改动即可用 + +`link` 模板是 `/housekeeper/grab-pool-group?groupBatchId=${groupBatchId}`，三类消息共用。 + +- `jumpBiz.js` 的 `resolveJumpLink` 对**非 `/pages/` 前缀**的 link 直接返回并 `router.push`，不做事件码分支 ⇒ 这三类消息走的是已交付的通用分支。 +- `canJumpToBiz` 对 HOUSE 非聊天行的判据是「有没有可用 link」，本条三类消息 link 非空 ⇒ **跳转入口会正常渲染**。 +- `/housekeeper/grab-pool-group` 已在 `src/router` 注册，`src/views/housekeeper/grab-pool-group/index.vue` 真实存在；后端 `V20260922_210` 也已把该路由纳入 link 白名单。 + +**⇒ mmg 不需要为本条写任何代码。** + +## 四、契约的覆盖边界（写在脸上，供前端判断要不要做增强） + +1. **目标页当前不消费 `?groupBatchId=` 这个查询参数**。`grab-pool-group/index.vue` 里没有任何 `route.query` / `useRoute` 读取（阳性对照：同目录下另有 5 个视图文件确有该用法，所以这不是我查不到）。同模块的 `todos/index.vue` 对 `?inquiryId=` 同样不读——**这是房务模块既有且已随 #8182 交付的约定，不是本条引入的新问题**。因此点进去落到的是抢单池列表页本身，不是定位到该团期。要做「直达该团期」的增强，前端读这个 query 即可，后端已经把 id 送到了。 +2. **`bizId` 不是路由键**。三类消息的 `bizId` 等于 `groupBatchId`、`bizType=HOUSE`，但 HOUSE 域的 `bizId` 在不同事件下有 `hotelId` / `groupBatchId` / `orderId` 三种含义，禁止拿它反推页面——唯一正确的跳转来源是 `link`。这条约束已固化在 `HouseNotificationPublisher` 类注释里。 +3. **`admin_message` 是快照表**。`link` 在消息落库那一刻按当时模板渲染写进行内，之后改模板不影响已存在的行。本条生效时刻为 2026-09-22 21:59:35，此前产生的消息不受影响，也不做批量回刷。 +4. **消息只发给房管角色**。非 `ROOM_MANAGER` 的管理员收件箱里不会出现这三类消息，这是预期行为不是漏发。 + +## 五、前端**看不见**的三处配置变更（列出以免被误读为回归） + +| 变更 | 对前端的影响 | +|---|---| +| 删除 `HOUSE_INQUIRY_TIMEOUT`、`HOUSE_INQUIRY_ESCALATED` 两行配置 | **无**。这两个事件的发布方随 #4470「天级确认流程」改造已被一并删除，配置行留着也从不产出消息；删前已按「字面量 / 前缀拼接 / 非 Java 载体」三种形态穷举 + 阳性对照查证零发布方。 | +| `HOUSE_HOTEL_SWAPPED_NEW_HOTEL` / `_OLD_HOTEL` 的 `inapp_enabled` 由 1 改 0（**行保留**） | **无**。这两个收件人类型是酒店联系人，不在分发器的站内信收件人白名单里，站内信对他们结构上不可达；`inapp_enabled=1` 是假象，自出生起产出为零。保留行是为了将来走短信时只改一位。 | +| `TRAVELER_INCOMPLETE_DAILY` 的企微三列关闭（**行保留**） | **无**。该事件的 `wework_receiver_type` 原值 `'USER'` 不是合法收件人类型，企微 14 条全部发送失败；同一事件的站内信 / 短信 / 小程序三条通道**保持原样开启，一条不少**。 | + +## 六、实测读数 + +**配置表活体**（2026-09-22，测试库）： + +``` +GROUP_BATCH_HOUSE_CLAIMED HOUSE inapp=1 /housekeeper/grab-pool-group?groupBatchId=${groupBatchId} HOUSE_TEAM +GROUP_BATCH_HOUSE_RELEASED HOUSE inapp=1 /housekeeper/grab-pool-group?groupBatchId=${groupBatchId} HOUSE_TEAM +GROUP_BATCH_REQUIREMENT_CONFIRMED HOUSE inapp=1 /housekeeper/grab-pool-group?groupBatchId=${groupBatchId} HOUSE_TEAM +``` + +**发送流水**（`notification_send_log`，按自建夹具 `biz_id=2102401449357197314` 聚合）： + +``` +GROUP_BATCH_REQUIREMENT_CONFIRMED ADMIN_INAPP status=0(SUCCESS) 18 行 22:17:44 +GROUP_BATCH_HOUSE_CLAIMED ADMIN_INAPP status=0(SUCCESS) 18 行 22:18:08 +GROUP_BATCH_HOUSE_RELEASED ADMIN_INAPP status=0(SUCCESS) 18 行 22:18:18 +``` + +只有 `ADMIN_INAPP` 一个通道、无 WEWORK/SMS 行，与配置 `inapp_enabled=1 / wework_enabled=0` 一致。18 这个数与「`ROOM_MANAGER` 角色下 `status='ACTIVE'` 的账号共 18 个」是两个独立口径，互相吻合。 + +**link 渲染逐字核对**：报文里三条 link 完全相同，其中 `groupBatchId=2102401449357197314` 与自建团期 id 逐字相等（19 位），模板里无残留 `${` 占位。 + +**全表断言**：`notification_event_config` 共 63 行 = 合法收件人类型 34 行 + `IS NULL` 29 行 + **非法 0 行**；阳性对照（把 `NOT IN` 改 `IN` 同一批 14 个常量）返回 34 行，证明该断言 SQL 本身能命中。