Odoo 企业版项目预测为什么不是“任务排进 gantt 就算计划”而已：template slot、publication breakers 与 project

项目计划最容易被误解成“任务上 gantt 了就算有预测”。真正难的是模板如何复用、工时如何聚合、哪些改动会让已发布计划失效。

这篇文章主要参考了以下企业版源码与测试入口：

• enterprise/project_forecast/models/planning_slot.py
• enterprise/project_forecast/models/project_project.py
• enterprise/project_forecast/tests/test_forecast.py

一、这个模块真正解决的不是表面动作，而是跨模块语义对齐

project_forecast 不是把 planning 套到项目上那么简单。它让项目成为排班模板和 forecast 统计的主维度，并且明确哪些字段变化会打断已发布的模板或计划。

如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 project_forecast 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。

二、核心机制链路

1. planning slot 被项目重新组织

_compute_project_id()、_read_group_project_id() 说明 forecast 视图不是按员工排班的附属表，而是项目维度的一等规划对象。

2. 模板不是复制粘贴

_prepare_template_values()、_get_template_fields()、_compute_template_id() 说明项目预测支持从模板快速生成未来班次，但模板字段和实际 slot 有明确映射边界。

3. publication breakers 防止已发布计划被静默改坏

_get_fields_breaking_publication() 直接告诉你，某些字段一旦变动，就不能假装这还是同一份已发布计划。

三、最容易被误解的边界

• 把 gantt 排进去就当预测完成。
• 复制历史班次却不维护模板关系。
• 已发布的 forecast 被关键字段改动后仍当作未变，导致协作方看到的计划和系统事实脱节。

这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。

四、实施与排查时，建议按这个顺序看

• 先查项目 forecast 是否正确聚合 total forecast time。
• 再核对 slot 与模板字段映射。
• 最后验证关键字段变动是否触发 publication breaker。

对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。

五、结论

项目预测真正要解决的，是未来资源计划能否以项目为单位持续维护，而不是 gantt 上有没有彩色条。