wx/hl-api-changelog

派生 0

文件

T

Mimingguang e5af5425e8

changelog-filename-gate / validate (push) Failing after 2s

详情

docs(changelog): #8195 回写 verified(hl-ui@7df29262),#8193 not_required 补 mmg 复核证据

2026-09-23 09:28:29 +08:00

9.1 KiB

原始文件 Blame 文件历史

schema, ticket, title, consumer, author, change_type, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base

schema	ticket	title	consumer	author	change_type	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base
hl-changelog/v2	8193	通知中心: 团期房务三个事件补齐配置行，管理后台站内信新增三类消息；两条已无发布方的询房配置行删除	admin	wx(GIT)	修复	deployed	not_required	not_required					本条不改变 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 落库那一刻按当时模板一次性渲染写进行内，不是按需渲染 ⇒ 本条只影响生效后新产生的消息，历史行不回刷。 mmg 2026-09-23 复核: grep 实证 jumpBiz.js resolveJumpLink 对非 /pages/ 前缀 link 直喂 router.push(通用分支无事件码分支)、src/router 已注册 housekeeper/grab-pool-group、src/views/housekeeper/grab-pool-group/index.vue 真实存在——三类新消息在当前已交付代码上零改动可点可跳,not_required 成立。	2026-09-22	dev-v3

通知中心: 团期房务三个事件补齐配置行，管理后台站内信新增三类消息；两条已无发布方的询房配置行删除

存放目录: 二期（order-v3）→ changelogs-v2/2026-09/

服务: hl-user-service（通知分发 / 站内信收件箱 / 配置表；Flyway V20260922_211）+ hl-order-service-v3（通知发布方，本次仅注释） PR: #8203 Issue: #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 里的字段取值（实测报文，非推断）：

{
  "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 不需要为本条写任何代码。

四、契约的覆盖边界（写在脸上，供前端判断要不要做增强）

目标页当前不消费 ?groupBatchId= 这个查询参数。grab-pool-group/index.vue 里没有任何 route.query / useRoute 读取（阳性对照：同目录下另有 5 个视图文件确有该用法，所以这不是我查不到）。同模块的 todos/index.vue 对 ?inquiryId= 同样不读——这是房务模块既有且已随 #8182 交付的约定，不是本条引入的新问题。因此点进去落到的是抢单池列表页本身，不是定位到该团期。要做「直达该团期」的增强，前端读这个 query 即可，后端已经把 id 送到了。
bizId 不是路由键。三类消息的 bizId 等于 groupBatchId、bizType=HOUSE，但 HOUSE 域的 bizId 在不同事件下有 hotelId / groupBatchId / orderId 三种含义，禁止拿它反推页面——唯一正确的跳转来源是 link。这条约束已固化在 HouseNotificationPublisher 类注释里。
admin_message 是快照表。link 在消息落库那一刻按当时模板渲染写进行内，之后改模板不影响已存在的行。本条生效时刻为 2026-09-22 21:59:35，此前产生的消息不受影响，也不做批量回刷。
消息只发给房管角色。非 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 本身能命中。

9.1 KiB 原始文件 Blame 文件历史 Unescape Escape