Groups in Odoo (User Groups & Access Control)

In Odoo, Groups are used to control what users can see and do in the system. They are a core part of security and access management.

What is a Group in Odoo?

A group is a collection of permissions assigned to users.
Groups determine:

• Which menus are visible
• Which models a user can access
• What operations (read, write, create, delete) are allowed
• Which buttons, fields, and views are shown

Example:

• Sales User
• Sales Manager
• Administrator

Where Groups Are Used

a) User Access

Users can belong to multiple groups.

Settings -> Users & Companies -> Users -> Access Rights

b) Model Security (Access Rights)

Defined using ir.model.access.csv

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_sale_order_user,sale.order.user,model_sale_order,base.group_user,1,1,1,0

Controls CRUD permissions

c) Record Rules (Row-level Security)

Limit which records a user can see.

<record id="rule_own_records" model="ir.rule">
    <field name="name">Own Records</field>
    <field name="model_id" ref="model_sale_order"/>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
    <field name="domain_force">[('user_id', '=', user.id)]</field>
</record>

Controls data visibility

d) Views (Buttons, Fields, Menus)

Use groups attribute in XML.

Hide a button

<button name="action_confirm"
        string="Confirm"
        groups="sales_team.group_sale_manager"/>

Hide a field

<field name="salary" groups="hr.group_hr_manager"/>

Menu visibility

<menuitem id="menu_hr"
          name="HR"
          groups="hr.group_hr_user"/>

Types of Groups in Odoo

1.Technical Groups

• Used internally by Odoo
• System / Administrative Groups
• Example: base.group_system

Technical groups are low-level system groups used to:

• Manage system configuration
• Control developer and admin-level access
• Enable technical menus, debug options, and advanced settings
• Protect dangerous or sensitive operations

These groups are not meant for business users.

Common Technical Groups

1.base.group_system

base.group_system (Administrator / Technical Superuser)

base.group_system is the highest-level technical group in Odoo.

A user in this group is considered a System Administrator with almost unrestricted access.

It is used to:

• Access Technical settings
• Modify models, views, fields
• Manage server actions, cron jobs
• Configure security rules
• Perform dangerous operations

 This group bypasses many normal restrictions

What Does base.group_system Control?

• Access to Technical Menu (Settings -> technical)
• Full CRUD on Almost All Models (Even models that normal managers cannot touch.)
• Ability to Install / Uninstall Modules

  • <menuitem id="menu_apps"
              name="Apps"
              groups="base.group_system"/>

• Debug & Developer Tools
  • View external IDs
  • Edit XML views
  • Inspect fields

2.base.group_erp_manager

base.group_erp_manager (Settings / Functional Super Admin)

base.group_erp_manager is a functional administrator group.

This group can configure business modules
but cannot access deep technical internals.

Think of it as a :

Functional Admin (not developer)

What Can base.group_erp_manager Do?

• Access Settings Menu (Settings -> general settings) : But no access to Technical submenu
• Configure Business Modules
  • Sales configuration
  • HR configuration
  • Inventory configuration
  • Accounting settings

What They CANNOT Do

How you can assign from the odoo UI

1.Assign base.group_system (System Administrator)

Administration
? Settings
? Access Rights

This is full system admin access

2.Assign base.group_erp_manager (ERP / Settings Manager)

Administration
? Settings
? Access Rights

Cannot access Technical menu

Example 1: System Administrator Access

<button name="action_reset_database"
        string="Reset Database"
        groups="base.group_system"/>

Use case

• Only administrators should reset system data
• Regular users must never see this button

Prevents accidental system damage

Example 2: Developer-Only Configuration Menu

<menuitem id="menu_technical_settings"
          name="Technical Settings"
          groups="base.group_system"/>

Use case

• Show technical configuration only to developers/admins

• Hide ORM models, cron jobs, server actions

   

Example 3: Python-Level Protection

def action_delete_logs(self):
    if not self.env.user.has_group('base.group_system'):
        raise AccessError("Only administrators can perform this action")

Use case

• Even if someone bypasses UI, logic is protected
• Critical for data safety

When to Use Technical Groups

-System-level features
-Developer tools
-Configuration screens
-Data migration / cleanup
-Security-sensitive actions

Do NOT use technical groups for normal business workflows

2.Functional Groups

• Sales, HR, Inventory, Accounting
• Example: sales_team.group_sale_user

Functional groups represent business roles and job responsibilities.

They:

• Control access to modules and features
• Represent real company roles
• Are assigned to end users

Examples:

• Sales User
• HR Manager
• Inventory User
• Accountant

Common Functional Groups

Example 1: Sales User vs Sales Manager

Sales User

• Create quotations
• Confirm sales orders
• View customers

Sales Manager

• Approve discounts
• Modify confirmed orders
• View sales reports

<button name="action_approve_discount"
        string="Approve Discount"
        groups="sales_team.group_sale_manager"/>

Real-world

Sales staff creates quotations
Sales manager approves special discounts

Example 2: HR Employee vs HR Manager

<field name="salary"
       groups="hr.group_hr_manager"/>

Use case

• Employees can view profiles
• Only HR managers can see salary details

 Protects confidential information

Example 3: Inventory Workflow

<button name="action_inventory_adjust"
        groups="stock.group_stock_manager"/>

Real-world

• Warehouse staff processes delivery
• Manager approves inventory corrections

Simple Rule to Remember

If the role exists in the company ? Functional Group
If the role exists only in the system ? Technical Group

3.Custom Groups

Created by developers for custom logic.

<record id="group_project_reviewer" model="res.groups">
    <field name="name">Project Reviewer</field>
    <field name="category_id" ref="base.module_category_project"/>
</record>

Implied Groups (Group Inheritance)

A group can automatically include another group.

<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>

User gets permissions of both groups

Checking Groups in Python

if self.env.user.has_group('sales_team.group_sale_manager'):
    # logic here

Best Practices

- Use groups + record rules together
-  Avoid putting logic only in views
- Create separate groups for custom features
- Use implied groups for hierarchy (User ? Manager)