property_tags

Odoo properties let end users add their own fields to a record without a developer. One of the property types is tags, where the user defines a set of labeled, colored values and then picks from them.

The property_tags widget renders the picking half of that: the selected values as pills, plus an autocomplete to add another. The tag definitions themselves are read out of the field definition, record.fields[name].tags, rather than from a separate model. There is no tag table and no related records.

The descriptor is a single line. It names a component and nothing else: no displayName, no supportedTypes, no supportedOptions.

Properties are the escape valve for teams who need one more field on a project or a knowledge article and do not want a development cycle for it. Tag properties are the version of that for a small, controlled vocabulary.

The thing to set expectations about is who can change the vocabulary. Through this widget, nobody can. Users select from tags that already exist and remove their own selections, and that is the whole range of what they can do. Defining, renaming and recoloring tags happens in the property definition on the parent record, which is a different screen and often a different permission.

The widget is applied to a tag-type property value:

<field name="my_tags_property" widget="property_tags"/>

In practice you rarely write this, because the properties field renders tag properties through the same component automatically. Standard Odoo 19 never writes it at all.

The underlying PropertyTags component is capable of more than the field widget exposes. It can create tags, delete them from the definition, and open a color popover to recolor them. The field wrapper switches all of that off:

get propertyTagsProps() {
    return {
        selectedTags: this.props.record.data[this.props.name] || [],
        tags: this.props.record.fields[this.props.name].tags || [],
        deleteAction: "value",
        readonly: this.props.readonly,
        canChangeTags: false,
        onValueChange: (value) => { ... },
    };
}

canChangeTags: false is why clicking a pill does nothing instead of opening the color picker, and why typing a new name offers No result rather than Create. deleteAction: "value" is why the cross on a pill unselects the tag rather than deleting it from the vocabulary. Neither is configurable. There is no option to flip them, because the wrapper never looks at options.

The second hardcoded behavior is easier to miss and more likely to be reported as a bug. In the component:

get displayBadge() {
    return !this.env.config || this.env.config.viewType !== "kanban";
}

and then, when building the list:

if (!this.displayBadge) {
    // in kanban view e.g. to not show tag without color
    value = value.filter((tag) => tag[2]);
}

In a kanban view, a tag whose color index is 0 or unset is removed from the rendered list entirely. A user who tagged a card and cannot see the tag on the board has not hit a caching problem. The tag has no color. Give it one in the property definition and it reappears.

No change. Diffing the property_tags registration between the 19.0 and 20.0 branches shows no options added or removed and no registration changes.

Worth noting alongside it: Odoo 20 adds a separate property_selection widget and a named properties_definition registration, neither of which existed under those names in Odoo 19. The properties area is being built out, but this particular widget was left alone.