Access Control in Odoo 19:
Groups, Record Rules & Field-Level Security

Your Users Can See (and Edit) More Data Than You Think

Every Odoo implementation starts with a demo where everything works because the admin user has full access. Then the system goes live, 40 employees log in, and within a week someone in marketing discovers they can read every employee's salary. A warehouse user accidentally edits a confirmed purchase order. A portal customer finds they can see invoices belonging to other companies in the group.

These aren't bugs in Odoo. They're the default behavior when access control is not explicitly configured. Odoo 19's security model is powerful — groups, record rules, field-level attributes, and multi-company isolation give you granular control over who sees what. But the framework is permissive by design: if you don't define a rule, access is granted, not denied.

This guide covers the complete access control stack in Odoo 19 — from defining res.groups and group categories, through ir.model.access CRUD matrices and ir.rule record rules, to field-level groups attributes and the dangerous power of sudo(). Every example is production-tested across multi-company deployments with portal users, external integrators, and regulatory audit requirements.

The ir.model.access.csv CRUD Matrix: Who Can Touch Which Models

Model-level access is defined in ir.model.access.csv — a CSV file in your module's security/ directory. Each row grants a specific group Create, Read, Update, and/or Delete access to an entire model. If no row exists for a group-model combination, access is denied by default. This is the first layer of defense: before Odoo even evaluates record rules or field-level security, it checks whether the user's groups have model access at all.

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_custom_transfer_viewer,custom.transfer.viewer,model_custom_transfer,group_warehouse_viewer,1,0,0,0
access_custom_transfer_operator,custom.transfer.operator,model_custom_transfer,group_warehouse_operator,1,1,1,0
access_custom_transfer_manager,custom.transfer.manager,model_custom_transfer,group_warehouse_manager,1,1,1,1
access_custom_transfer_line_viewer,custom.transfer.line.viewer,model_custom_transfer_line,group_warehouse_viewer,1,0,0,0
access_custom_transfer_line_operator,custom.transfer.line.operator,model_custom_transfer_line,group_warehouse_operator,1,1,1,0
access_custom_transfer_line_manager,custom.transfer.line.manager,model_custom_transfer_line,group_warehouse_manager,1,1,1,1

A common mistake is leaving perm_unlink = 1 for operational groups. In most business processes, deletion should be restricted to managers. Operators should archive (deactivate) records instead. Deletion removes audit trails, breaks relational integrity, and can't be undone without a database restore.

Notice that the CSV references model_custom_transfer — this is the XML ID that Odoo generates from your model's _name. For a model named custom.transfer, the corresponding ir.model XML ID is model_custom_transfer (dots replaced with underscores). Getting this wrong is a silent error: the CSV loads without complaint, but the access rule points to a nonexistent model and has no effect.

Also watch the id column (first column). Each ID must be unique across your entire module. We use a consistent naming convention: access_{model}_{group}. Duplicate IDs cause the second rule to silently overwrite the first — another common source of "my access rules don't work" bugs.

Field-Level Security: The groups Attribute and Sensitive Data Protection

Model access controls who can see records. Record rules control which records they see. Field-level security controls which columns are visible on those records. In Odoo 19, any field can be restricted to specific groups using the groups attribute — both in the Python model definition and in the XML view.

When a user without the required group accesses a record, the restricted field simply doesn't exist from their perspective. The ORM strips it from search results, form views, and API responses. It's not hidden with CSS — the data never leaves the server.

from odoo import models, fields, api


