OdooField
VI

OdooField / Notes / Article

Stop guessing fields: read live Odoo 18 metadata

A practical fields_get, ir.model, and ir.model.fields workflow for confirming models, fields, and effective access before an integration reads or writes data.

23/07/2026 Odoo 18.0 3 sources Notes

Problem

An integration often fails before its first create or write: the client assumes the target database has the same models and fields as an example or a remembered schema. The actual registry also reflects installed apps, custom modules, Studio changes, and the integration user’s access.

Official documentation describes the API. The database’s own metadata describes the surface the integration can actually see.

Evidence in Odoo 18

Odoo 18 exposes fields_get() for field metadata and the ir.model and ir.model.fields meta-models for inspecting models and fields in the system. [N1]

ir.model.fields carries technical names, labels, types, relations, base or manual state, and properties such as required and readonly. Those are inputs to payload validation, not details to guess. [N2]

Field-level access changes the result. A field restricted by groups is removed from fields_get(), and explicit reads or writes can fail. Inventory with the same service identity that will run the integration, not an administrator used only for a convenient test. [N3]

Minimum workflow before a write

  1. Pin the host, database, and Odoo 18.0 in the integration configuration.
  2. Authenticate as the service user with the intended production permissions.
  3. Call fields_get() on the target model and request only useful attributes such as string, type, required, readonly, and relation.
  4. Reject the payload when a model or field is absent; never substitute a similar-looking name.
  5. Test record rules and representative data separately on staging before production.

A shortened XML-RPC example:

fields = models.execute_kw(
    db, uid, api_key,
    "res.partner", "fields_get", [],
    {"attributes": ["string", "type", "required", "readonly", "relation"]},
)

Treat the result as an expiring snapshot. Re-inventory after installing apps, upgrading modules, or changing the service user’s groups.

Limit

Metadata confirms structure and the visible access surface; it does not prove business semantics. It does not replace checks for computed fields, constraints, side effects, record rules, or custom-module flows. High-risk writes still need representative staging tests before production is enabled.