Introduction
In Odoo, models define how data is structured and stored in the database. Every piece of business data you work with, from sales orders to invoices to contacts, lives in a model.
Understanding Odoo models is essential for both developers and functional consultants. Models are the foundation of the Odoo data architecture. They define Odoo fields, relationships, and business logic.
But where does Odoo store information about every model in the system? The answer is ir.model. This model in Odoo is the registry that holds metadata about all other models. Whether you are building custom modules, exploring the API, or debugging Odoo, you will encounter ir.model.
What is the ir.model Model
The ir.model model is the metadata registry for all Odoo models. It stores one record per model in the system. When you define a new model in Python or create one via Odoo Studio, Odoo creates or updates an ir.model record.
This model in Odoo is used by the base module. It is part of the core framework. Every Odoo model, whether it is a regular model, an Odoo abstract model, or an Odoo transient model, has a corresponding ir.model entry.
The model is defined in the base module. It is closely related to ir.model.fields, which stores metadata about each Odoo field on each model. Together, ir.model and ir.model.fields form the backbone of Odoo's introspection and reflection capabilities.
Developers use ir.model when they need to list available models, check model inheritance, or build dynamic tools that work with any model. The API model in Odoo exposes ir.model through XML-RPC and JSON-RPC.
Key Fields in the Model
Here are the most important Odoo fields in the ir.model model. Understanding these will help you work effectively with the model registry.
1. name
Type: Char. This field stores the human-readable description of the model. It is translatable and displayed in the Technical Settings and in developer tools. It is the label you see when browsing models.
2. model
Type: Char. The technical name of the model. This is the string you use in Python code, such as res.partner or sale.order. It is required and indexed for fast lookups.
3. info
Type: Text. Additional information or notes about the model. Used for documentation and internal use. Can be empty for most models.
4. state
Type: Selection. Indicates whether the model is base (from Odoo modules) or manual (created via Odoo Studio or custom code). Base models are protected. Manual models can be modified more freely.
5. transient
Type: Boolean. When True, this model is an Odoo transient model. Transient models are temporary. Their records are automatically cleaned up. Used for wizards and temporary data.
6. field_id
Type: One2many (ir.model.fields). The list of Odoo fields defined on this model. Each ir.model.fields record describes one field: its name, type, and other attributes.
7. access_ids
Type: One2many (ir.model.access). Access rights for this model. Each record defines which groups can create, read, update, or delete records. Used for security.
8. rule_ids
Type: One2many (ir.rule). Record rules for this model. Record rules restrict which records users can see. Used for row-level security.
9. inherited_model_ids
Type: Many2many (ir.model). The parent models when using Odoo model inheritance. When you inherit a model in Odoo, the child model links to its parent here. This is Odoo inherit model at work.
10. modules
Type: Char. A computed field listing the modules where this model is defined. For models extended by multiple modules, this shows all of them. Useful for understanding dependencies.
11. sort
Type: Integer. Display order for the model in the Technical Settings menu. Lower values appear first. Used for organizing the model list.
12. constrains
Type: Text. Python constraint definitions. Stores the code for @api.constrains decorators. Used when the model has custom validation logic.
13. post_constrains
Type: Text. Python post-constraint definitions. Similar to constrains but for post-validation. Used for advanced validation scenarios.
14. sql_constraints
Type: Text. SQL constraint definitions. Database-level constraints like unique indexes. Ensures data integrity at the database level.
15. view_ids
Type: One2many (ir.ui.view). Computed field listing views associated with this model. Used for introspection and view management.
16. record_count
Type: Integer. Computed field showing the number of records in this model. Useful for reporting and understanding how much data a model holds.
17. display_name
Type: Char. Computed field for the display representation. Used when the record is shown in lists and relations. Typically combines name and model.
18. create_date
Type: Datetime. Stores the date and time when the record was created. Automatically managed by Odoo.
19. create_uid
Type: Many2one (res.users). The user who created the record. Used for auditing and tracking.
20. write_date
Type: Datetime. Stores the date and time of the last modification. Also automatically managed.
21. write_uid
Type: Many2one (res.users). The user who last modified the record. Used for auditing.
22. active
Type: Boolean. Soft delete flag. When False, the record is archived. Used for deprecated models.
23. id
Type: Integer. The database ID. Unique identifier for each ir.model record. Used when referencing the model in API calls.
24. restrict_functionality
Type: Boolean. When True, this model has restricted functionality in certain Odoo editions. Used for enterprise vs community differentiation.
25. is_mail_thread
Type: Boolean. Indicates whether the model is a mail thread. Mail thread models have chatter, messages, and followers. Used for models that support discussions.
26. is_mail_activity
Type: Boolean. Indicates whether the model supports activities. Activity models have the activity planner and next action tracking.
How This Model Is Used in Business Workflows
1. Technical Settings and Configuration
Administrators use the Technical Settings menu to browse models. The ir.model records define what appears in that list. Each model shows its name, description, and field count.
2. Access Rights Management
When configuring security, administrators assign access rights to groups. The access_ids on ir.model define which groups can create, read, update, or delete records for each model.
3. Odoo Studio Customization
When users create custom models in Odoo Studio, Odoo creates new ir.model records with state manual. The field_id relation is populated with the custom Odoo fields.
4. API and Integration Discovery
External systems integrate with Odoo via the XML-RPC or JSON-RPC API. They can query ir.model to discover available models and their structure. The API model in Odoo exposes this for introspection.
5. Module Development and Debugging
Developers use ir.model when building modules. They check inherited_model_ids to understand Odoo model inheritance. They inspect field_id to see all Odoo fields on a model.
How Developers Extend This Model
Developers rarely extend ir.model directly. Instead, they work with it when they define new models. The model registry is updated automatically when you load a module.
Model Inheritance
When you use _inherit = 'res.partner' in your Python, Odoo updates the ir.model record for res.partner. The inherited_model_ids on your new model's ir.model record will link to the parent. This is Odoo model inheritance at work. The inherit model in Odoo keeps the registry in sync.
Adding Fields
When you add new Odoo fields to a model, Odoo creates ir.model.fields records. These link to ir.model via the model_id field. The ir.model record itself is not modified.
Python Extensions
You do not typically override ir.model methods. The model is part of the core framework. If you need to customize behavior, you extend the models that ir.model describes, not ir.model itself.
Odoo Studio
Odoo Studio creates ir.model and ir.model.fields records when you build custom models. No code required. The transient flag distinguishes Odoo transient model from regular models. Abstract models (Odoo abstract model) do not create ir.model records because they have no database table.
Best Practices
- Use ir.model for introspection and discovery. When building integrations, query ir.model to list available models instead of hardcoding.
- Use the model field for lookups. It is indexed. Search by model name when you need a specific model's metadata.
- Check inherited_model_ids when building custom modules. Understand the inheritance chain before extending.
- Use the API model in Odoo (XML-RPC or JSON-RPC) to read ir.model. Avoid modifying it unless you are building a Studio-like tool.
- Use ir.model.fields for field-level introspection. The field_id relation gives you all Odoo fields on a model.
Common Mistakes
- Modifying ir.model records directly. The registry is managed by Odoo. Changes can break the system or be overwritten on upgrade.
- Confusing ir.model with the Python model class. ir.model is the database record. The Python class is the actual model. They are related but different.
- Assuming all models have ir.model records. Odoo abstract model classes do not create database tables or ir.model records.
- Forgetting that transient models are temporary. The transient flag means the Odoo transient model data is cleaned up. Do not use it for permanent data.
- Querying ir.model without filtering. A typical Odoo instance has hundreds of models. Always filter by model name or use search domains.
Conclusion
The ir.model model is the registry of all Odoo models. It stores metadata about every model in the system. Understanding its fields and how it relates to ir.model.fields will help you navigate the Odoo data architecture.
Whether you are a functional consultant exploring Technical Settings or a developer building API integrations, a solid grasp of ir.model will save time and prevent errors.
Need Help With Your Odoo Implementation ?
Dasolo helps companies implement, customize, and optimize Odoo. We specialize in API integrations and Odoo development. Our team has deep experience with the Odoo data architecture and models like ir.model.
If you need help with your Odoo implementation, custom modules, or integrations, we are here to help. Book a demo to discuss your project.