Odoo 企业版 Documents + Fleet 为什么不是“车辆上挂附件”而已：集中 folder、owner 策略与访问传播边界讲透

很多团队给车辆挂附件时，默认思路是“照片、保单、登记证都贴在车辆记录上”。但 /home/ubuntu/odoo-temp/enterprise/documents_fleet 的设计明显更偏文档治理：车辆只是业务对象，真正的文档管理发生在 Documents 的集中空间里。

参考入口：

• enterprise/documents_fleet/models/fleet_vehicle.py
• enterprise/documents_fleet/models/res_company.py
• enterprise/documents_fleet/tests/test_documents.py

一、文档默认进公司级 fleet folder，不是散落在每辆车附件区

_get_document_folder() 返回 company_id.documents_fleet_folder，而 _check_create_documents() 又要求 company.documents_fleet_settings 开启。说明官方的默认目标是：把车辆相关文档集中到企业定义好的车队文档文件夹里，而不是让每辆车各自散落一堆附件。

二、默认 owner 为什么是当前用户

_get_document_owner() 直接返回 self.env.user，注释还提醒：用户只能看到自己在车队 folder 里的文档。也就是说，企业版这里故意没有把 owner 默认成车辆负责人或全局管理员，而是让“谁创建、谁先负责”。

这种策略很适合行政与后勤协作：文档集中，但责任仍然可追到具体操作人。

三、action_open_attachments() 打开的不是简单附件弹窗

动作最终走的是 documents.document_action_preference，并带上：

• default_res_id / default_res_model
• 默认 search panel folder
• 默认 tag

这意味着从车辆打开附件，本质上是进入 Documents 的偏好视图，并预先收紧到当前车与公司车队文档空间。它不是普通 many2many 附件窗口，而是一个受治理的文档入口。

四、测试表明访问传播是受控的，不走 public link

测试里会检查：

• 文档 is_access_via_link_hidden 为真；
• access_internal = none；
• access_via_link = none；
• 同时仍存在传播出的访问记录。

这说明车辆文档的默认思路是不靠公开链接开放，而是通过受控的 access propagation 给相关人员授权。

五、关闭公司设置后，自动建文档会停掉

test_disable_fleet_centralize_option 验证关闭集中化后，不再自动创建 Documents 记录。这很合理：不是所有公司都想把车队附件强行纳入集中治理。官方把它做成公司级开关，而不是不可关闭的强制策略。

六、结论

documents_fleet 讲的不是“车上能传附件”，而是企业车队文档如何集中、归属、授权和受控访问。车辆记录只是入口，真正的重点在于：文档要被治理，而不是被随手挂着。