Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo Helpdesk 工单转任务时，到底哪些会继承、哪些不会：project、sale line 与 timesheet 边界讲透
很多人以为 Odoo 把 helpdesk ticket 转成 project task 时，会把工单上的上下文、工时、可计费信息整包搬过去。企业版源码给出的答案更克制：向导会继承项目、阶段、客户、描述，销售订单行也可跟过去，但 ticket 工时不会自动改挂到 task，且同一条 timesheet 不能同时连 ticket 和 task。
Odoo 循环会议提醒为什么不是“每个实例各挂一个定时器”：calendar.recurrence、下一个事件选择与 trigger 接力讲透
结合 calendar.recurrence 与 calendar_event 源码，讲清 Odoo 为什么只给每条 recurrence 挂一个 trigger，如何选择未来最近实例、更新 trigger_id，以及拆分/截断循环后提醒为什么会跟着重排。
Odoo 为什么有人收到邮件，有人只在 Chatter 里看到：followers、通知通道与 activity 边界讲透
很多团队把 followers、邮件通知和活动待办混成一回事，结果就会出现“为什么他没收到邮件”“为什么她只有 inbox 通知”“为什么系统给他安排了 activity 却没自动关注”这类问题。结合 mail_thread.py 与 mail_activity_mixin.py 源码，这篇把三条链路拆开。
Odoo Discuss 频道为什么分 chat、group、channel：成员上限、公开组授权与邀请边界讲透
Odoo Discuss 里的 chat、group、channel 不是三个 UI 名字，而是三种不同的协作边界模型。源码把成员数量、公开访问、群组授权、父子频道与邮件邀请能力都分得很细，这正是频道治理不失控的基础。
Odoo 发消息为什么分 `message_post()` 和 `message_notify()`：业务线程、用户通知与自动订阅边界讲透
很多人把 Odoo 里“发一条消息”理解成同一件事，但源码里 `message_post()` 和 `message_notify()` 从入口约束到通知语义都不是一回事。看清它们的边界，才能避免 Chatter 污染、通知错发和关注者异常增长。
Odoo 关注者为什么不是“要么收、要么不收”：follower subtypes、父子子类型和通知粒度讲透
很多人已经知道 follower 会自动订阅，但真正决定“收到哪一类消息”的，往往是 subtype。本文把 mail.message.subtype、父子子类型映射与项目/任务传播链讲清楚。