Odoo Security Rules 是一个专精 Odoo 访问控制（access control）的技能，其公开介绍围绕模型级访问与记录级规则两条安全层级展开：模型级访问决定谁可以读/写哪些模型，记录级规则决定用户可以看见哪些记录。该技能的定位是帮助用户写出正确的 ir.model.access.csv 条目与基于 domain 的 ir.rule 记录规则。
【适用场景】 资料中列出四类使用场景：
- 为新的自定义模块设置访问权限；
- 限制记录，使用户只能看到自己的数据或本公司的数据；
- 排查“Access Denied”或“You are not allowed to access”类错误；
- 实现多公司（multi-company）记录可见性规则。
【使用方式】 资料给出三步工作方式：
- 激活：提及 @odoo-security-rules 并描述访问场景；
- 生成：获得正确的 CSV 访问行与 XML 记录规则；
- 调试：粘贴访问错误，获得诊断与修复方案。
【示例要点】 资料提供了三个示例。第一个是 ir.model.access.csv，包含 id、name、model_id:id、group_id:id、perm_read、perm_write、perm_create、perm_unlink 列，并演示给普通用户只读、给管理者完整权限两种条目。示例同时提醒：base.group_erp_manager 用于 ERP 管理者，而 base.group_system 保留给 Odoo 技术超级用户；模块特有的管理者角色应创建自定义组，示例用 res.groups 记录定义了 Hospital Manager 组，category_id 引用 base.module_category_hidden。
第二个示例是“用户只能看自己的记录”的 ir.rule，domain_force 为 [('create_uid', '=', user.id)]，并通过 groups 字段 eval [(4, ref('base.group_user'))] 指定适用组，perm_read/perm_write/perm_create 为 True，perm_unlink 为 False。示例强调：若省略 groups 字段，规则将变为全局规则并作用于所有用户（包括管理员），因此除非明确想要全局限制，否则应始终指定组。
第三个示例是多公司记录规则，domain_force 使用 ['|', ('company_id', '=', False), ('company_id', 'in', company_ids)]，即允许 company_id 为空或属于用户所属公司集合的记录，同样通过 groups 指定 base.group_user。
【最佳实践】 资料列出的推荐做法包括：从最严格的访问权限开始，按需放开；在多公司规则中使用 company_ids（复数），它包含用户所属的所有公司；在调试模式下用非管理员用户测试规则，因为 sudo() 会完全绕过记录规则；为每个模块创建专用的安全组，而不是复用 Odoo 核心组。
不建议的做法包括：除非业务流程明确要求删除，否则不要给普通用户 perm_unlink = 1；除非确实想授予公共（未认证）访问，否则不要在 ir.model.access.csv 中让 group_id 留空；不要用 base.group_system 作为模块管理者，因为那会授予包括服务器配置在内的完整技术访问权限。
【限制】 资料明确说明本技能不涵盖字段级访问控制（ir.model.fields 的读/写限制），这类需求需要自定义 OWL 或 Python 覆盖。门户（portal）与公共用户访问规则有额外细节未完全覆盖，需结合 base.group_portal 谨慎测试。记录规则会被 sudo() 绕过——任何在超级用户上下文中运行的代码都会忽略所有 ir.rule 条目。此外，本技能不涵盖通过 PostgreSQL 实现的行级安全（RLS），因为 Odoo 在 ORM 层管理全部安全性。关于该技能的价格、平台支持、安装命令等信息，资料中暂未提供。