项目里最危险的“快操作”就是直接拖 gantt：看似调了日期，实际上可能把依赖、缓冲和人力容量一起打穿。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/project_enterprise/models/project_task.pyenterprise/project_enterprise/tests/test_gantt_reschedule_dates.pyenterprise/project_enterprise/tests/test_planning_overlap.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
project_enterprise 在任务排程上补的不是更漂亮的 gantt，而是任务依赖、缓冲消费、资源重叠和 allocated hours 的计算规则，让拖动计划不至于把任务网络和人员容量一起拖坏。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 project_enterprise 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 任务移动受依赖与缓冲约束
gantt_reschedule 测试专门覆盖 forward/backward dependency 以及 consume/maintain buffer，说明拖条并不是简单改开始结束日期。
2. allocated hours 会影响日期重算
project_task._compute_allocated_hours() 以及 related tests 表明，任务持续时间和可用工时绑定，不是纯粹日历跨度。
3. planning overlap 是系统主动发现的
_fetch_planning_overlap()、_compute_planning_overlap() 与多组 overlap 测试说明，同一用户在多个任务上的冲突需要被显式识别，而不是事后抱怨排不过来。
三、最容易被误解的边界
- 把 gantt 拖拽当作纯视觉调整。
- 忽略 dependency / buffer，导致关键路径被 silently 改坏。
- 同一资源跨项目重叠却不启用 overlap 检测。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先看移动任务时依赖链是否触发联动。
- 再核对 allocated hours 对计划日期的影响。
- 最后检查 overlap 计算是否把同一员工的冲突抓出来。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
智能排程的意义，不在“能拖”，而在拖动之后任务网络、资源容量和项目承诺仍然成立。
DISCUSSION
评论区