If you’ve built custom Odoo modules that usegroups_id on view records to control which users can see specific views, that mechanism no longer works. The field has been removed from ir.ui.view, and the documentation now reflects the change: the attribute that once let developers assign a Many2many relationship to user groups on view records is gone.
What groups_id Used to Do
The groups_id field on ir.ui.view was a Many2many relationship linking view records to res.groups. When populated, it restricted the view to users belonging to those groups. If a user wasn’t in any of the specified groups, the view — including any view extensions that inherited from it — wouldn’t load for them.
It was a blunt instrument but a convenient one. Developers could lock down entire form views, tree views, or kanban views to specific user roles without writing record rules or modifying the underlying model permissions. For quick prototyping or simple access scenarios, it worked well enough.
Why It Was Removed
The removal aligns with a broader shift in how Odoo handles access control. View-level restrictions were always somewhat fragile — they controlled what the UI showed, but didn’t necessarily prevent data access through other means like RPC calls, reports, or alternative views. A user who couldn’t see a form view might still access the same data through a list view, a pivot table, or a direct API call.
True access control in Odoo happens at the model level throughir.model.access records and ir.rulerecord rules. These mechanisms control data access regardless of which view is rendering it, making them both more reliable and more predictable than view-level group restrictions.
What Developers Need to Change
Any custom module that sets groups_idon a view record — either through XML data files or programmatically — needs to be updated. The field simply doesn’t exist anymore, so referencing it will cause errors.
The migration path depends on what the groups_id was actually protecting:
If it was hiding UI elements from certain users: Use the groups attribute on individual fields or page elements within the view XML instead. This hides specific parts of a view rather than the entire view, which is usually what developers actually wanted.
If it was enforcing data security: Create properir.model.access records and ir.rulerecord rules. These operate at the ORM level and prevent data access regardless of the interface being used.
If it was used on view extensions: Thegroups attribute on xpath elements within inherited views still works and can achieve per-element visibility control without needing the view-level field.
The Bigger Picture
This is part of an ongoing cleanup of Odoo’s view system. The framework has accumulated several approaches to access control over the years — model-level ACLs, record rules, view-level groups, field-level groups, menu-level groups — and the overlap created confusion about which mechanism to use and which ones actually enforced security versus merely hiding UI elements.
Removing groups_idfrom views draws a clearer line: views handle presentation, models handle data access. If you need to hide something from a user, use field-level groups for cosmetic control and model-level rules for actual security. The view itself shouldn’t be in the business of deciding who can see what.
For existing codebases, this means a review of any module that touches groups_idon view records. The fix is usually straightforward — most uses were cosmetic hiding that maps cleanly to field-level groups attributes — but it needs to happen before upgrading, or the module won’t load.