Enabling one checkbox on a user’s permissions screen — “Invoicing: Manager,” say — and the user quietly picks up two or three other groups nobody explicitly assigned. Nothing broke; that’s implied_ids, a real, documented mechanism, and it’s worth understanding before assuming a user’s group list should match exactly what a form shows as checked.
The short version: a group (res.groups) can declare other groups it implies — assigning the first automatically assigns every implied one too. It's real inheritance in one direction only: removing the implied group individually, later, doesn't remove the group that implied it, per Odoo's own description of the mechanism as "a convenience pseudo-inheritance relationship."
What implied_ids actually does
Per Odoo’s own developer documentation on security, a group’s implied_ids field lists other groups to set on any user assigned this one — described precisely as “a convenience pseudo-inheritance relationship.” Assigning “Sales: Manager” to a user, for instance, commonly implies “Sales: User” underneath it, since a manager should obviously have at least whatever a regular user has — without every module having to redundantly grant both explicitly everywhere.
<record id="group_sale_manager" model="res.groups">
<field name="name">Manager</field>
<field name="implied_ids" eval="[(4, ref('group_sale_salesman'))]"/>
</record>Why “pseudo” inheritance, specifically
The documentation’s own choice of words — “pseudo-inheritance” — is precise, not casual: it’s possible to explicitly remove an implied group from a user without removing the group that implied it. A user assigned “Manager” (which implies “User”) can have “User” individually unchecked afterward, and stays a Manager without it. This is different from what “inheritance” usually implies in a type-system sense, where the parent relationship is structural and can’t be selectively broken — here it’s closer to “assigning A also assigns B as a starting point,” not “A structurally requires B forever.”
Watch out: because of exactly this, a user's current group list can't be fully reconstructed just by looking at which higher-level checkboxes are checked on their form — someone may have later removed an implied group individually, and the form's own checkbox state reflects the current explicit assignment, not the original implication that put it there. When auditing exactly what a specific user can do, the actual list of currently-assigned groups (developer mode → the user's own Groups field) is the source of truth, not an assumption based on the higher-level permission checkboxes alone.
A worked example: three levels, one checkbox
A typical three-level permission structure — User, Manager, Administrator, each implying the one below — resolves like this the moment “Administrator” is assigned:
| Group assigned | Implies | User ends up with |
|---|---|---|
| Administrator | Manager | Administrator + Manager + User (transitively) |
| Manager | User | Manager + User |
| User | (nothing) | User only |
Assigning only “Administrator” to a user’s form results in all three being set on the actual user record — the chain resolves transitively, not just one level deep. Nothing on the simplified dropdown reveals that two additional groups were just granted; the UI shows the single highest level selected, by design, since that’s the level a human is meant to reason about day to day.
Category: what turns a list of groups into radio buttons
A separate field, category_id, groups related res.groups records together for presentation — per the same documentation, it “serves to associate groups with an Odoo App… and convert them into an exclusive selection in the user form.” This is why a user’s permission screen shows most rows as a single dropdown (Administrator / Manager / User / none) rather than a pile of independent checkboxes: groups sharing a category are treated as mutually exclusive levels of the same permission, and picking one is what actually triggers implied_ids to layer in everything below it.
Why this matters beyond curiosity
Two practical consequences, both real:
- Auditing “why can this user do X” has to consider implied groups, not just explicitly-checked ones. A user with unexpected access to a feature may have gotten there entirely through an implication chain from a completely different, seemingly-unrelated permission level.
- A custom module adding
implied_idsto an existing core group affects every user who has that group already, immediately on install/upgrade — not just users assigned the group afterward. This is a real, if intentional, way for a module to widen what an existing group grants across an entire database in one update.
Frequently asked questions
Is implied_ids the same mechanism as a record rule granting access via multiple groups?
No — record rules combine multiple *separate* groups' domains (AND for global, OR for group-specific) at query time; implied_ids is a property of the group definition itself, determining which other groups get assigned to a user in the first place, before any record rule is ever evaluated.
Does removing a group from a user remove everything it originally implied?
No — per the "pseudo-inheritance" wording above, an implied group stays assigned on its own once granted, unless it's separately, explicitly removed. Removing the implying group doesn't cascade to remove what it once implied.
Can a group imply another group that in turn implies a third?
Yes — implication chains, and Odoo resolves the full transitive set when a group is assigned; a user assigned only the top-level group ends up with every group in the chain beneath it, not just the immediate one.
Why do some permission rows show as a dropdown and others as independent checkboxes?
Groups sharing the same category_id render as one exclusive dropdown (a "level" selection); groups without a shared category, or explicitly meant to be independent, render as separate checkboxes instead.
Can I see a user's full resolved group list, including implied ones, anywhere in the UI?
Yes — in developer mode, a user's own form has a Groups tab/field listing every group currently assigned, implied ones included, which is the actual ground truth rather than inferring it from the simplified permission-level dropdowns.
Further reading
- Security in Odoo — official Odoo 18.0 developer documentation, the primary source for
implied_idsandcategory_idabove.
And on this site: Why Can’t This User See a Record They Should? for the record-rule layer this one is often confused with, and the External ID / XML ID Helper for naming a new group or its implied_ids records consistently.