{"id":9677,"date":"2026-10-06T16:08:02","date_gmt":"2026-10-06T13:08:02","guid":{"rendered":"https:\/\/machinser.com\/?p=9677"},"modified":"2026-10-06T16:09:09","modified_gmt":"2026-10-06T13:09:09","slug":"odoo-19-custom-module-components","status":"publish","type":"post","link":"https:\/\/machinser.com\/ar\/odoo-19-custom-module-components\/","title":{"rendered":"Odoo 19 Custom Module Components: A Powerful Guide to Building Better Modules"},"content":{"rendered":"

Once the basic structure of an Odoo 19 custom module is understood, the next step is to understand what each component actually does. A custom module is not simply a collection of Python and XML files. Different components are responsible for different parts of the application.<\/p>\n

Models define data and business logic.<\/p>\n

Views define how users interact with that data.<\/p>\n

Security controls who can access it.<\/p>\n

Data files provide predefined records and configuration.<\/p>\n

Actions and menus connect the functionality to the Odoo interface.<\/p>\n

Controllers, wizards, reports, and frontend assets can be added when the module requires more advanced functionality.<\/p>\n

This separation allows an Odoo 19 custom module to remain organized and maintainable as its functionality grows.<\/p>\n

1. Models: The Core of the Business Logic<\/h2>\n

The models directory contains the Python<\/a> code responsible for defining or extending Odoo models. Models can contain fields, business logic, computed values, constraints, onchange methods, automated operations, model inheritance, and relationships between records.<\/p>\n

from odoo import models, fields\r\n\r\nclass EmployeeDetails(models.Model):\r\n    _name = \"employee.details\"\r\n    _description = \"Employee Details\"\r\n\r\n    name = fields.Char(string=\"Employee Name\")\r\n    email = fields.Char(string=\"Email\")\r\n    phone = fields.Char(string=\"Phone\")\r\n    active = fields.Boolean(default=True)<\/pre>\n
The _name attribute defines the technical name of the model. The fields define the information that the model stores. Methods inside the model contain the business rules that determine how the application behaves.<\/p>\n
\"Odoo
Figure 1: Python model defining fields and business logic in the Employee Management custom module.<\/figcaption><\/figure>\n
<\/div>\n
2. Common Field Types<\/h2>\n
Odoo provides many field types for representing different kinds of business data.<\/p>\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Field<\/td>\nTypical use<\/td>\n<\/tr>\n
Char<\/td>\nShort text<\/td>\n<\/tr>\n
Text<\/td>\nLong text<\/td>\n<\/tr>\n
Integer<\/td>\nWhole numbers<\/td>\n<\/tr>\n
Float<\/td>\nDecimal values<\/td>\n<\/tr>\n
Boolean<\/td>\nTrue\/False values<\/td>\n<\/tr>\n
Date<\/td>\nDates<\/td>\n<\/tr>\n
Datetime<\/td>\nDate and time<\/td>\n<\/tr>\n
Selection<\/td>\nFixed list of choices<\/td>\n<\/tr>\n
Many2one<\/td>\nLink to one record<\/td>\n<\/tr>\n
One2many<\/td>\nMultiple related records<\/td>\n<\/tr>\n
Many2many<\/td>\nMultiple records on both sides<\/td>\n<\/tr>\n
Monetary<\/td>\nCurrency values<\/td>\n<\/tr>\n
Binary<\/td>\nFiles or binary data<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
department_id = fields.Many2one(\r\n    \"hr.department\",\r\n    string=\"Department\"\r\n)\r\n\r\njoining_date = fields.Date(\r\n    string=\"Joining Date\"\r\n)\r\n\r\nsalary = fields.Float(\r\n    string=\"Salary\"\r\n)<\/pre>\n
Choosing the appropriate field type is important because it affects how the data is stored, displayed, searched, and related to other records.<\/p>\n
3. Model Relationships<\/h2>\n
Real business applications rarely consist of completely independent records. Odoo provides relational fields to connect models.<\/p>\n
Many2one<\/h4>\n
A record belongs to one related record.<\/p>\n
department_id = fields.Many2one(\r\n    \"hr.department\"\r\n)<\/pre>\n
For example, many employees can belong to the same department.<\/p>\n
One2many<\/h4>\n
A One2many field represents multiple related records from the other side of a relationship.<\/p>\n
employee_ids = fields.One2many(\r\n    \"employee.details\",\r\n    \"department_id\"\r\n)<\/pre>\n
Many2many<\/h4>\n
A Many2many field allows records to be related to multiple records on both sides of a relationship.<\/p>\n
sskill_ids = fields.Many2many(\r\n    \"employee.skill\"\r\n)<\/pre>\n
These relationships are fundamental when designing custom business applications in Odoo.<\/p>\n
4. Business Logic in Models<\/h2>\n
Models are not only used to define fields. They can also contain methods that implement business rules.<\/p>\n
def action_confirm(self):\r\n    for record in self:\r\n        record.state = \"confirmed\"<\/pre>\n
A method can be triggered by buttons, automated processes, scheduled actions, other model methods, controllers, and user interactions. This is where much of an application’s business behavior is implemented.<\/p>\n
5. Model Inheritance<\/h2>\n
One of Odoo’s most useful development features is model inheritance. Instead of creating a completely new model, a custom module can extend an existing Odoo model.<\/p>\n
from odoo import models, fields\r\n\r\nclass SaleOrder(models.Model):\r\n    _inherit = \"sale.order\"\r\n\r\n    customer_reference = fields.Char(\r\n        string=\"Customer Reference\"\r\n    )<\/pre>\n
This adds a new field to the existing Sales Order model. The original Odoo model does not need to be copied or rewritten. This approach is useful when implementing customer-specific requirements.<\/p>\n
6. Views: Connecting Data to the User Interface<\/h2>\n
Models define the data, but users need an interface to work with that data. This is the role of views. Odoo views are generally defined using XML.<\/p>\n
Form<\/h6>\n
List<\/h6>\n
Kanban<\/h6>\n
Search<\/h6>\n
Calendar<\/h6>\n
Graph<\/h6>\n
Pivot<\/h6>\n
Activity<\/h6>\n
The view determines how the fields are presented to the user.<\/p>\n
\"\"
Figure 2: Form view of the Employee Management custom module, showing how model fields are presented to users.<\/figcaption><\/figure>\n
<\/div>\n
 <\/p>\n
7. Form Views<\/h2>\n
A form view is used to create and edit individual records. Typical examples include customer forms, employee forms, sales orders, purchase orders, and products.<\/p>\n
<sheet>
\n<group>
\n<field name=”name”\/>
\n<field name=”email”\/>
\n<\/group>
\n<\/sheet><\/p>\n
A form can organize fields using group, sheet, notebook, page, and header elements.<\/p>\n
8. List Views<\/h2>\n
List views display multiple records at the same time. They are useful for searching records, sorting records, selecting records, and performing bulk operations.<\/p>\n
<list>
\n<field name=”name”\/>
\n<field name=”email”\/>
\n<field name=”phone”\/>
\n<\/list><\/p>\n
\n
<\/p>\n
\"\"
Figure 3: List view displaying employee records and the fields configured for the custom model.<\/figcaption><\/figure>\n<\/div>\n
 <\/p>\n
9. Search Views<\/h2>\n
Search views control the available search fields, filters, and grouping options.<\/p>\n
<search>\r\n\u00a0\u00a0\u00a0 <field name=\"name\"\/>\r\n\r\n\u00a0\u00a0\u00a0 <filter\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 name=\"active\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 string=\"Active\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 domain=\"[('active', '=', True)]\"\r\n\u00a0\u00a0\u00a0 \/>\r\n<\/search><\/pre>\n
Search views can provide search fields, filters, group-by options, and predefined search conditions. For modules containing many records, a good search view can significantly improve usability.<\/p>\n
\n
\"\"
Figure 4: Search view XML showing searchable fields, a Draft filter, and a group-by option.<\/figcaption><\/figure>\n
<\/p>\n<\/div>\n
10. Actions and Menus<\/h2>\n
Views alone do not determine how users navigate to a feature. An action connects a model with a user interface.<\/p>\n
<record id=\"employee_details_action\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 model=\"ir.actions.act_window\">\r\n\r\n\u00a0\u00a0\u00a0 <field name=\"name\">Employees<\/field>\r\n\r\n\u00a0\u00a0\u00a0 <field name=\"res_model\">\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 employee.details\r\n\u00a0\u00a0\u00a0 <\/field>\r\n\r\n\u00a0\u00a0\u00a0 <field name=\"view_mode\">\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 list,form\r\n\u00a0\u00a0\u00a0 <\/field>\r\n\r\n<\/record><\/pre>\n
A menu can then trigger the action:<\/p>\n
<menuitem\r\n\u00a0\u00a0\u00a0 id=\"employee_menu\"\r\n\u00a0\u00a0\u00a0 name=\"Employees\"\r\n\u00a0\u00a0\u00a0 action=\"employee_details_action\"\r\n\/><\/pre>\n
The basic relationship is Menu to Action to View to Model.<\/p>\n
11. Security and Access Rights<\/h2>\n
Security is an important part of every business application. Odoo uses access control mechanisms to determine what users can do with a model.<\/p>\n
A common module file is:<\/p>\n
security\/
\n\u2514\u2500\u2500 ir.model.access.csv<\/p>\n
Access records can control Read, Write, Create, and Delete permissions.<\/p>\n
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink\r\naccess_employee,employee access,model_employee_details,base.group_user,1,1,1,1<\/span><\/pre>\n
The four permission columns determine whether users in the specified group can perform each operation.<\/p>\n
12. Groups and More Granular Security<\/h2>\n
Access control can be assigned to specific user groups. For example, an application might have Employee User, Employee Manager, HR Manager, and Administrator groups.<\/p>\n
Different groups can receive different permissions. For more advanced requirements, Odoo also provides record rules that can restrict which records a user can access.<\/p>\n
This creates an important distinction:<\/p>\n
Access rights: What operations can the user perform?<\/h6>\n
Record rules: Which records can the user perform those operations on?<\/h6>\n
For example, a salesperson might be allowed to read customers but only access customers belonging to their assigned sales team.<\/p>\n
13. Data Files<\/h2>\n
Custom modules often need predefined records. These can be loaded through XML or CSV files.<\/p>\n
Sequences<\/h6>\n
Configuration records<\/h6>\n
Default settings<\/h6>\n
Email templates<\/h6>\n
Scheduled actions<\/h6>\n
Predefined groups<\/h6>\n
Initial records<\/h6>\n
Data files are especially useful when a module requires certain records to exist immediately after installation.<\/p>\n
14. Wizards<\/h2>\n
Wizards are used for temporary user interactions. They are commonly implemented using TransientModel.<\/p>\n
For example, a wizard could allow a user to select a date range, select a customer, choose a report type, and then generate a report.<\/p>\n
wizard\/\r\n\u251c\u2500\u2500 __init__.py\r\n\u2514\u2500\u2500 employee_report_wizard.py<\/pre>\n
Unlike normal business models, wizard records are temporary and are intended for short-lived operations.<\/p>\n
15. Reports<\/h2>\n
Custom modules can also contain reports. Odoo supports report generation using its reporting framework and QWeb templates.<\/p>\n
Invoices<\/h6>\n
Quotations<\/p>\n
Delivery documents<\/p>\n
Employee documents<\/p>\n
Certificates<\/p>\n
Business reports<\/p>\n
A report generally combines Odoo data, a report action, and a QWeb template to produce the final document.<\/p>\n
16. Controllers<\/h2>\n
Controllers are used when a module needs to handle HTTP requests. They can be useful for website functionality, custom web pages, external integrations, APIs, and receiving external requests.<\/p>\n
A custom integration can follow a simple flow from an external system to an HTTP request, then to an Odoo controller, business logic, and an Odoo model.<\/p>\n
Controllers should be used carefully, especially when exposing business data through external endpoints.<\/p>\n
17. Static Assets<\/h2>\n
A module can also contain frontend resources such as JavaScript, CSS, XML templates, images, and module icons.<\/p>\n
static\/\r\n\u251c\u2500\u2500 src\/\r\n\u2502 \u251c\u2500\u2500 js\/\r\n\u2502 \u251c\u2500\u2500 css\/\r\n\u2502 \u2514\u2500\u2500 xml\/\r\n\u2514\u2500\u2500 description\/<\/pre>\n
These resources are useful for modules that modify the Odoo web client or website.<\/p>\n
18. How the Components Work Together<\/h2>\n
The components of an Odoo 19 custom module are connected rather than independent.<\/p>\n
User
\n\u2193
\nMenu
\n\u2193
\nAction
\n\u2193
\nView
\n\u2193
\nModel
\n\u2193
\nBusiness Logic
\n\u2193
\nDatabase<\/p>\n
Security works across this flow by determining what the current user is allowed to do. Reports, automation, controllers, and frontend assets can extend the same basic structure.<\/p>\n
19. Choosing the Right Component<\/h2>\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Requirement<\/td>\nUsually handled by<\/td>\n<\/tr>\n
Store new information<\/td>\nModel + Fields<\/td>\n<\/tr>\n
Add a field to an existing Odoo model<\/td>\nModel inheritance<\/td>\n<\/tr>\n
Change how information appears<\/td>\nXML View<\/td>\n<\/tr>\n
Add a new menu<\/td>\nMenu + Action<\/td>\n<\/tr>\n
Restrict user operations<\/td>\nAccess Rights<\/td>\n<\/tr>\n
Restrict records by conditions<\/td>\nRecord Rules<\/td>\n<\/tr>\n
Add predefined records<\/td>\nData files<\/td>\n<\/tr>\n
Temporary user input<\/td>\nWizard<\/td>\n<\/tr>\n
Printable document<\/td>\nReport<\/td>\n<\/tr>\n
External HTTP endpoint<\/td>\nController<\/td>\n<\/tr>\n
Change web-client behavior<\/td>\nJavaScript \/ Assets<\/td>\n<\/tr>\n
Add custom styling<\/td>\nCSS \/ Assets<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
20. A Good Custom Module Design<\/h2>\n
A well-designed module keeps responsibilities separated. For example:<\/p>\n
employee_management\/\r\n\u2502\r\n\u251c\u2500\u2500 models\/\r\n\u2502 \u251c\u2500\u2500 employee.py\r\n\u2502 \u2514\u2500\u2500 department.py\r\n\u2502\r\n\u251c\u2500\u2500 views\/\r\n\u2502 \u251c\u2500\u2500 employee_views.xml\r\n\u2502 \u2514\u2500\u2500 department_views.xml\r\n\u2502\r\n\u251c\u2500\u2500 security\/\r\n\u2502 \u251c\u2500\u2500 ir.model.access.csv\r\n\u2502 \u2514\u2500\u2500 security.xml\r\n\u2502\r\n\u251c\u2500\u2500 data\/\r\n\u2502 \u2514\u2500\u2500 sequence.xml\r\n\u2502\r\n\u251c\u2500\u2500 wizard\/\r\n\u2502 \u2514\u2500\u2500 employee_report.py\r\n\u2502\r\n\u251c\u2500\u2500 report\/\r\n\u2502 \u2514\u2500\u2500 employee_report.xml\r\n\u2502\r\n\u2514\u2500\u2500 static\/\r\n\u2514\u2500\u2500 src\/<\/pre>\n
Not every module needs all these directories. They should be added only when the functionality requires them.<\/p>\n
21. Common Development Considerations<\/h2>\n
Keep business logic in Python<\/h6>\n
Avoid putting complex business logic directly into views.<\/p>\n
Keep views focused on presentation<\/h6>\n
XML should primarily control how information is displayed and interacted with.<\/p>\n
Apply security deliberately<\/h6>\n
Do not give every user full read, write, create, and delete access simply because it makes development easier.<\/p>\n
Avoid unnecessary inheritance<\/h6>\n
Extend an existing model when the requirement genuinely belongs to that model.<\/p>\n
Keep modules focused<\/h6>\n
A module should have a clear business purpose instead of becoming a collection of unrelated customizations.<\/p>\n
Conclusion<\/h2>\n
An Odoo 19 custom module is built from several specialized components rather than a single type of code. The most important development concepts are models for data and business logic, fields for data representation, inheritance for extending existing functionality, views for the user interface, actions and menus for navigation, security for access control, data files for predefined records and configuration, wizards for temporary workflows, reports for business documents, and controllers and assets for web and frontend functionality.<\/p>\n
Understanding how these components interact is more important than memorizing folder names. Once the responsibility of each component is clear, custom requirements can be mapped to the appropriate Odoo development mechanism.<\/p>\n
This gives developers a practical foundation for building clean, maintainable Odoo 19 custom modules without unnecessarily modifying Odoo’s standard source code.<\/p>\n
 <\/p>\n
To learn more about setting up your module directory and manifest file, read our complete guide on Odoo 19 Module Structure: Developer’s Handbook<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Once the basic structure of an Odoo 19 custom module is understood, the next step is to understand what each component actually does. A custom module is not simply a collection of Python and XML files. Different components are responsible for different parts of the application. Models define data and business logic. Views define how […]<\/p>\n","protected":false},"author":5,"featured_media":9692,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[330,318,313,195,192],"tags":[],"class_list":["post-9677","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-custome-addons","category-odoo-19","category-odoo-configuration","category-odoo-customization","category-odoo-erp"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/machinser.com\/wp-content\/uploads\/2026\/10\/Odoo-19-Custom-Module-Guide.png","_links":{"self":[{"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/posts\/9677","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/comments?post=9677"}],"version-history":[{"count":4,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/posts\/9677\/revisions"}],"predecessor-version":[{"id":9691,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/posts\/9677\/revisions\/9691"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/media\/9692"}],"wp:attachment":[{"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/media?parent=9677"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/categories?post=9677"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/machinser.com\/ar\/wp-json\/wp\/v2\/tags?post=9677"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}