password_meter

On startup the component asks the server for the live password policy and builds its scoring rules from the answer:

onWillStart(async () => {
    const policy = await orm.call("res.users", "get_password_policy");
    this.state.required = new ConcretePolicy(policy);
});

It then renders a Meter component under the input that rates what the user types against that policy, alongside the module's standard recommendations.

Note the naming trap. The exported descriptor is called passwordField and its displayName is Password, identical to the unrelated password widget in the web module. Only the registration key tells them apart.

This is for the one screen where a user sets their own password. It closes the gap between a policy that exists in configuration and a user who has no idea what it demands until the save is rejected.

The value is that the bar is honest: it is scored against your server's actual policy rather than a generic rule of thumb, so a green bar means the save will go through.

What it does not do is hide anything. If someone might be reading over the user's shoulder, that is a different widget, and the two do not combine on the same field.

On a password field the user sets themselves:

<field name="new_password" widget="password_meter"/>

Do not expect this to mask. If you want masking instead, that is a different widget:

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

Odoo ships two widgets whose displayName is Password, in different modules, doing opposite things.

password, in web, masks the input and adds a reveal button. It never scores anything.

password_meter, in auth_password_policy, shows the value in the clear and scores it against the server policy. It never masks.

Anything that lists widgets by display name, including Studio-style pickers and options helpers, will show two entries reading Password with no way to tell them apart. Check the registration key, not the label.

There is a practical consequence too: you cannot have both behaviors on one field. A field is rendered by exactly one widget, so a password input that is both masked and scored needs a custom widget that combines them.

One more detail worth knowing before you put this on a screen. The policy call happens in onWillStart, so it runs once when the field is first rendered. If an administrator changes the password policy while a user has the form open, the meter keeps scoring against the old policy until the view is reloaded.

No change. Diffing the password_meter registration between the 19.0 and 20.0 branches shows the same component, the same supported type and still no options.

Its namesake in web, the password widget, is also unchanged in Odoo 20, though Odoo 20 does start using that one on two res.users views where Odoo 19 used it nowhere.