docs(user): 团期房务三事件补站内信配置行，管理后台新增三类消息 (#8193)
changelog-filename-gate / validate (push) Failing after 1s
changelog-filename-gate / validate (push) Failing after 1s
三个 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) <noreply@anthropic.com>
这个提交包含在：
API Changelog Bot
@@ -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 本身能命中。
|
||||||
在新工单中引用
屏蔽一个用户