Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 任务状态为什么不只是“改个字段”：approved、changes requested、waiting 的 subtype 传播链讲透
项目任务里的批准、打回和等待，并不只是 state 值变化。Odoo 源码把这些状态翻译成 subtype，再通过父子子类型向项目层传播，形成真正可协作的状态语义。
Odoo 任务为什么能把邮件自动变成协作上下文：收件人认领、CC 留存、正文落描述与附件接力讲透
Odoo 项目任务的邮件入口并不只是“来信建 task”。源码同时处理了内部用户认领、外部联系人 CC、首封邮件正文落到任务描述，以及图片附件变封面这一整套协作接力。
Odoo 邮件网关为什么要先分“新建还是续帖”：message_route、catchall、alias 与 Chatter 边界讲透
很多团队把邮件进 Odoo 理解成“收到邮件就创建记录”。但 mail.thread 源码真正先做的是分流：这封邮件究竟是在回复既有线程、命中新 alias、转发到别的模型，还是该直接 bounce。
Odoo Discuss 频道为什么不是“成员都一样收消息”：channel member、mentions only、mute 和 web push 矩阵讲透
很多人以为 Discuss 频道里只要是成员，就会按同一种方式收通知。源码其实分得非常细：成员不是 follower，频道通知还要看 custom_notifications、mute、busy 状态和 web push 分流。
Odoo 企业版 Mobile Push 为什么不是“开了推送就行”：@mention 分流、4KB payload 与深链回退链路讲透
基于 mail_mobile 源码，讲清 Odoo 企业版移动推送如何先做设备注册，再按 @mention 与普通消息拆分投递，并在 4KB payload、Discuss 会话 subject 重写与 Firebase dynamic link 回退之间维持可点开的移动通知体验。
Odoo 企业版移动消息为什么不是“有新消息就推送”：device token、bus fallback 与未读同步讲透
基于 mail_mobile 源码，讲清移动端消息推送如何围绕 OCN token、线程通知、回退链路与未读状态同步来保证移动体验。