From dbf47847fec9a0ec9e9a1f8532133c89a858ca4b Mon Sep 17 00:00:00 2001 From: Your Name Date: Sun, 6 Sep 2026 15:51:10 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E5=A4=8D=E7=B3=BB=E7=BB=9F=E6=B6=88?= =?UTF-8?q?=E6=81=AF=E5=88=97=E8=A1=A8=E6=BC=8F=E6=9F=A5=E8=A1=A8=E7=9A=84?= =?UTF-8?q?"group.join=5Frequest.accepted/rejected"=E6=9C=BA=E5=99=A8?= =?UTF-8?q?=E7=A0=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 现象：核对第2章系统消息列表最近修复的"group.announcement.updated"查表遗漏问题时，逐个比对 im_be 的 insertGroupEventTx 调用点，发现入群申请审批这一条并不在当初核对的 9 种静态事件码 之列——群管理员在群管理页批准或拒绝入群申请后，系统消息列表会展示原始机器码，而不是可读文案。 根因：TenantGroupJoinRequestResolve（server/db/mysql/tenant_groups.go:642）拼的事件码是 "group.join_request."+status（status 取 server/store/types/groups.go 的 GroupJoinRequestStatusAccepted/Rejected，即 "accepted"/"rejected"），实际产生的是 "group.join_request.accepted"/"group.join_request.rejected" 两个完整机器码。这两个和已收录的 "group.join_request.created"（提交申请时那条）是三个不同的 key，NOTIFICATION_TEXT 表里只有 后者，前两个查表落空，systemNotificationText() 兜底把原始机器码直接展示给用户。 修复：在 message-center-view.jsx 的 NOTIFICATION_TEXT 表里补上这两个 key。 验证：读 im_be 源码逐个核对 insertGroupEventTx 全部调用点，确认这是唯一还缺失的动态拼接事件码； 重新构建后确认产物里两个 key 及对应文案都已生效。未在真实环境触发一条这样的通知做端到端验证—— 需要另一账号先申请加群、本账号再批准/拒绝，属于第6章群管理操作范畴，本轮未展开搭建。 注：umd/index.dev.js 本次同样未随此提交提交——工作区里此刻并行的其它 agent 正在改 i18n/zh(-TW).json、group-management-view.jsx、sidepanel-view.jsx、call-panel.jsx、 contact-management-view.jsx 等多个文件且均未提交，重新构建的 index.dev.js 会把它们的未提交 改动一起编译进同一产物文件，为避免混入不相关改动，本次只提交源码。 Co-Authored-By: Claude Sonnet 5 --- src/views/message-center-view.jsx | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/views/message-center-view.jsx b/src/views/message-center-view.jsx index be53a698..e7453762 100644 --- a/src/views/message-center-view.jsx +++ b/src/views/message-center-view.jsx @@ -425,6 +425,17 @@ const NOTIFICATION_TEXT = { 'group.owner.transferred': '群主已转让', 'group.role.updated': '群成员角色有变更', 'group.settings.updated': '群设置有更新', + // 上面那 9 种都是 insertGroupEventTx 的静态字符串调用，唯独审批入群申请这一条不是： + // TenantGroupJoinRequestResolve（tenant_groups.go:642）拼的是 + // "group.join_request."+status，status 是 "accepted" 或 "rejected"（server/store/types/groups.go + // 的 GroupJoinRequestStatusAccepted/Rejected），实际落进 summary 的是 + // "group.join_request.accepted"/"group.join_request.rejected" 这两个完整机器码，跟本已收录的 + // "group.join_request.created"（申请提交时那条）是三个不同的 key。当初核对 9 种静态事件码时 + // 这条动态拼接的漏了，管理员在群管理页批准/拒绝入群申请后，申请人这边系统消息列表同样会原样 + // 展示机器码——跟 group.announcement.updated 是完全同一类问题，只是触发路径不同（未在真实 + // 环境里等到一条这样的通知，是读 im_be 源码逐个比对 insertGroupEventTx 调用点发现的）。 + 'group.join_request.accepted': '你的入群申请已通过', + 'group.join_request.rejected': '你的入群申请被拒绝', accepted: '对方已通过你的好友申请', rejected: '对方拒绝了你的好友申请', // 新样本：security.risk.continue/cancel 事件的 summary 直接是 decision 字面量