many2one_avatar_leader_user

When you assign a salesperson in a context that already knows the sales team, the fair question is: which of these users actually leads that team? many2one_avatar_leader_user answers it inside the dropdown. It is a small CRM-module subclass of many2one_avatar_user, so you get the familiar avatar chip and user search, plus one addition: the entry belonging to the selected team's leader carries a (Team Leader) tag.

The mechanism, read from the 19.0 source, is a context handshake. The widget takes a teamField attribute naming the team many2one on the same record, reads that team's id, and injects it as crm_formatted_display_name_team into the dropdown's search context. Server side, res.users checks the context, looks up the team's user_id, and appends the marker to that one user's display name using Odoo 19's formatted display name convention, which the dropdown renders as a muted suffix.

Core wires it up where lead routing is configured: the team member settings in CRM and the lead generation rules of event_crm, always next to a team field like lead_sales_team_id.

Lead routing screens are where a wrong click quietly reshapes a sales org: assign event leads to the wrong person and a team leader spends the quarter wondering where their pipeline went. The widget's job is context at the moment of choice. Whoever configures the rule sees, without leaving the dropdown, which candidate is the leader of the team the rule feeds, and can deliberately pick the leader for oversight or a member for workload.

It also encodes a data dependency worth respecting in customizations: the marker follows the team currently selected on the record. Change the team, reopen the user dropdown, and the tag moves to the new team's leader. That live link between two fields on the same form is exactly what generic user pickers cannot express, and replicating it by hand, with domains and onchanges, is clumsier than reusing this widget next to your own team field.

If your org chart concept is departments rather than sales teams, this widget does not transfer, the server hook is CRM-specific, but the pattern, a ten-line widget passing one context key to a display name override, is a template our team reuses for approver and manager pickers.

The core pattern, from event lead rules

<field name="lead_sales_team_id"/>
<field name="lead_user_id" widget="many2one_avatar_leader_user"
       teamField="lead_sales_team_id"/>

With inherited avatar-user options

<field name="user_id" widget="many2one_avatar_leader_user"
       teamField="team_id"
       options="{'no_open': True, 'no_create': True}"/>

Both options come from the inherited many2one behavior; the leader tag needs no configuration beyond teamField.

The server half is three lines in crm/models/res_users.py and repays reading. The display name override fires only when two context keys are present: crm_formatted_display_name_team, injected by this widget, and formatted_display_name, which Odoo's autocomplete sets when it wants rich name formatting. It then browses the team, takes its user_id, and appends the marker to exactly that user, wrapped in the --...-- convention that the dropdown renders as muted text.

Three consequences follow. First, the tag appears in dropdown listings but never in the stored value, exports or the readonly chip, because those render without the formatting context. Second, only one user per team can carry the tag, the team's user_id; co-leadership setups will show a single leader. Third, the lookup runs per dropdown search, so the tag always reflects the current team on the record, not the team at form load.

On the client side, the notable line is the unguarded read: record.data[teamField].id. With an empty team the widget has nothing to inject and the expression errors instead of skipping, which is why every core usage sits next to a team field that always has a value. Treat that as a placement rule when you reuse the widget.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below are read from the public development branch, which can still change before release; we re-verify against the shipped version.

No functional changes are visible on master. The diff is the framework-wide props migration: useProps with the shared avatar-user props and t.string() for teamField, replacing the static declarations. Registration name, context key and server override are untouched.

Inherited changes are the ones to watch: the base avatar user widget is picking up the master-branch avatar cache-busting and card changes tracked on its own page, and whatever lands there flows through this descriptor automatically. Plan the review together during an Odoo 20 upgrade.