Odoo Security Rules

Odoo Security Rules

Overview

Security in Odoo is managed at two levels: model-level access (who can read/write which models) and record-level rules (which records a user can see). This skill helps you write correct ir.model.access.csv entries and ir.rule domain-based record rules.

When to Use This Skill

• Setting up access rights for a new custom module.
• Restricting records so users only see their own data or their company's data.
• Debugging "Access Denied" or "You are not allowed to access" errors.
• Implementing multi-company record visibility rules.

How It Works

1. Activate: Mention @odoo-security-rules and describe the access scenario.
2. Generate: Get correct CSV access lines and XML record rules.
3. Debug: Paste an access error and get a diagnosis with the fix.

Examples

Example 1: ir.model.access.csv

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_hospital_patient_user,hospital.patient.user,model_hospital_patient,base.group_user,1,0,0,0
access_hospital_patient_manager,hospital.patient.manager,model_hospital_patient,base.group_erp_manager,1,1,1,1

Note: Use base.group_erp_manager for ERP managers, not base.group_system — that group is reserved for Odoo's technical superusers. Always create a custom group for module-specific manager roles:

<record id="group_hospital_manager" model="res.groups">
    <field name="name">Hospital Manager</field>
    <field name="category_id" ref="base.module_category_hidden"/>
</record>

Example 2: Record Rule — Users See Only Their Own Records

<record id="rule_hospital_patient_own" model="ir.rule">
    <field name="name">Hospital Patient: Own Records Only</field>
    <field name="model_id" ref="model_hospital_patient"/>
    <field name="domain_force">[('create_uid', '=', user.id)]</field>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
    <field name="perm_read" eval="True"/>
    <field name="perm_write" eval="True"/>
    <field name="perm_create" eval="True"/>
    <field name="perm_unlink" eval="False"/>
</record>

Important: If you omit <field name="groups">, the rule becomes global and applies to ALL users, including admins. Always assign a group unless you explicitly intend a global restriction.

Example 3: Multi-Company Record Rule

<record id="rule_hospital_patient_company" model="ir.rule">
    <field name="name">Hospital Patient: Multi-Company</field>
    <field name="model_id" ref="model_hospital_patient"/>
    <field name="domain_force">
        ['|', ('company_id', '=', False),
               ('company_id', 'in', company_ids)]
    </field>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
</record>

Best Practices

• ✅ Do: Start with the most restrictive access and open up as needed.
• ✅ Do: Use company_ids (plural) in multi-company rules — it includes all companies the user belongs to.
• ✅ Do: Test rules using a non-admin user in debug mode — sudo() bypasses all record rules entirely.
• ✅ Do: Create dedicated security groups per module rather than reusing core Odoo groups.
• ❌ Don't: Give perm_unlink = 1 to regular users unless deletion is explicitly required by the business process.
• ❌ Don't: Leave group_id blank in ir.model.access.csv unless you intend to grant public (unauthenticated) access.
• ❌ Don't: Use base.group_system for module managers — that grants full technical access including server configurations.

Limitations

• Does not cover field-level access control (ir.model.fields read/write restrictions) — those require custom OWL or Python overrides.
• Portal and public user access rules have additional nuances not fully covered here; test carefully with base.group_portal.
• Record rules are bypassed by sudo() — any code running in superuser context ignores all ir.rule entries.
• Does not cover row-level security via PostgreSQL (RLS) — Odoo manages all security at the ORM layer.

AGI Framework Integration

Adapted for @techwavedev/agi-agent-kit Original source: antigravity-awesome-skills

Memory-First Protocol

Cache compliance check results to avoid re-running expensive AWS API calls. Retrieve prior audit findings to track remediation progress across sessions.

# Check for prior security context before starting
python3 execution/memory_manager.py auto --query "prior security audit results for Odoo Security Rules"

Storing Results

After completing work, store security decisions for future sessions:

python3 execution/memory_manager.py store \
  --content "Audit findings: 3 critical IAM misconfigurations found and remediated" \
  --type technical --project <project> \
  --tags odoo-security-rules security

Multi-Agent Collaboration

Share security findings with other agents so they avoid introducing vulnerabilities in their code changes.

python3 execution/cross_agent_context.py store \
  --agent "<your-agent>" \
  --action "Completed security audit — 3 critical findings fixed, compliance score 94%" \
  --project <project>

Signed Audit Trail

All security findings are cryptographically signed with the agent's Ed25519 identity, providing tamper-proof audit logs for compliance reporting.

Semantic Cache for Compliance

Cache compliance check results (semantic_cache.py) to avoid redundant AWS API calls. Cache hit at similarity >0.92 returns prior results instantly.