Odoo 周期任务为什么不会“无限复制到失控”：下一次生成、子任务复制与停止规则讲透
很多人以为 Odoo 的周期任务只是“关掉一张，系统再复制一张”。但源码里真正决定会不会继续生成、复制哪些字段、截止日期怎么顺延、子任务会不会一起带过去的，是 project.task 与 project.task.recurrence 的一整套协作逻辑。本文把这条链路拆开讲清。
ARTICLE LIBRARY
Odoo 学习文章
持续记录源码理解、业务流程、模块开发经验与踩坑总结。
Odoo 补货异常为什么不是“报一条错就结束”：stock.rule.run 的异常聚合与排查顺序讲透
很多人排库存补货问题时，只看到界面上一句“找不到规则”或“无法补货”，于是沿着单条错误去追。可在 stock_rule.py 里，run() 的职责其实是把一批 procurement 统一分流、统一执行、统一收集失败项，最后再决定抛给用户什么信息。本文结合 stock_rule.py 与 stock_orderpoint.py 把这条链路讲透。
Odoo 补货调度为什么不是“一个 orderpoint 报错整批就废了”：savepoint、失败剔除与 warning activity 讲透
很多人一看到 replenishment scheduler 报错，就直觉认为这一轮补货全军覆没。但在 stock_orderpoint.py 里，Odoo 实际采用的是“savepoint + 聚合异常 + 失败项剔除 + 剩余继续”的处理方式。本文聚焦 orderpoint 调度本身，解释为什么 warning activity 往往代表部分失败而不是整批失败。
Odoo 销售行里的 display_type 为什么不是“排版字段”：section / note / down payment 如何绕开交付与开票计算讲透
很多人看到 sale.order.line 里的 display_type，会下意识把它理解成报价单上的 section 和 note 排版辅助。可一旦把它和 is_downpayment、qty_to_invoice、invoice_status 放在一起看，就会发现它其实定义了“哪些行参与业务计算、哪些行只负责结构呈现”的硬边界。本文结合 sale_order_line.py 把这条边界讲透。
Odoo 记录规则为什么不是“domain 过滤完就结束”：SQL 域、访问校验与越权错觉讲透
很多人理解记录规则时只记住一句话：ir.rule 会给 search 自动加 domain。这个说法不算错，但远远不够。到了新版本源码里，访问检查已经不再是“前面搜出来就算能操作”，而是模型权限先过一层、记录规则再过一层，最后才得到真正允许的记录集。本文结合 orm/models.py 把这条边界讲透。
Odoo 会计行里的 display_type 为什么不是“前端展示字段”：section / tax / payment term 行的会计边界讲透
很多人把 account.move.line 里的 display_type 误以为只是 UI 用来画 section 和 note 的字段。实际上，它同时决定一行是不是产品行、税行、付款条款行，甚至决定这行应不应该有科目、金额和后续会计语义。本文结合 account_move_line.py 与 account_move.py 把这条边界讲透。