properties

Most custom-field requests are not really development requests. A project manager wants a "Review deadline" date on tasks of one project; the fleet manager wants "Winter tires" on vehicles of one model. Studio would add that field to every task in the database. The Properties field adds it only where it belongs: definitions attach to a parent record, and all children of that parent grow the same set of extra fields, stored as JSON in a single column.

The widget renders those properties as if they were real fields, grouped under separators, split into up to two columns, drag-sortable in edit mode, with a definition popover for label, type, default value and per-type settings. Odoo 19 offers 14 property types, from text and checkbox through dates, selection and tags up to relational many2one and many2many, plus monetary with a currency, HTML and multiline text, the last three being 19 additions.

Properties are the pressure valve that keeps a deployment maintainable. Every field a department adds through Studio is global schema the whole company carries forever; every property is scoped to the parent that needed it and disappears with it. Our rule on implementations: schema fields for what the company shares, properties for what a team owns. Task metadata per project, vehicle details per model, candidate criteria per job position, all properties.

The governance story is what makes this safe to hand to users. Because definition editing requires write access on the parent record, the project manager can reshape task properties for their own project and nobody else's, with no new security groups to invent. And because properties are searchable, groupable and displayable on kanban cards, the data teams put in them stays reportable instead of dying in a notes field.

The one discipline to enforce: deleting a property definition deletes that data for every child record, and renaming is safe but retyping is not. Treat definition editing as a small-blast-radius admin action, not a daily habit.

No Studio license is needed; defining properties is the built-in no-code path.

1. Open a record whose model has properties, for example a task, and make sure it belongs to a parent (a project): properties cannot exist without one.

2. Click the cog menu of the form and choose Add Properties.

3. In the definition popover, set the Label and pick the Field Type from the 14 available, then fill the type-specific settings: default value, selection options, related model for relational types, currency for monetary.

4. Tick Display in Cards to surface the property on kanban and list contexts, and drag properties to reorder or group them under separators.

The natural limits are the flip side of the scoping. Properties exist only on models whose Python declares a fields.Properties with its definition_record; you cannot add a Properties container itself without a developer (or Studio, which can add one). They cannot be made required, they carry no compute or onchange logic, and record rules cannot key on them.

The access model is also fixed: definition editing follows write access on the parent record, full stop. If "who may define task properties" should differ from "who may edit the project", that needs custom access design on the parent, which is developer work.

Two-column layout, as the fleet form uses

<field name="vehicle_properties" columns="2"/>

No widget attribute needed: fields.Properties resolves to this widget automatically.

The Python side that makes properties possible

task_properties = fields.Properties(
    string="Properties",
    definition="project_id.task_properties_definition",
)

The definition path names the parent field and the PropertiesDefinition field on the parent model. That pair is the entire wiring: the widget discovers the parent through it and checks definition-edit rights against that record.

Opening a wizard field in definition mode

<field name="template_properties" editMode="True"/>

Useful on configuration wizards where the whole point is editing the definition, so users land directly in edit state instead of finding the cog menu.

The source answers the questions admins actually ask about properties.

Who can edit definitions, precisely? The widget calls the access-rights check for write on the definition record, the concrete parent, not the parent model. No parent set means no definition editing at all, which is why properties on an unassigned record show values but refuse the edit pencil. The result is cached in component state and re-checked when the parent field changes.

How does the cog menu reach the field? The form controller broadcasts a PROPERTY_FIELD:EDIT event on the model bus; the widget listens only on form views, runs the access check, warns politely on failure, and if the field has no properties yet, immediately opens creation of the first one.

Why do kanban and calendar never offer definition editing? The variant registrations, kanban.properties (also registered for hierarchy views) and calendar.properties, override the access check to a hard false. Definition editing is a form-view activity by design.

Ordering and grouping are implemented with the sortable machinery over separator groups, and the two-column split distributes groups, not individual properties, unless there is only one group, which is then split across the columns to use the width.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below compare the shipped 19.0 sources against the public development branch, which is unstable until feature freeze; we re-verify after release.

The field's core is remarkably stable: the property engine's changes are internal API migrations, with columns and editMode still the only attributes. Two structural moves are visible around it. The kanban registration follows the great rename and becomes card.properties, with hierarchy.properties kept, so view inheritance targeting kanban.properties needs review. And a new sibling widget appears, properties_definition, giving definition editing its own dedicated field UI on parent models rather than piggybacking on the child's widget.