Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 任务依赖为什么重点不在“连线”，而在防环与复制边界：dependency 机制讲透
很多团队做任务依赖时只盯着甘特图连线，但 Odoo 官方测试更在意三件事：能不能防止循环依赖、复制项目时依赖关系如何映射、跨项目依赖是否应该原样保留。
Odoo 项目状态更新为什么不只是写周报：默认描述、milestone 变化抓取与快照逻辑讲透
很多人把 project.update 当成一条手写周报，但 Odoo 源码其实在做“项目快照”：默认继承上次进度与状态、自动拼装 milestone 信息、创建时冻结任务计数。
Odoo 任务模板为什么不是“复制一条旧任务”那么简单：字段黑名单、子任务继承与角色映射讲透
Odoo 的 task template 功能看似只是复制，但 project.task 与 project.template.create.wizard 的源码表明，官方其实很在意：哪些字段必须清空、子任务如何沿袭、项目创建时角色怎么映射给真实成员。
Odoo 周期任务为什么常在“关单那一刻”生成下一条：关闭触发、规则继承与边界讲透
很多人以为 Odoo 周期任务会像日历那样一次性展开很多条，其实 project.task 的实现更克制：最后一个未完成实例在被关掉时，才按 recurrence 规则生成下一次任务。
Odoo 任务个人阶段为什么不是改共享看板：每人一套 personal stage 的机制讲透
很多团队想把“我眼里的任务状态”和“团队共享状态”混在一张看板里，最后越改越乱。Odoo 的做法更聪明：共享 stage 继续描述团队流转，personal stage 单独描述每个用户的个人节奏。
Odoo 邮件模板为什么常常“看着能写、保存就报错”：渲染校验、默认收件人和附件归属讲透
很多人把 Odoo 邮件模板当成一个富文本编辑器，但 mail.template 源码真正关心的是：模板能不能渲染、默认收件人是否成立、附件归属是否安全。理解这三层，才能把协同邮件做稳。