Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 邮件组为什么不只是“群发邮箱”：mail.group 的成员、审核和退订链路讲透
Odoo 的 mail.group 看起来像一个邮件列表功能，但官方源码做得远不止“把邮件群发出去”。它同时维护访问模式、成员订阅、审核规则、退订令牌和待审核提醒，是一套完整的邮件协同模型。
Odoo To-Do 为什么不是一个新模型：project.task 外壳化、待办视图和入职自动任务讲透
很多人以为 Odoo To-Do 应该有个独立模型，但官方源码走的是另一条路：继续复用 project.task，只是在视图、入口和活动分组层面把“私人待办”做成另一种壳。这个设计非常值得协同类产品学习。
Odoo 周期会议为什么不是“复制多条记录”：recurrence、例外事件、参会人状态与视频会议链路讲透
Odoo 的周期会议并不是简单批量复制日程。官方源码显示，它真正维护的是 recurrence 规则、例外事件、参会人状态重置、提醒重建，甚至还会把视频会议频道和后续事件关联起来。
Odoo @提及为什么不只是高亮名字：mention token、direct recipients 与作者通知边界讲透
在 Odoo 里，@某个人并不只是编辑器里插入一段高亮文本。源码显示，提及背后连着候选人筛选、mention token、direct recipients、作者是否自提醒等一整套通知判断链。
Odoo Chatter 字段追踪为什么不是简单 diff：tracking、subtype 与日志消息生成链路讲透
Odoo 里字段开启 tracking 后，并不是在 write() 之后直接拼一段变更文案。源码先在 precommit 保存旧值，再做 _message_track 对比，接着由 _track_subtype 决定是否升级成带 subtype 的消息，最后才在 Chatter 中生成可展示日志。这条链路决定了字段追踪到底是“静态差异”还是“有业务语义的协作消息”。
Odoo Calendar 为什么改一条循环会议会连带未来实例：recurrence 拆分与 attendee 同步讲透
Odoo 里修改一条循环会议时，系统并不是简单“批量改掉后面所有记录”。源码把 recurrence 拆分、基准事件重建、未来实例重算和参会人 attendee 命令分开处理，因此你看到的“只改当前及未来”其实是一套状态拆分逻辑。