循环任务如果只复制标题和截止日期，看起来很方便，但很快就会让项目排程失真。因为企业里的 recurring task 往往不只是“下周再来一次”，而是 下一次也应该继承合理的计划起点。project_enterprise 在这里多做了一步：把 planned_date_begin 也当作需要顺延的字段。
主要参考：
enterprise/project_enterprise/models/project_task_recurrence.pyenterprise/project_enterprise/models/project_task.pyenterprise/project_enterprise/views/project_task_views.xml
一、planned_date_begin 被纳入 recurring 字段，本身就是设计声明
_get_recurring_fields_to_postpone() 在企业版里追加了 planned_date_begin。这说明 Odoo 认为任务的计划开始时间不是可忽略的 UI 信息，而是周期任务的一部分业务上下文。
这很现实。比如每周例会准备、每月结账检查、固定客户回访，它们通常不仅有截止时间，也有一个应该开始准备的时间窗口。只顺延 deadline，不顺延 start，排程很快会失真。
二、unschedule 不是“只删一个日期”，而是成对清空
action_unschedule_task() 会同时把 planned_date_begin 和 date_deadline 设为 False。这个动作看似简单，但非常重要：系统在告诉你，计划起点和计划终点本来就是一组配对字段。
如果只清一个、不清另一个，任务就会留下半残的计划痕迹。下一轮 recurrence 或人工排期时，这类残留最容易引发误解。
三、取消任务时，未来计划也会被主动拆掉
_inverse_state() 里，如果任务被置为取消状态且计划开始时间还在未来，系统会一并清掉 planned_date_begin 和 date_deadline。这说明企业版不希望“已经取消的未来任务”继续占着计划资源。
这个细节很有项目管理意味：取消，不只是业务上不做了，也意味着计划视图上不该再像一个待执行任务那样占位。
四、为什么这比“自动复制任务”更成熟
企业版在循环任务这里的思路是：
- 周期任务要继承的不只是表面字段；
- 计划开始时间本身有业务意义；
- 当任务被取消或取消排期时，计划字段要整体退场。
这让 recurrence 不会沦为“批量制造脏任务”的工具。很多团队抱怨循环任务越用越乱，往往不是 recurrence 本身有问题，而是系统没有把计划字段当成一等公民处理。
五、新手误区
- 以为 recurring task 只要顺延 deadline 就够了。
- 以为 unschedule 是临时隐藏，不影响后续周期逻辑。
- 以为取消任务只改状态，不需要动计划字段。
六、落地建议
- 对周期性工作，明确团队究竟关心 deadline 还是完整计划窗口；若是后者，就应该保留企业版这种 start+end 顺延逻辑。
- 排程培训时告诉成员：unschedule 会清掉整组计划字段，不是仅仅把任务从图上挪开。
- 对自动生成的周期任务，定期检查是否存在被取消但仍保留计划日期的定制逻辑冲突。
七、结论
project_enterprise 在循环任务上的成熟之处，是承认 planned_date_begin 也是计划本体的一部分，并在顺延、unschedule、取消三类动作里都保持这组字段的一致性。这样周期任务才不会越跑越乱，而会像真正的计划对象一样持续自洽。
DISCUSSION
评论区