Odoo 企业版 Social 为什么不是“统一发社媒内容”而已：UTM、live post 与多公司访问边界讲透

社媒平台最怕的是“发得出去，归因回不来；账号接得上，权限却乱套”。

这篇文章主要参考了以下企业版源码与测试入口：

• enterprise/social/models/social_post.py
• enterprise/social/models/social_live_post.py
• enterprise/social/tests/test_social_multi_company.py

一、这个模块真正解决的不是表面动作，而是跨模块语义对齐

Social 模块处理的不是一个群发器，而是一套跨账号、跨公司、跨媒介的内容与归因体系：发帖时要生成 UTM，发出后要拉 live statistics，多公司下还要保证谁能看、谁能发、谁能接账号。

如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 social 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。

二、核心机制链路

1. 发帖对象先计算可用账号

social_post._compute_account_ids()、_compute_account_allowed_ids() 说明不是任何账号都能挂到任何帖，账号可用性会受媒体、公司与权限约束。

2. UTM 是内容链的一部分

social_live_post._get_utm_values() 与 test_social_post_utm / image_utm 说明，企业版默认把链接归因视为发帖机制的一部分，而不是事后统计外挂。

3. 多公司安全是显式测试主题

test_allowed_company_ids、test_social_post_acls、test_social_stream_post_acls 说明 Social 天生是“多账号、多公司”高风险模块，权限边界必须先设计。

三、最容易被误解的边界

• 把 Social 当作简单群发器，不设计账号可用域。
• 发帖只关心成功与否，不管 UTM 回流和统计刷新。
• 多公司环境里共享账号或帖子查看权限过宽，导致品牌/数据串线。

这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。

四、实施与排查时，建议按这个顺序看

• 先查帖子计算出的 account_ids 和 allowed_ids。
• 再核对 UTM 是否在 live post 链路中正确生成。
• 最后验证不同公司用户对账号、帖子、stream 的 ACL。

对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。

五、结论

Social 的真正价值，不在“统一发帖”，而在它把发帖、归因、统计和权限一起做成了一套能长期运营的机制。