password

The password widget swaps a normal text input for a masked one and adds a button that toggles between masked and revealed. The button title changes with the state, reading Reveal value when hidden and Hide value when shown.

It supports char and text fields. Internally it uses the standard useInputField hook, so it saves and validates exactly like a plain char field. The only difference is what the user sees.

The descriptor declares no supportedOptions. Its extractProps is a single line that forwards the placeholder it was given, and nothing else.

Use this when someone will read the screen over a colleague's shoulder: an API key on an integration form, a shared account credential, a license key. It stops the casual glance.

It does not stop anything else, and this is the part worth being clear about with your team. Anyone who can open that form can click the reveal button. Anyone who can open the browser developer tools can read the value without clicking anything. If the value genuinely must not be readable by a user who can see the record, masking is the wrong tool and the field needs an access rule or server-side encryption instead.

Basic masking:

<field name="api_key" widget="password"/>

With a placeholder. Note that placeholder is an attribute, not an option:

<field name="api_key" widget="password" placeholder="Paste the provider key"/>

This does not work, and is the most common mistake on this widget:

<!-- wrong: placeholder is not an option, this is silently ignored -->
<field name="api_key" widget="password" options="{'placeholder': 'Paste the key'}"/>

Masking happens in the browser, after the value has arrived there. The component's own getter makes this plain:

get displayedValue() {
    return this.props.record.data[this.props.name] || "";
}

The value is read straight out of the loaded record. For it to be there, the server already sent it in the read response. That means three things in practice.

1. Any user who can open the form can click the reveal button and read the value. There is no permission check on the toggle.
2. The value is visible in the browser network tab and in the page's JavaScript state whether or not the user ever clicks reveal.
3. Exports, the developer mode record viewer and the ORM all return the plain value. The widget only affects one input on one form.

If a value must be hidden from users who can otherwise see the record, that has to be enforced on the server: a restricted field with a groups attribute, a separate model behind an access rule, or a value your code writes but never reads back. Odoo's own res.users password is handled that way, not with this widget.

The widget is identical in Odoo 20. We diffed the registration and found no options added or removed and no change to supported types.

The interesting change is adoption. In Odoo 19 the widget appears zero times in standard views. In Odoo 20 it appears twice, both on user-facing security screens: res_users_views.xml and res_users_identitycheck_views.xml. So a widget that existed unused in 19 becomes part of the standard user forms in 20.