Odoo 企业版文档仪表盘为什么不是“把文件加到 dashboard”而已：metadata、dashboard group 与新建跳转讲透

把 Documents 里的 Spreadsheet “加到 dashboard”，表面看像一个普通入口按钮；但 enterprise/spreadsheet_dashboard_documents/models/spreadsheet_dashboard.py 和 documents_document.py 告诉我们，这其实是一次对象迁移，而不是简单挂链接。

一、前端按钮先看元数据是否允许

documents_document.py 的 _get_spreadsheet_metadata() 会在父类数据上附加 can_add_to_dashboard，并且这个能力取决于当前用户是否有 spreadsheet.dashboard 的 create 权限。也就是说，文档预览里显示“可加入 dashboard”，不是靠前端猜，而是后端先把权限判断算进元数据。

二、真正加入 dashboard 时，系统会新建一个 dashboard 对象

add_document_spreadsheet_to_dashboard() 不是给原 document 打标签，而是直接 create() 一个新的 dashboard，把 document 的名称、snapshot 和 binary data 复制过去。随后再调用 document._copy_revisions_to(dashboard)，把 revision 历史也搬过去。

这一步非常关键：如果只是链接到原文档，Dashboard 就不具备自己独立的协作历史，也没法在分析场景里作为一等对象存在。

三、迁移后原文档会被归档，而不是与 dashboard 双活

在复制完 revisions 之后，源码直接 document.action_archive()，然后 dashboard._delete_comments_from_data()。这说明官方并不鼓励“同一份 spreadsheet 既当文档又当 dashboard 永久双活”。

业务原因很现实：文档协作和仪表盘分析虽然都基于 Spreadsheet，但两者的使用场景不同。继续保留原文档活跃态，很容易让团队分不清“以后该改哪一份”。

四、新建 dashboard 入口也强调对象独立性

action_open_new_dashboard() 会新建一个 Untitled dashboard，然后跳到 action_edit_dashboard。它不是打开一个通用文档编辑器，而是直接进入 dashboard 编辑场景。这再次说明 dashboard 在 Odoo 里不是 document 的一个视图，而是独立业务对象。

五、实战注意事项

1. 先治理权限，再开放按钮：没有 dashboard create 权限，前台就不该诱导用户尝试。
2. 迁移后统一入口：既然原文档会归档，就应让团队明确改动以后只在 dashboard 上进行。
3. 理解 revision 复制的价值：没有历史，就没有真正的分析演进能力。
4. 评论数据要分场景：源码删除评论数据，说明 dashboard 不该继承全部文档协作痕迹。

新手误区

• 误以为加入 dashboard 只是新增一个菜单项。
• 误以为原文档和 dashboard 会一直保持双向同步。
• 误以为 dashboard 不需要 revision 历史。
• 误以为评论和讨论痕迹应该完整带到仪表盘里。

主要源码参考

• enterprise/spreadsheet_dashboard_documents/models/spreadsheet_dashboard.py
• enterprise/spreadsheet_dashboard_documents/models/documents_document.py