Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 计划活动为什么不会无限接龙：mail.activity.type 的 suggest / trigger 与完成后续接链路讲透
很多人以为 Odoo Activity 的“下一步”只是界面上的推荐按钮。实际上，mail.activity.type 里 suggest 和 trigger 是两套完全不同的机制：一套负责给人选项，一套负责在完成时自动长出下一条。看懂这条链，才能把提醒真正配置成流程。
Odoo 任务分派为什么不只是改个负责人：user_ids、date_assign、通知与邮件入口背后是一整条链
Odoo 的任务分派并不是往 user_ids 填个人就完事。源码里它还会更新时间、自动订阅、发送分派通知，甚至从邮件收件人推断 assignee。本文把整条链讲清楚。
Odoo 企业版 Documents 分享链接为什么不是“有个 URL 就都能看”：token、文件夹权限与上传边界讲透
很多人把 Odoo Documents 的外链分享理解成“生成一个 access URL”。但从 documents_document.py 和分享模板看，真正决定外部人能看什么、能不能上传、能否继续深入子文件夹的，是 token、user_permission、access_via_link、父文件夹权限和 owner 规则叠加出来的一套边界。本文把这套机制拆开讲清。
Odoo Chatter 字段追踪为什么不是“把旧值和新值记一下”：mail.tracking.value、字段权限过滤与差异展示讲透
很多人以为 Chatter 里的字段变更只是生成一句“X 改成 Y”。但从 mail.tracking.value 与 account 对 mail.message 的扩展看，Odoo 真正在维护的是一份结构化差异数据：既要按字段类型存储旧值/新值，又要在展示时再判断当前用户有没有权限看到这些字段。
Odoo 企业版 Sign 为什么不是“群发一个签字请求”：签署顺序、Reminder Cron、SMS 二次认证与逐批投递链路讲透
基于 sign 源码，讲清 Odoo 企业版签署请求如何用 signer 的 mail_sent_order 控制分批发送，再用 _cron_reminder 续推下一批，并在 SMS 二次认证与无余额降级之间维持签署闭环，而不是把所有签署人一次性丢进同一封邮件里。
Odoo 企业版 Approvals 为什么不是“点同意/拒绝”而已：顺序审批、最低人数、必审人与活动队列边界讲透
很多人把 Odoo 企业版 Approvals 看成一个很轻的审批按钮系统。源码里真正重要的不是按钮，而是“最低审批人数 + 必审人 + 顺序审批 + mail.activity 队列”四层约束如何一起决定请求何时进入 approved、refused 或 waiting。