class CustomTransfer(models.Model):
    _name = 'custom.transfer'
    _description = 'Warehouse Transfer'

    name = fields.Char(string='Reference', required=True, copy=False)
    state = fields.Selection([
        ('draft', 'Draft'),
        ('confirmed', 'Confirmed'),
        ('done', 'Done'),
        ('cancelled', 'Cancelled'),
    ], default='draft', tracking=True)

    # ── Visible to everyone with model access ──
    partner_id = fields.Many2one('res.partner', string='Customer')
    warehouse_id = fields.Many2one('stock.warehouse', string='Warehouse')
    scheduled_date = fields.Datetime(string='Scheduled Date')

    # ── Restricted to Operators and above ──
    internal_notes = fields.Text(
        string='Internal Notes',
        groups='my_module.group_warehouse_operator',
    )

    # ── Restricted to Managers only ──
    cost_price = fields.Monetary(
        string='Cost Price',
        groups='my_module.group_warehouse_manager',
        currency_field='currency_id',
    )
    margin_percent = fields.Float(
        string='Margin %',
        groups='my_module.group_warehouse_manager',
        compute='_compute_margin',
    )
    override_reason = fields.Text(
        string='Override Reason',
        groups='my_module.group_warehouse_manager',
    )

    currency_id = fields.Many2one(
        'res.currency', related='company_id.currency_id')
    company_id = fields.Many2one(
        'res.company', default=lambda self: self.env.company)

    @api.depends('cost_price')
    def _compute_margin(self):
        for rec in self:
            rec.margin_percent = 0.0  # actual logic omitted

You can also restrict fields at the view level using the groups attribute on XML elements. This is useful when you want to show a field from a base model only to certain groups without modifying the Python model:

<record id="view_custom_transfer_form" model="ir.ui.view">
  <field name="name">custom.transfer.form</field>
  <field name="model">custom.transfer</field>
  <field name="arch" type="xml">
    <form>
      <sheet>
        <group>
          <group string="General">
            <field name="name"/>
            <field name="partner_id"/>
            <field name="warehouse_id"/>
            <field name="scheduled_date"/>
          </group>
          <group string="Financial"
                 groups="my_module.group_warehouse_manager">
            <field name="cost_price"/>
            <field name="margin_percent"/>
            <field name="override_reason"/>
          </group>
        </group>
        <!-- Notes tab: visible to operators and above -->
        <notebook>
          <page string="Internal Notes"
                groups="my_module.group_warehouse_operator">
            <field name="internal_notes"/>
          </page>
        </notebook>
      </sheet>
    </form>
  </field>
</record>

sudo(), with_user(), and Security Bypasses: When and How to Elevate Privileges

Sometimes business logic requires accessing data that the current user can't see. A salesperson confirming an order needs to decrement stock in a warehouse they don't have access to. A portal user submitting a helpdesk ticket needs to create an hr.ticket record on a model they can't normally write to. This is where sudo() enters — and where most security mistakes happen.

from odoo import models, api
from odoo.exceptions import AccessError


class CustomTransfer(models.Model):
    _inherit = 'custom.transfer'

    def action_confirm(self):
        """Confirm transfer — needs to update stock across companies."""
        self.ensure_one()

        # BAD: sudo() on the entire method — bypasses ALL security
        # self.sudo().write({{'state': 'confirmed'}})

        # GOOD: sudo() only for the cross-boundary operation
        self.write({{'state': 'confirmed'}})  # runs as current user

        # Create stock move in target warehouse (may be different company)
        stock_move = self.env['stock.move'].sudo().create({{
            'product_id': self.product_id.id,
            'location_id': self.source_location_id.id,
            'location_dest_id': self.dest_location_id.id,
            'product_uom_qty': self.quantity,
            'company_id': self.dest_warehouse_id.company_id.id,
        }})

        # IMPORTANT: validate before sudo() — never trust user input
        if self.quantity <= 0:
            raise AccessError("Quantity must be positive.")

    def action_portal_submit(self):
        """Portal user submits a request — needs elevated create."""
        # Validate the user is the record owner BEFORE elevating
        if self.partner_id != self.env.user.partner_id:
            raise AccessError("You can only submit your own transfers.")

        # with_user() — run as a specific user instead of superuser
        system_user = self.env.ref('base.user_admin')
        self.with_user(system_user).write({{
            'state': 'submitted',
            'submitted_date': fields.Datetime.now(),
        }})

Multi-Company Security Patterns

Multi-company setups introduce a second dimension of access control. A user might have access to Company A and Company B but should only see Company A's data when working in Company A's context. Odoo 19 handles this with the company_ids / company_id pattern in record rules, but cross-company operations (intercompany invoices, shared warehouses) require careful sudo() or with_company() usage.

