Odoo 为什么列表能看见,点进去却报权限错误:ACL 与记录规则域合并顺序
用户能在列表里看到记录,点进详情却报权限错,常见原因不是单纯“没给权限”,而是 ACL、全局规则、组规则和关联模型读取顺序叠在了一起。
TOPIC PICKS
用户能在列表里看到记录,点进详情却报权限错,常见原因不是单纯“没给权限”,而是 ACL、全局规则、组规则和关联模型读取顺序叠在了一起。
可以顺着继续读的相邻方向
很多人把 Odoo 的 auth_signup 理解成“用户点链接,填个密码,账号就开好了”。但源码里的真实重点,其实是 signup token 绑定的是 partner 还是现有 user、未邀请注册是否被允许、Template User 复制了什么,以及 reset password 和 invite 流程为什么共用一套 token 机制却不是一回事。
很多人一看到 Odoo 里的 auth_password_policy,就以为它已经覆盖复杂度、历史密码、过期轮换等整套企业密码治理。翻源码会发现,标准模块真正强制的核心只有“最小长度”,而且它还要和 signup、reset password、前端密码提示一起配合,才能形成一条不打架的用户链路。
Outlook 日历同步最麻烦的从来不只是 OAuth 授权过期,而是增量 delta token 失效后如何回退全量同步、循环事件为什么必须尽量在 Outlook 端创建,以及 Odoo 为什么要把外部推送动作放到 post-commit,避免本地事务和远端日历状态互相打架。
很多团队把西班牙 SII 理解成过账后调用一次税局接口。真正麻烦的,是发票行税种组合是否合规、同批次为什么按 move_type 与 CSV 分组、税局回执 CSV 如何沉淀到单据上,以及撤销时为什么既要看状态也要看历史回执。
Peppol 项目里最容易被低估的,不是把公司注册成发送方或接收方,而是数据库恢复后 token 为什么会失步、为什么 Odoo 要把 webhook 当成持续保活链路,以及 not_registered、sender、smp_registration、receiver 这些状态背后到底在保护什么。
把 Odoo 附件迁到 Google Cloud Storage,真正难的不是 URL 变成了 storage.googleapis.com,而是上传下载为什么都走短时签名 URL、为何配置时要现场验证读写权限、以及为什么连 PDF 预览都会牵出 CORS。