Odoo 权限不是“ACL 再加个 rule”这么简单：记录规则域合并、组 OR 与访问校验边界
很多开发者把 Odoo 权限理解成“两层门”：先看 ACL，再看 record rule。但从 ir_rule.py 的 _compute_domain 和 models.py 的 _check_access 看，系统实际做的是“先判模型权限，再把全局规则、组规则、继承模型规则合成一个 domain，最后对真实记录集做过滤和报错”。
ARTICLE LIBRARY
Odoo 学习文章
持续记录源码理解、业务流程、模块开发经验与踩坑总结。
Odoo 点 Create Payment 后到底发生了什么：register wizard、payment post 与 reconciliation 串联
很多人把 Register Payment 看成一个按钮动作：点一下，系统就“自动付款完成”。但从 account.payment.register 的 _create_payments、_init_payments、_post_payments、_reconcile_payments 和 account.move.line.reconcile 看，这其实是一条“分批组织 -> 建 payment -> 过账/变更状态 -> 对账核销”的完整链路。
Odoo 采购收货为什么不是“一行采购一张收货单”：已有 picking 复用、move 挂接与 qty_received 真实链路
很多人以为采购确认后，Odoo 会按采购行机械地一行生成一张收货单。但从 purchase_stock 的 _create_picking、_create_or_update_picking 与 _prepare_qty_received 看，系统真正维护的是“订单级收货容器 + 行级 stock.move + 已完成 move 反推收货数量”的模型。
Odoo 展位销售为什么不是“卖一个 Booth 产品”就完事：预留、确认、抢占冲突与付款落定链路讲透
Odoo 的 Event Booth Sale 看起来像是在销售订单里卖一个服务产品，但源码实际上把“想要某个展位”“确认拿到某个展位”“付款后正式落定”拆成了多层状态。本文沿着 sale.order.line、event.booth.registration、sale.order 和 account.move 把这条链路拆开讲清。
Odoo 问卷邀请为什么不是“群发一个链接”而已：收件人识别、重复邀请与 token 链路讲透
Odoo 的 Survey Invite 向导看起来只是填几个邮箱然后发送，但源码里实际处理了 access mode、partner 识别、外部参与资格、重复邀请复用、answer token 生成、模板渲染和语言上下文。本文把 survey.invite 到 survey.user_input 的主链路一次讲清。
Odoo 企业版 Documents 分享链接为什么不是“有个 URL 就都能看”：token、文件夹权限与上传边界讲透
很多人把 Odoo Documents 的外链分享理解成“生成一个 access URL”。但从 documents_document.py 和分享模板看，真正决定外部人能看什么、能不能上传、能否继续深入子文件夹的，是 token、user_permission、access_via_link、父文件夹权限和 owner 规则叠加出来的一套边界。本文把这套机制拆开讲清。