The with_company() method switches the environment's active company without changing the user. This is essential when a scheduled action needs to process records across companies sequentially — the record rules re-evaluate for each company context, so the cron sees only the relevant records per iteration:

• self.with_company(company_a).search([]) — returns records where company_id = company_a, respecting the user's existing group permissions.
• self.sudo().with_company(company_b).create(vals) — creates a record in company_b's context as superuser. The company_id field is automatically set to company_b.
• Never use sudo() alone for cross-company operations — sudo bypasses record rules but doesn't change the active company. The record will be created with the wrong company_id.

The golden rules for sudo():

• Validate before elevating. Check user permissions, ownership, and input sanity before calling sudo(). Once you're in sudo mode, all security checks are bypassed.
• Scope it narrowly. Don't sudo() a whole method. Elevate only the specific ORM call that needs it, then drop back to the normal user context.
• Never sudo() user-supplied domains. If a user can control the domain passed to search() or filtered(), calling sudo() on that search lets them read any record in the database.
• Prefer with_user() over sudo() when you need to act as a specific user rather than as superuser. sudo() disables all access checks; with_user() applies that user's actual permissions.

4 Access Control Mistakes That Leak Data in Production Odoo Deployments

Odoo 19 Security Audit: Access Control Review Points

Before any Odoo deployment goes live, we run through this checklist. Every "no" is a finding that gets remediated before launch. We've condensed this from over 100 audits into the items that catch the most common vulnerabilities:

• Every custom model has ir.model.access.csv entries — no model should be accessible without explicit group permissions.
• Every model with company_id has a global multi-company record rule — the ('company_id', 'in', company_ids) pattern must be present.
• Portal-accessible models have dedicated portal record rules — limiting portal users to ('partner_id', '=', user.partner_id.id) or equivalent.
• Sensitive fields use model-level groups — cost prices, margins, salaries, and internal notes restricted at the Python field definition, not just the view.
• Every sudo() call is documented and validated — input validation happens before elevation, and the scope is as narrow as possible.
• Group hierarchies are tested by logging in as real users — not just checking group memberships in the admin panel, but actually navigating the system at each permission level.
• Deletion is restricted to manager-level groups — operational users archive records instead of deleting them.
• No empty group_id in ir.model.access.csv for internal models — public access must be intentional, never accidental.
• Relational fields don't expose restricted models — Many2one fields to hr.employee, account.move, or other sensitive models use related fields to expose only the name, not full model access.
• XML IDs for security records follow naming conventions — consistent naming like group_{module}_{role} and rule_{model}_{scope} makes auditing possible without reading every file.

Debugging AccessError in Odoo 19: Where to Look When Users Can't Access Data

When a user reports "I can't see record X" or gets an AccessError, the investigation follows a consistent flow: model access → record rules → field groups → related model access. Here's the diagnostic sequence we use:

• Step 1: Check ir.model.access for the target model — does the user's group have the required CRUD bit? Use Settings → Technical → Security → Access Controls List.
• Step 2: Check ir.rule for the target model — is a record rule filtering out the record? Toggle developer mode and go to Settings → Technical → Security → Record Rules. Test the domain with the user's context.
• Step 3: Check field-level groups — is the field restricted to a group the user doesn't belong to? Inspect the Python model definition.
• Step 4: Check related models — does the record reference a model (via Many2one) that the user can't read? The name_get call on the related record triggers the AccessError even though the main record is accessible.
• Step 5: Check the Odoo server log with --log-level=debug — the log shows exactly which security check failed and for which record ID.

The most confusing AccessErrors come from computed fields that traverse relational boundaries. A computed field on your model calls self.partner_id.property_payment_term_id. The payment term is on account.payment.term, which requires the Invoicing group. Your user has warehouse access but not invoicing access. The error message says "Access denied on account.payment.term" — which looks completely unrelated to the warehouse form they're trying to open.

For production systems, we recommend maintaining a security test suite as part of your CI pipeline. Each test logs in as a specific user type (viewer, operator, manager, portal) and asserts which records and fields are accessible. When someone modifies a record rule or group hierarchy, the test catches unintended access changes before deployment. This is especially critical after Odoo version upgrades, which can alter base group implied_ids chains.

Optimization Metadata