Odoo 企业版 Documents + Project + Sign 为什么不是“任务附件去签字”而已：文件夹 action 嵌入与 task 文档签署路由讲透

documents_project_sign 这个模块代码非常少，少到很多人会忽略它。但正因为它只做了一件事，反而更能看清 Odoo 企业版的设计取向：项目协作里的签署入口，应该长在文档工作区里，而不是长在任务表单四处散落的按钮里。

参考入口：

• enterprise/documents_project_sign/__manifest__.py
• enterprise/documents_project_sign/data/ir_actions_server_data.xml
• 关联依赖：enterprise/documents_project、enterprise/documents_sign

一、这个模块做的不是新功能，而是“把已有能力嵌到对的位置”

唯一的数据文件里调用了 documents.document._data_embed_if_records_exist()，参数是：

• documents_project.document_project_folder
• documents_sign.ir_actions_server_create_sign_template_direct

翻成人话就是：如果项目文档文件夹存在，就把“直接创建签署模板”的 action 嵌进去。

这不是重复造轮子，而是给 Documents、Project、Sign 三者补一条用户最顺手的交汇点。

二、为什么官方选“folder action 嵌入”，而不是 task 上再加一个按钮

任务附件本来就应该先进入项目文档语境，再决定要不要发起签署。若直接在 task 表单上放散落按钮，用户很容易绕过文档归档、标签、工作区权限这些前置语义。

把入口放在项目文档文件夹里，有三个好处：

1. 用户先站在文档上下文里，再发起签署；
2. 文档本身的归属、标签、工作区权限已经就位；
3. Sign 只需要承接“这份文档进入签署流程”，不必重新解释它来自哪个项目空间。

三、这类嵌入式设计的隐含边界

因为它是“如果记录存在就嵌 action”，所以模块默认假设：

• 项目文档工作区是主要入口；
• Sign 的直接建模板动作已经在 documents_sign 中定义好；
• 这里不改变签署逻辑，只改变用户触达路径。

也就是说，documents_project_sign 的重点不是业务规则，而是入口架构。

四、最容易误解的点

• 代码少不等于价值小。很多企业版桥接模块的价值就在于把能力放对位置。
• 它不是把任务对象直接变成签署对象，而是让任务相关文档在 Documents 里拥有签署入口。
• 真正的签署回流、附件所有权、folder 继承，仍主要由 documents_sign 承担，这个模块只负责项目语境里的入口拼装。

五、实战建议

• 如果你希望项目团队在协作空间里自然发起签署，优先优化文档工作区入口，而不是盲目给 task 加自定义按钮。
• 遇到“项目里找不到签署入口”时，先检查 project folder 和 documents_sign 动作是否都存在。
• 不要把这类桥接模块误判为可有可无的 demo glue，它直接影响用户是否走标准链路。

六、结论

documents_project_sign 证明了一件事：在企业协同里，入口位置本身就是产品设计。把 Sign 放进项目文档文件夹，不只是省点击，而是把签署行为固定在正确的文档与项目上下文里。