Models, records and fields¶
Odoo's business layer is an object-relational model. Integrations call methods on models; methods read or change records; records expose named fields.
Models¶
A model is a typed business object identified by a technical name such as res.partner, sale.order, or account.move. The dot-separated name is the value used in API URLs.
The human label is descriptive but not stable enough for integration code. Use account.move, not "Journal Entry".
Model, field, and method notation
Link the model and name its member separately. For example, account.move is a model, partner_id is one of its fields, and action_post() is a business method. A combined expression such as account.move.action_post describes a method lookup; it is not another model.
Records¶
Each persistent record has an integer id unique within its model and database. An ID from res.partner has no meaning in sale.order unless a relation field connects them.
Do not move raw IDs between databases. Resolve records through stable business identifiers or external IDs when migrating or synchronizing environments.
Fields¶
Field metadata controls how values are represented and whether they can be written:
| Property | Meaning |
|---|---|
type |
Value shape, such as char, date, many2one, or monetary |
required |
A value is normally needed before a valid record can be saved |
readonly |
The field is computed, protected, or otherwise not directly writable |
stored |
The value is persisted and may usually be searched efficiently |
relation |
Technical name of the target model for relational fields |
help |
Runtime help text supplied by the owning module |
Required and readonly metadata is necessary but not sufficient to predict a successful write. Onchange behavior, constraints, company rules, state, and model overrides may impose additional requirements.
Persistent and transient models¶
Persistent models hold durable business data. Transient models support short-lived wizards and configuration flows; Odoo periodically removes their records. Treat transient models as workflow implementation details unless the integration explicitly drives that wizard.
Discover at runtime¶
Use fields_get when code needs to verify field availability:
{
"allfields": ["name", "email", "country_id"],
"attributes": ["string", "help", "type", "required", "readonly", "relation"]
}
The generated model reference is the human-oriented view of the same runtime metadata.