Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版电话 + Helpdesk 为什么不是“来电弹出工单”而已：partner 上下文、open ticket 计数与建单入口边界讲透
基于 voip_helpdesk 源码与测试，讲清来电窗口为何直接复用 partner 的 ticket 计数、何时跳到已有工单、何时打开新建单表单，以及 related_sudo=False 为什么很关键。
Odoo 企业版 Knowledge 为什么不是“父文章一改权限全树跟着变”而已：desync 脱同步、成员继承与最后一名 writer 约束讲透
很多人把 Odoo 企业版 Knowledge 的权限理解成“根文章设 read/write/none，子文章原样继承”。但 `knowledge` 源码真正做的是一套可局部脱同步的权限树：子节点可以在降权时复制父级成员后切断继承，根/子节点还始终要满足至少一名 writer，移动到 private/shared 时也会重建权限边界。
Odoo 离岗自动回复为什么不会无限乱飞：`out_of_office` 消息类型、4 天限流与责任人补发链路讲透
Odoo 的离岗自动回复不是简单把一段请假文案群发出去。源码里它被做成独立 `message_type`，只在特定消息类型上触发，还会补入负责人和父消息作者，并对同一往来设置 4 天去重窗口。
Odoo 为什么既有定时消息又有定时通知：`mail.scheduled.message` 与 `mail.message.schedule` 两套延迟机制讲透
在 Odoo 里，“稍后发送”并不是一个单点功能。源码把“延迟发正文”和“正文先生成、通知稍后送达”拆成了两条链：`mail.scheduled.message` 和 `mail.message.schedule`。这正是协同体验能兼顾留痕、提醒和失败兜底的关键。
Odoo 任务状态为什么不只是“改个字段”：approved、changes requested、waiting 的 subtype 传播链讲透
项目任务里的批准、打回和等待，并不只是 state 值变化。Odoo 源码把这些状态翻译成 subtype，再通过父子子类型向项目层传播，形成真正可协作的状态语义。
Odoo 任务为什么能把邮件自动变成协作上下文：收件人认领、CC 留存、正文落描述与附件接力讲透
Odoo 项目任务的邮件入口并不只是“来信建 task”。源码同时处理了内部用户认领、外部联系人 CC、首封邮件正文落到任务描述，以及图片附件变封面这一整套协作接力。