先说结论
Odoo 项目里的邮件别名，不是“收到一封邮件，就多一张任务卡”这么简单。
从 /home/ubuntu/odoo-temp/addons/project/tests/test_project_mail_features.py 可以清楚看到，一封进入项目别名的邮件，至少会触发这些动作：
- 选中目标项目
- 按邮件内容创建任务
- 识别作者 partner
- 处理 To / Cc 中已知联系人与未知联系人
- 把相关人加入关注链路
- 按阶段模板给作者发自动确认回执
- 设计回复地址，确保后续沟通还能回到同一任务线程
所以它真正解决的是：
把邮件入口接入项目协作链，而不是单纯做一条“邮件转任务”的数据导入。
第一层：为什么邮件建任务的重点不是建，而是识别
很多人以为关键动作是“create task”。
其实真正难的是识别上下文。
官方测试里重点验证的反而是：
- 作者是不是已有 partner
- 没有的话能不能自动建 partner
- To 和 Cc 里哪些人应该被识别为已有联系人
- 哪些地址只应该保留在
email_cc文本里，不该乱建 partner
这说明 Odoo 很清楚一个风险：
- 邮件地址是一团半结构化输入
- 不能见到邮箱就乱生成业务联系人
所以它采用的是比较克制的策略：
- 作者更像真正发起人，必要时会被建成 partner
- Cc / To 中未知地址未必自动转成业务联系人
- 已识别联系人才更容易进入关注者或关系链
这比“全量导入联系人”靠谱得多。
第二层：为什么 email_cc 不等于 partner 关注链
测试里有个很值得注意的点：
- 未识别的 Cc 地址会保留在
email_cc - 但不一定会变成 partner
这其实是在分离两件事：
- 通信痕迹：邮件里抄送过谁
- 业务主体：系统里真正认识谁
如果这两层不分开，邮件入口会把数据库污染得很快。
很多企业真实场景里，抄送人可能是：
- 临时邮箱
- 外包人员
- 群组地址
- 纯通知邮箱
这些人未必都该成为系统里的业务联系人。
Odoo 选择保留痕迹，但谨慎建模，这是对的。
第三层：为什么关注者传播很重要
项目别名建任务，不只是把内容塞进 description。测试里还验证了：
- 项目关注者能在新任务上接到通知
- 某些 subtype 决定谁会被通知到
- 作者、已识别联系人、项目内部关注者会形成不同的通知组合
这说明邮件入口的真正价值是：
- 邮件一进来
- 协作关系就被建立起来
- 不需要人工再去补“谁应该知道这件事”
换句话说，Odoo 不只是导入内容，更是在建立线程。
第四层：自动回执为什么放在阶段模板上
测试里还专门验证了新任务创建后的 acknowledgment 邮件。
这里的设计很妙：
- 自动回执不是项目级硬编码
- 而是挂在任务阶段模板上
这意味着：
- 进入某项目的新任务
- 如果落入某个初始阶段
- 该阶段配置了邮件模板
- 系统就能自动给作者回一封确认邮件
这个设计的好处是，自动回执属于流程配置，而不是程序死逻辑。
企业可以按阶段策略定义：
- 哪些项目要回执
- 用什么语言
- 模板内容写什么
- 哪个阶段触发
比“全站统一回一句已收到”要灵活很多。
第五层：为什么回复地址设计也很关键
测试里对 reply_to 也很关注，这不是细节洁癖，而是邮件线程能不能跑下去的关键。
如果回复地址没设计好，就会出现：
- 首次邮件进系统成功
- 后续往来却断线
- 回复跑丢到普通邮箱
- 任务线程里看不到完整对话
而 Odoo 这里的思路是：
- 让回复继续回到项目别名或任务线程入口
- 从而把后续沟通继续吸附在同一任务里
这才算真正完成“邮件协作闭环”。
第六层：实施时最常见的三个误区
误区一：觉得邮件别名只是自动录单
如果只把它当导单入口，你会忽略客户识别、通知和回执的重要性。
误区二：希望所有收件人都自动建 partner
这通常会迅速污染联系人主数据。
误区三：不关心初始阶段模板
结果就是任务建出来了，但外部客户没有回执，体验像“邮件石沉大海”。
排错顺序建议
如果邮件建任务不如预期，按这个顺序查：
- 项目 alias 是否正确
- 任务是否真的落到目标项目
- 作者和 To/Cc 联系人哪些被识别成 partner
- 项目关注者 / subtype 是否配置正确
- 初始阶段是否挂了邮件模板
- reply_to 是否能把后续邮件继续拉回线程
最后一句
Odoo 项目邮件别名最厉害的地方，不在“自动建任务”，而在它把邮件入口真正接进了：
- 客户识别
- 通知传播
- 自动回执
- 后续回复线程
这样邮件才不是系统外的沟通残留，而是项目执行链的一部分。
DISCUSSION
评论区