Odoo 为什么列表能看见，点进去却报权限错误：ACL 与记录规则域合并顺序
用户能在列表里看到记录，点进详情却报权限错，常见原因不是单纯“没给权限”，而是 ACL、全局规则、组规则和关联模型读取顺序叠在了一起。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo Google Calendar 同步为什么难点不只在 OAuth：sync token、循环事件重写与 organizer 权限边界讲透
很多人觉得 Google Calendar 接入的核心就是拿到 OAuth token，但真正让同步稳定的，是更底层的几条规则：写库成功后才 post-commit 推送、sync token 失效时全量重拉、循环事件在 Odoo 与 Google 之间如何重新生成、以及 guest readonly 事件为什么必须由 organizer 身份修改。
Odoo EDI Proxy 为什么不是“后面有个中转服务”而已：refresh token、RSA 加密与数据库克隆边界讲透
很多团队在调 Peppol 或其他电子发票接入时，只看到前台按钮和后端报错，却没看清 Odoo 还有一层 account_edi_proxy_client 基础设施。真正容易出问题的，不是“代理服务挂了”，而是 refresh token 24 小时轮换、HMAC 与私钥双签名回退、数据库克隆后的 invalid_signature、以及代理端文件为何必须走公钥加密。
Odoo 罗马尼亚 e-Factura 为什么难点不只在“成功上传”：SPV 索引、异步同步与拒绝恢复边界讲透
罗马尼亚 e-Factura 在 Odoo 里最容易被低估的，不是 XML 生成，而是发出去之后并不会立刻得到最终结论：有时先拿到发送成功与索引 key，有时压根拿不到 index，要靠后续 synchronize 去补回；已发送文档还可能被替换成 validated 或 refused 文档，甚至超过保留天数后只能做“推定拒绝”处理。
Odoo 西班牙 Veri*Factu 为什么真正难点不在“发 XML”，而在链式指纹、批次节流与二维码边界
很多人把 Veri*Factu 理解成“开票后生成一份 XML 发给税局”。但 Odoo 标准实现里，真正复杂的是每条记录都要带上前序记录指纹形成链、已成功生成的文档不能删除、发送还要遵守批次等待时间，甚至超时后还要靠 duplicate 信息做恢复判断，二维码也依赖最终记录标识而不是随手拼接。
Odoo 支付为什么难点常常不在“收款成功”，而在令牌化、手工捕获与退款子交易链路
很多团队已经知道 Odoo Payment 有一套 transaction state machine，但线上最容易踩坑的往往不是 done / error，而是 token 什么时候创建、授权后何时 capture、部分捕获如何拆子交易、退款为什么会变成负金额 child transaction，以及 provider 关闭后旧 token 为什么会一起失活。
Odoo 邀请注册为什么不只是“发一封设密码邮件”：token 认领、模板用户复制与重置链路边界讲透
很多人把 Odoo 的 auth_signup 理解成“用户点链接，填个密码，账号就开好了”。但源码里的真实重点，其实是 signup token 绑定的是 partner 还是现有 user、未邀请注册是否被允许、Template User 复制了什么，以及 reset password 和 invite 流程为什么共用一套 token 机制却不是一回事。