| 环节 | 现在靠什么 | 状态 |
|---|---|---|
| 谁是 admin | 源码里三个人名,每个客户组织都发给 Sparticle 这三个 | ❌ 待改 |
| 客户归谁跟 | profile.md 里的名字 | ❌ 待改(数据已就位) |
| 这人收不收 | notify_level | ✅ 今天切完 |
| 名字 → 投递地址 | 名字 → org-members.json 邮箱 → Lark 查 open_id | ❌ 待改 |
| 发完记录 | 没有 —— 只有一行会滚掉的日志 | ❌ 待做 |
| 输入 → 输出 | 关键约束 | |
|---|---|---|
| ① | 事件 + 客户 → 人的列表 | 输出是「人」,不是 open_id —— 它不认识任何一家 IM |
| ② | 人 → 收 / 不收 | 是最后一道闸,不是路由的一部分。混在一起就分不清「他关了通知」还是「路由算掉了」 |
| ③ | 人 → 渠道账号 → 发 | 渠道类型是盒子级配置(一个组织一套 IM),不是人的属性 |
| ④ | 一人一行 | 一个人失败不影响其他人 —— 遍历的是互不相干的 N 个人,不是一个事务 |
①②③ 的实现都在 worker/lib/org_members.py(纯函数层),
和邮件那套 mail_query.py 同形 —— pipeline 直接调函数,Mio 走 MCP,前端走 HTTP,三条路调同一个函数。
| 是什么 | 存哪 | |
|---|---|---|
| 身份 | 这个人是谁(登录用) 邮箱 / 姓名 / 属于哪个组织 |
控制平面 control.db 每 10 分钟镜像进盒子 |
| 渠道账号 | 他在 Lark / Teams 里是哪个账号 | 盒子 runs.db channel_account_id |
⚠️ 这两个必须分开,因为它们真的不一样。
prod 实测 28 人里 7 个的 Lark 是用私人邮箱注册的:
李荣会 rh.li@sparticle.com ←→ dmkd3006@gmail.com
拿公司邮箱去 Lark 查这些人,一个都查不到。
| 要配什么 | 谁来配 | 现状 |
|---|---|---|
收不收 / 收什么notify_level |
本人 + 管理员 | 只能改数据库。原来在 config.yaml —— 也等于「只有工程能改」 |
渠道绑定channel_account_id |
本人自助 | 我用脚本一次性回填了 21/28,剩 7 个没有入口 |
| 客户归谁跟 | 管理员 | 只能改 profile.md 文件 |
放哪:用户设置弹窗,邮箱连接的旁边。形状我们上周刚做过一遍 —— 「连接工作邮箱」那个弹窗,加一块「通知设置」即可,不用新建页面。
「绑定成立」的定义是「消息真的送到了」,不是「填了个账号」。
和邮箱连接是同一条原则 —— 「已连接」是一个动词的结果,不是一个存下来的形容词。
飞书日历那次停摆一个多月,正因为页面上的绿灯读的是存下来的状态,而 token 三周前就死了。
| 1 | 读侧再切 4 处(admin / 归属 / 名字→地址) | 进行中 1/5 |
| 2 | 送达台账 —— 现在发没发出去查不到, 这正是「漏发几个月没人发现」的原因 | 待做 |
| 3 | 页面配置 —— 通知设置 + 渠道绑定(带确认) | 待做 · 要 Mia |
| 4 | 投递层抽象 + Teams 骨架 | 待做 |
| 5 | 删掉旧的两份名单 | 观察后 |