Odoo 为什么列表能看见，点进去却报权限错误：ACL 与记录规则域合并顺序
用户能在列表里看到记录，点进详情却报权限错，常见原因不是单纯“没给权限”，而是 ACL、全局规则、组规则和关联模型读取顺序叠在了一起。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo IAP 为什么不只是“买点积分”：account token 生命周期、中和库禁用与 credit 边界讲透
很多人把 IAP 理解成 Odoo 的在线充值功能，但 iap 源码真正处理的是 account token 的创建与缓存、NoCredit 回滚时如何保住账号、credit URL 只传哈希、中和数据库自动禁用 token，以及多公司下优先选哪一个 IAP account。本文把这套边界讲清楚。
Odoo VAT 校验为什么不只是“验个税号”：前缀归一、VIES 联机校验与 no_vat_validation 边界讲透
很多人觉得 Odoo 的 VAT 校验就是套个正则，但 base_vat 源码真正处理的是国家前缀推断、EU 特殊前缀、格式标准化、VIES 在线验证失败降级，以及外部平台推数时 no_vat_validation 的边界。本文把这套税号逻辑讲清楚。
Odoo 实时总线为什么难点不只在 WebSocket：post-commit 通知、payload 拆分与订阅边界讲透
很多人把 Odoo bus 理解成“前端开个 WebSocket 收消息”，但 bus 源码真正解决的是事务提交后再广播、超长通知负载拆分、频道加库名防串库，以及客户端 last id 回放边界。本文把这条实时链路讲透。
Odoo 台湾 ECPay 电子发票为什么不只是“发票送审”：载具/捐赠互斥、Allowance 同意链与作废边界讲透
台湾 ECPay 模块的复杂度，远不止生成一份 JSON。Odoo 需要先区分 B2B 与 B2C、处理列印/爱心码/载具三者的互斥关系、按税别拼装项目明细、为 B2B 先建买方、送出后再反查有效状态、退款时根据 online/offline allowance 走不同同意链，最后还要在作废与 reset to draft 之间维护严格边界。
Odoo 埃及 ETA 电子发票为什么不只是“生成 JSON 提交”：U 盾签名、阈值校验与提交/取消分层边界讲透
埃及 ETA 电子发票模块的难点，不在于把发票导成 JSON，而在于 Odoo 如何先按本地字段拼出监管要求的结构，再借助个人 thumb drive 证书完成签名、按 preprod/production 区分域名、拿 client_credentials token 提交、回填 UUID / longId / submissionId，并在后续取消、状态查询与 PDF 拉取之间维持一致的文档身份。
Odoo 土耳其 Nilvera 电子发票为什么不只是“传个 UBL XML”：series 自动补建、状态轮询与不可回草稿边界讲透
土耳其 Nilvera 接入看起来像是标准的 XML 发票上传，但 `/home/ubuntu/odoo-temp/addons/l10n_tr_nilvera_einvoice` 里真正难的，是 Odoo 如何在 e-Invoice / e-Archive 间选路、遇到序列号不存在时自动补建 series 并重试、按 CreatedDate 断点拉取进项单据，以及为什么一旦报错或送出后就不能再随便 reset to draft。