activity_model_selector

Most activities are scheduled from the record they concern, so the link is implicit. Scheduling from the activity wizard is different: nothing says what the activity is about, and the answer could be any record in the database.

This widget asks that in two steps. First a model, chosen from a list the server says the user is allowed to link to. Then a record, chosen through a full search dialog opened on that model. Only when both are answered does the wizard get its link.

The reason it is a widget rather than two fields is what happens in between. Changing the model changes which activity types are available, which recomputes several fields on the wizard, including the summary the user has quite likely already typed. The widget carries that text across the change.

Losing typed text is the fastest way to make a wizard feel broken, and this one is unusually exposed to it because the natural order of filling it in, summary first and link second, is exactly the order that triggers the loss. The source comment says so outright, which is a good sign that it was found the hard way.

The two-step shape is also worth recognizing as a pattern. Any time a record reference can point anywhere, the interface has to narrow the model before the record, and doing it in local state rather than on the record means a half-finished choice never gets saved. If you build something similar, that separation is the part to copy.

The core usage

<field name="res_model"
       widget="activity_model_selector"
       string="Link to"/>

One field element covers both steps. The record ids are written by the widget rather than by a second field.

The companion fields it touches

res_model        # written when a record is chosen
res_model_name   # read for the initial label
res_ids          # written with the chosen record
summary, note    # saved and restored across the change

All read by literal name, so the wizard model has to carry them.

Where the model list comes from

# server method, called once per session
mail.activity.schedule.get_model_options()

The result is memoized, so opening the wizard repeatedly does not re-query.

The preservation trick is the part worth reading closely. When a record is chosen, the widget first copies the current summary and notes into a local object. It then updates the model and the record ids without saving, which is what triggers the recomputation of activity types and everything downstream of them. Finally it writes the saved summary and notes back, overwriting whatever the recompute produced.

The same dance happens on reset. Clearing the link recomputes the same fields, so the same save and restore is applied, and then the model selection is cleared through the normal path.

The model list is fetched through a memoized helper, with a comment noting a small hack: the memoization keys on the first argument, so a placeholder is passed first and the actual service second. The practical effect is one server call per session rather than one per wizard.

Local state is used deliberately for the chosen model, with its own comment: writing a model to the record without a record id would leave the wizard in a state the server cannot interpret. So the model lives in the component until a record is picked, and the dialog's close handler resets everything if nothing was chosen.

One consequence of that design is worth knowing: the record label shown after choosing comes from a separate name lookup the widget performs itself, not from the record, so a renamed target will show its old name until the wizard is reopened.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

No behavior change. The two-step flow, the memoized model list, the local state and the summary preservation are all identical. The props and state helpers move to the new syntax, which affects patches rather than views.