6.1 KiB
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 | 8228 | HOLD 派单降级车务站内信补齐跳转链接，指向车务看板 | admin | wx(GIT) | 修复 | deployed | not_required | not_required | 接口路径、请求参数、响应字段均未变，变的是 admin_message 表里这一类消息 link 字段的取值。事件识别特征为 event_code=FLEET_DISPATCH_CREATED、biz_type=FLEET_ASSIGNMENT_HOLD、category_code=SYSTEM，触发条件是 fleet 派单进 HOLD 且给司机的短信通道返回 SKIP_NO_TEMPLATE（HOLD 占位无行程短链 code，或短信模板未配置），这条降级分支不看该事件的 inapp_enabled 开关。user-service 用 Flyway V20260923_001 给该事件补上链接模板 /fleet/board?orderId=${orderId}，fleet 发出的 HOLD 通知在能确定唯一订单时于 extras 里带 orderId。PR #8299 已合并（3227d495c），user-service 与 fleet 均已部署测试服，测试服实测该事件配置已是该模板。backend_status=deployed。gateway_status=not_required，无新增路由，消息仍走既有列表接口读取。frontend_status=not_required，前端零改动，link 走既有 resolveJumpLink 逻辑；车务看板当前不读取 orderId 这个 query，两种取值均落在看板首页；存量消息不回填，link 仍为空。；前端复核(mmg):resolveJumpLink 空值砍 query/原样跳转两态安全,fleet/board 目录 route.query 零命中,FLEET_ASSIGNMENT_HOLD 前端零分支——与后端 not_required 评估双向印证 | 2026-09-23 | dev-v3 |
车务通知: HOLD 派单降级车务站内信补齐跳转链接
存放目录: 二期（order-v3）→
changelogs-v2/2026-09/服务: hl-user-service（通知配置）+ hl-fleet-service（消息 extras） PR: #8299 Issue: #8228 日期: 2026-09-23 影响范围: 站内信列表中
event_code=FLEET_DISPATCH_CREATED且biz_type=FLEET_ASSIGNMENT_HOLD的记录的link字段取值；读取这些消息的接口本身未变
⚠️ 关键变化
这一类“HOLD 派单降级车务”站内信的 link 字段现在有值了。 消息的识别特征、触发条件都没变；变的只是这一类消息的跳转地址：本次上线之前发出的消息 link 为空，之后新产生的按下文规则带跳转链接。
一、触发条件与消息识别（未变）
fleet 派单进入 HOLD 状态、给司机的短信通道返回 SKIP_NO_TEMPLATE（HOLD 占位没有行程短链 code，或短信模板未配置）时，通知中心按既有规则降级为给车务角色（VEHICLE_MANAGER）的后台管理员发一条站内信。这条消息在 admin_message 表里的识别特征：
event_code = FLEET_DISPATCH_CREATEDbiz_type = FLEET_ASSIGNMENT_HOLDcategory_code = SYSTEM
以上触发条件和识别特征本次都没有变。这条降级分支也不看该事件的 inapp_enabled 开关——测试服上这个开关当前是 0，降级站内信照样会发，不受它影响。
二、link 取值规则（本次新增）
| 场景 | link 取值 |
|---|---|
| fleet 能确定唯一订单 | /fleet/board?orderId=<订单ID> |
| fleet 确定不了唯一订单（同一派车组的行跨了两张订单，或行上缺订单 ID） | /fleet/board?orderId=（query 值为空，不会报错） |
实现方式：user-service 用 Flyway V20260923_001 给该事件的通知配置补上链接模板 /fleet/board?orderId=${orderId}；fleet 发出的 HOLD 通知在能确定唯一订单时于 extras 里带上 orderId，通知中心降级为站内信时用它渲染出最终链接。
三、边界
- 存量消息不回填：本次只改配置和消息生成逻辑，不动已经发出的历史消息。测试服上 2026-08-05 至 2026-08-08 期间发出的 234 条这类站内信
link仍为空，前端resolveJumpLink对空 link 返回null，这些消息依旧没有跳转入口；只有之后新产生的才带链接。 - 车务看板当前不读取
orderId这个 query：hl-ui（origin/v2.1@31a198613）的车务看板src/views/fleet/board/**目前不读取route.query（对该目录 86 个文件检索route.query/useRoute/$route均为 0 命中；同一检索在兄弟目录src/views/fleet/matrix/有命中，检索本身有效）。带orderId与不带orderId的两种链接点开后都落在看板首页，不会按订单定位。 link走既有跳转逻辑，前端无需新增处理：link是后台相对路由，前端现有的resolveJumpLink（src/views/notification/MyMessages/jumpBiz.js:22-32）直接把它交给router.push；kv.endsWith('=')时会把整段 query 砍掉（:27-31），所以/fleet/board?orderId=实际会跳到/fleet/board，/fleet/board?orderId=123原样跳转，两种情形都不会报错。- 生产环境没有这类消息：二期（order-v3、fleet）尚未上生产，本次改动目前只在测试服可见。
四、测试环境已验证
- PR #8299，合并提交
3227d495c，user-service、fleet 均已部署到测试服。 - 测试服上
notification_event_config中event_code=FLEET_DISPATCH_CREATED那一行的inapp_link_template实测已是/fleet/board?orderId=${orderId}。
五、可选增强（非必须，供参考）
如果车务看板以后想按订单定位，query 参数名已经固定是 orderId，值是订单 ID 字符串，直接读取即可，不需要另外跟后端约定参数名。这是可选增强，不是必须动作。
关联 / 联系人
链接
联系人
- 后端负责人: @wx