很多人使用 Sign 时，只看到“上传 PDF → 发起签署”，但企业版 documents_sign 真正做的是让 PDF 从 Documents 空间出发，在签署模板、请求和完成文件之间保留同一套 folder、tag 与访问权。
## 1. Documents 里的二进制文件可以直接升格成 sign.template
在 enterprise/documents_sign/models/documents_document.py，document_sign_create_sign_template() 会校验只能基于 PDF 文档创建模板，并把原文档的 folder/tag 带进 sign.template。这一步解决的是“模板来源”问题：签署模板不是孤立新对象，而是 Documents 中已有文件的再利用。
2. Sign request 创建时会反查 reference_doc，避免签署脱离原始文档空间
enterprise/documents_sign/models/sign_request.py 在 create() 里会根据模板的 document attachment 找回 documents.document，并把 reference_doc 指向单个文档或其 folder。于是从请求页跳回 Documents 时，用户还能沿着原始文件空间继续工作，而不是停留在一个与文档库脱节的 Sign 页面。
3. 完成文件生成后，权限会回补给 signer 与 requester
同一文件里的 _generate_completed_documents()、_send_completed_documents() 与 sign.request.item._sign() 共同确保：completed attachment 会被转成 Documents 文档，但发邮件时不会重复建文档；同时 signer 和 requester 会被补上 completed document 的 view access。文件完成后仍然活在 Documents 权限体系里。
4. 最容易踩坑的是只看 Sign，不看 Documents 的 folder 边界
如果模板 folder 设计混乱，签完后的 completed file 就会散落在错误空间；如果只关心邮件是否发出，不核对 reference_doc 和 tag，后续检索、审计和归档都会很难做。企业版这里其实是在把 e-sign 变成文档治理流程的一部分。
## 结论
所以，Odoo 企业版 Documents 发起签署的价值，不是省一次上传动作，而是让原始 PDF、签署模板、请求对象和 completed file 始终共用同一套 folder/tag/权限链。
主要源码锚点：
- `enterprise/documents_sign/models/documents_document.py`
enterprise/documents_sign/models/sign_request.pyenterprise/documents_sign/models/sign_template.pyenterprise/documents_sign/data/documents_folder_data.xml
DISCUSSION
评论区