< _

Creating Your First Odoo Module

Abstract generated cover for Creating Your First Odoo Module.

An Odoo module is a package of functionality. It can add models, fields, views, menus, access rules, reports, scheduled actions, controllers, and business logic. If you are coming from general Python or web development, the first thing to understand is that an Odoo module is not a standalone app in the usual sense. It plugs into the Odoo framework. That means your module works inside Odoo's ORM, security system, view system, and application lifecycle.

The Mental Model

Think of a module as a controlled extension to Odoo. It can:

  • define new business objects
  • add fields to existing objects
  • change how records are displayed
  • create menus and actions
  • add validation rules
  • connect to external systems
  • define permissions The module does not own the whole application. It adds or changes a slice of behavior. That is why small modules are easier to maintain than huge modules that try to control everything.

A Typical Module Shape

An Odoo module commonly has a structure like this: ```plain text mymodule/ init.py manifest.py models/ init.py mymodel.py views/ mymodelviews.xml security/ ir.model.access.csv data/ scheduled_actions.xml

Not every module needs every folder.
The manifest describes the module.
The Python files define behavior.
The XML files often define views, menus, actions, and data records.
The security files define who can access which models.
## The Manifest
The \`__manifest__.py\` file tells Odoo about the module.
It usually includes metadata:
```python
{
    "name": "My Module",
    "depends": ["base"],
    "data": [
        "security/ir.model.access.csv",
        "views/my_model_views.xml",
    ],
    "installable": True,
}

The `depends` list matters. If your module extends sales orders, it likely depends on `sale`. If it extends inventory behavior, it may depend on `stock`. Dependencies tell Odoo what needs to be installed first.

Models

Models are where business data and behavior live. A simple model might look like:

from odoo import fields, models

class WorkshopTask(models.Model):
    _name = "workshop.task"
    _description = "Workshop Task"

    name = fields.Char(required=True)
    notes = fields.Text()
    is_done = fields.Boolean(default=False)

This defines a new model called `workshop.task`. The fields describe the data stored on each record. Odoo uses this model definition to create database structure, forms, lists, access rules, and behavior around records.

Views

Views describe how records appear in the Odoo interface. A form view shows one record. A list view shows many records. Menus and actions let users open those views. Conceptually, XML view files answer:

  • Where does this feature appear?
  • What records does it show?
  • What fields are visible?
  • How is the form organized? The exact XML can be verbose, but the purpose is straightforward. You are telling Odoo how users should interact with your model.

Security

Security is not optional. If you create a new model, users need access rights before they can use it. The common file is: ```plain text security/ir.model.access.csv

This file can define permissions like read, write, create, and delete for a model and user group.
It is easy to forget this step when starting.
If the menu appears but users cannot open records, check access rules.
## Extending Existing Models
Many Odoo modules do not create brand new models.
They extend existing ones.
Example:
```python
from odoo import fields, models

class SaleOrder(models.Model):
    _inherit = "sale.order"

    internal_reference = fields.Char()

This adds a field to sales orders. Extending existing models is powerful because it lets your module fit into standard workflows. It also requires care because those workflows may connect to invoices, inventory, delivery, accounting, and reporting.

Common Mistakes

Mistake 1: Making one giant module

If a module handles sales, warehouse behavior, accounting reports, CRM changes, and external integrations, it becomes hard to reason about. Split modules around real business boundaries.

Mistake 2: Forgetting security

Access rules are part of the feature. A model without the right access rules will fail as soon as normal users try to use it.

Mistake 3: Overriding too much

Odoo gives you many ways to customize behavior. Use the smallest override that solves the problem. Large overrides are harder to upgrade and debug.

Where This Shows Up in Real Projects

Custom modules are useful when a business has real workflow requirements that standard Odoo cannot represent cleanly. Examples:

  • custom approval steps
  • extra sales order fields
  • special partner classifications
  • warehouse checklists
  • integrations with supplier systems
  • internal reports
  • validation rules for business data The best first module is small. Pick one business concept, add one clear behavior, and learn how models, views, security, and module installation fit together.

Key Takeaways

  • An Odoo module extends the Odoo platform.
  • The manifest declares metadata, dependencies, and loaded files.
  • Models define business data and behavior.
  • Views define how users interact with records.
  • Security rules are required for real users.

  • Keep first modules small and focused.

    Related Articles

  • What Is Odoo and When Should You Customize It?

  • ERP vs CRM vs Ecommerce Systems
  • API Integrations for Business Software

← Back to Blog Index