多品牌、多公司的网站环境里，文档共享最怕的一件事不是“分享失败”，而是分享成功但域名错了。客户明明属于 A 站点，却收到 B 站点的公开链接，权限和品牌都会一起混乱。
这篇文章主要参考了以下企业版源码入口：
enterprise/website_documents/models/documents_document.pyenterprise/website_documents/views/documents_document_views.xml
一、这篇功能真正解决什么问题
website_documents 给 documents.document 增加了 website_id，看起来只是多一个字段，实际上是把“文档分享”正式拉进了多网站治理范围。它关心的不是文件本身，而是公开访问 URL 应该挂在哪个网站身份上。
如果没有这层约束，多公司用户很容易在后台随手选错站点，最后让公开链接带着错误域名、错误品牌甚至错误公司上下文发给客户。
二、核心链路怎么走
1. 新字段不是摆设，而是公开 URL 的网站锚点
website_id 被定义在 documents.document 上，并且使用可编辑的存储计算字段。它不是纯展示信息，而是给共享链接提供网站归属。
2. 默认值会沿着 company -> website 关系自动回填
_compute_website_id() 会在文档缺失站点、或原站点与当前公司不一致时，优先使用 document.company_id.website_id，否则退回 env.company.website_id。这保证了大多数文档在创建时就会贴近公司默认站点，而不是空着等人乱选。
3. 真正的安全点在 _check_website_id()
这个校验方法会逐条检查：当文档设置了 website_id 时，如果该网站属于别的公司，而且这个公司不在当前 allowed_company_ids 里，就抛出 AccessError。也就是说，跨公司/跨站点不是简单“禁止显示”，而是在 create() 与 write() 阶段直接阻断。
三、新手最容易踩的坑
- 以为只要能看到网站下拉框，就代表当前用户可以安全绑定任何网站。
- 以为文档换公司后，链接域名会自动一切无痛同步。实际上公司和网站错位时会重新计算并校验。
- 以为这是纯前端配置。真正的限制发生在模型层，所以脚本写入和批量更新同样会被挡住。
四、实战落地时最该盯的点
- 多公司场景先梳理“每家公司默认对应哪个 website”，不要把默认关系留空。
- 批量导入或脚本迁移文档时，别只带
company_id，要同时检查website_id是否仍在允许范围内。 - 给运营培训一个简单原则：共享链接的品牌域名不是装饰，而是合规与客户体验的一部分。
五、结论
website_documents 真正解决的是“文档能不能分享对的站点”。它把公司、网站和公开链接三者绑在一起，让多站点环境不至于因为一个下拉框选错，就把品牌和权限边界一起弄乱。
DISCUSSION
评论区