维护现场最怕“检查做了，但记录散落在聊天、附件和口头描述里”，最后根本不具备可追溯性。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/maintenance_worksheet/models/maintenance_request.pyenterprise/maintenance_worksheet/models/worksheet_template.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
maintenance_worksheet 不是简单加一个富文本附件。它把维护请求和 worksheet template、安全组、打印报告串起来，让每一张维修单都能基于模板采集可审计的作业信息。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 maintenance_worksheet 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 维护请求要知道自己挂了几份 worksheet
_compute_worksheet_count() 与 action_maintenance_worksheet() 表明 worksheet 不是一次性附件，而是维修单的可追踪工作记录对象。
2. 模板不是谁都能用
worksheet_template 里专门定义 manager/user/access_all groups，说明模板可见性和可填写范围是流程治理的一部分。
3. 最终输出要能成报告
模块自带 maintenance_custom_report.xml，说明 worksheet 不只是在线填写，还要能沉淀为标准化报告交付给维护管理与审计。
三、最容易被误解的边界
- 把 worksheet 当成上传一个 PDF 模板。
- 不给模板设计权限边界，导致谁都能改。
- 只收集现场填写，不考虑后续打印与审计复盘。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 maintenance request 的 worksheet_count 和打开动作。
- 再核对模板归属的安全组。
- 最后验证填写后的数据能否落入自定义报告链。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
维护 worksheet 的意义，不在“多一个表单”，而在让维护作业从临时动作变成结构化、可审计的工作记录。
DISCUSSION
评论区