Creating Your First Odoo Model

The smallest useful model

from odoo import fields, models

class EquipmentCheck(models.Model):
    _name = "equipment.check"
    _description = "Equipment Check"
    _order = "check_date desc, id desc"

    name = fields.Char(string="Reference", required=True, copy=False, default="New")
    check_date = fields.Date(string="Checked on", default=fields.Date.context_today)
    equipment_id = fields.Many2one("maintenance.equipment", required=True, ondelete="cascade")
    notes = fields.Text()
    state = fields.Selection([
        ("draft", "Draft"),
        ("done", "Done"),
    ], default="draft", required=True)

Install that and Odoo creates an equipment_check table with the columns implied, plus create_uid, create_date, write_uid and write_date, which every model gets for free.

The underscore attributes that matter

_name is the model's identity. Dotted, singular, lowercase. It becomes the table name with underscores, so equipment.check becomes equipment_check.

_description is required in practice: Odoo logs a warning without it, and it is what appears wherever the model is listed for a human.

_order sets the default sort. It is SQL, so it must reference stored columns. Sorting on a non-stored computed field is a common and confusing failure.

_rec_name names the display field. It defaults to name, which is why a model without a name field shows records as bare identifiers in every dropdown until you set it.

_inherit is how you extend an existing model instead of creating one, which is covered separately in model inheritance.

Field types you will actually use

Char for short text, Text for long, Html for rich content. Integer, Float and Monetary, the last requiring a currency_id on the model. Boolean. Date and Datetime, where datetimes are stored in UTC and displayed in the user's timezone, which is a source of off-by-one-day bugs whenever someone forgets it. Selection for a fixed list. Binary for files.

The relational three are where the design happens:

• Many2one is a foreign key. Set ondelete deliberately: set null is the default, cascade deletes your record with the parent, restrict blocks the parent's deletion. Leaving it unset means accepting the default silently.
• One2many is the reverse of a Many2one and stores nothing itself. It needs the target model and the name of the Many2one field pointing back.
• Many2many creates a relation table, which Odoo names automatically unless you specify.

Access rights are not optional

This is the step that catches everybody. A new model has no access rights, so no user other than the superuser can read it.

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_equipment_check_user,equipment.check.user,model_equipment_check,base.group_user,1,1,1,0

The model_id:id value is model_ plus the model name with dots replaced by underscores. Odoo generates that external identifier for every model automatically.

Because administrators test as superuser, the missing line does not surface until an ordinary user tries the feature. Add the CSV line in the same commit as the model, and list it first in the manifest data.

Making it reachable

A model with no action and no menu exists but cannot be opened. Both are XML records:

    Equipment Checks
    equipment.check
    list,form

Note view_mode uses list, not tree. The view type was renamed in Odoo 17 and the old name no longer works in current versions.

The action must load before the menu that references it, which is a manifest ordering constraint rather than a file placement one.

Four reasons a new model appears to do nothing

In the order they actually occur:

• No access rights. Works as admin, invisible to everyone else.
• The Python is never imported. A model in a file missing from __init__.py produces no error at all, it simply does not exist.
• The XML is not in the manifest data list. Same silence.
• The module was installed, not upgraded. New models arrive on install, but changes to an already-installed module need an upgrade to take effect.

Work down that list before debugging the model itself. It is nearly always one of the four, and none of the four produce a traceback.

What comes next

Once the model exists, the interesting work is behaviour: computed fields for derived values, constraints for the rules that must always hold, and wizards for actions that need input before they run.