知识库页面里插个附件，看上去像纯编辑器功能；但 Odoo 企业版真正做的是把 knowledge.article、ir.attachment、编辑器评论线程和 portal 访问控制接成一条上下文链。没有这层设计，所谓“知识沉淀”很快就会变成一堆没人敢点的附件。
## 1. Knowledge 文章本身就是权限树，而不是富文本容器
在 enterprise/knowledge/models/knowledge_article.py，文章拥有 parent、member、inherited permission 等结构。文章被移动、复制、套模板时，系统还会重写 embedded view 和 article link。也就是说，正文中的元素从一开始就受知识库权限树支配，不是脱离上下文的 HTML 片段。
2. 附件访问权会随着评论线程和 portal 场景动态补 token
enterprise/knowledge/models/ir_attachment.py`` 会对关联knowledge.article.thread的附件在 portal 场景下补access_token；而knowledge_article_thread.py在_process_attachments_for_post()里会显式generate_access_token()`。这意味着评论线程上传的文件不会因为脱离后台会话就失联，附件权限会沿着 article thread 这条协作链传下去。
3. 编辑器不是只负责显示，它会维护 embedded view 与 article link 的引用语义
知识模板应用与文章复制时，源码会扫描 data-embedded="view"、o_knowledge_article_link 与 articleIndex 等节点，把它们改写成新文章可用的引用。这是第二条关键跨模块链：html_editor 提供编辑能力，knowledge 负责把这些嵌入元素翻译成新上下文可用的引用。
4. 对实施来说，最大的误区是把 Knowledge 当 Documents 替代品
Knowledge 更像“带协作与权限树的知识页面层”，Documents 更像“文件对象层”。Knowledge 附件能被安全访问，是因为 token、thread、member ACL 与 editor 引用一起工作；不是因为文章正文神奇地自带文件治理。
## 结论
所以，Odoo 企业版知识库不是把文件塞进一段 HTML，而是让文章权限树、评论线程附件 token 与编辑器嵌入引用共同维持一份可协作、可外部访问又可追责的知识上下文。
主要源码锚点：
- `enterprise/knowledge/models/knowledge_article.py`
enterprise/knowledge/models/ir_attachment.pyenterprise/knowledge/models/knowledge_article_thread.pyenterprise/knowledge/__manifest__.py
DISCUSSION
评论区