portal_wizard_user_one2many

When you select contacts and choose Grant portal access, Odoo opens a wizard listing those contacts with a status icon and an action button on each row. Every button on that list triggers a server method that creates a user, sends an invitation, or revokes access. Those methods take a moment, and the buttons stay clickable while they run.

That is the problem this widget exists for. It is a one2many widget that changes exactly one thing about the embedded list: the controller behind it. The replacement controller keeps a flag while a button's action is in flight and refuses any further button click until it finishes.

It also blocks one button name unconditionally. The three little icons in the email column, the green check, the red cross and the crossed-out user, are declared in the view as buttons calling action_refresh_modal. The controller returns false for that name every time, so the call is never made. They exist to be visible, not to be pressed.

The failure this prevents is embarrassing rather than catastrophic: a customer receives two identical portal invitations, or an access grant runs twice and the admin cannot tell whether it worked. On a wizard where each row is a real person receiving a real email, that is worth twenty lines of code.

There is a wider lesson in it for custom work. Any wizard where a row-level button sends mail, calls an external service or creates users has the same exposure, and Odoo's default list controller does nothing about it. If your implementation has grown that kind of screen, this widget is the pattern to copy: a small controller subclass, one boolean, and buttons that stop being able to double-fire.

The status icons are worth explaining to admins too. Users assume a red cross next to an email is a button that will fix something. It is a diagnosis: the address is invalid, or already belongs to another user. The fix is to edit the email inline, which revalidates the row.

The core wizard, trimmed

<field name="user_ids" widget="portal_wizard_user_one2many">
  <list editable="bottom" create="false" delete="false">
    <field name="partner_id" force_save="1"/>
    <field name="email" readonly="is_internal"/>
    <button name="action_grant_access" type="object"
            string="Grant Access"/>
  </list>
</field>

create="false" and delete="false" matter: the rows come from the selected contacts, not from the user.

Status icons as declared in core

<button name="action_refresh_modal" type="object"
        icon="fa-check text-success"
        invisible="email_state != 'ok'"
        title="Valid Email Address"/>

Declared as a button, blocked by the controller. Three of these cover the ok, invalid and already-taken states.

Reusing the pattern on your own wizard

<field name="line_ids" widget="portal_wizard_user_one2many">
  <list editable="bottom">
    <field name="email"/>
    <button name="action_send" type="object" string="Send"/>
  </list>
</field>

Legal and it works, since nothing in the widget is portal-specific. Just remember the action_refresh_modal name stays blocked wherever you use it.

The whole widget is a component subclass swapping one entry in X2ManyField.components: Controller becomes PortalWizardUserListController. That controller overrides two hooks of the standard list controller.

beforeExecuteActionButton runs before any row button executes. It returns false if the button is named action_refresh_modal or if a portal action is already running, otherwise it sets the in-flight flag and calls the base implementation. afterExecuteActionButton clears the flag and, unlike the base version, does not chain to super.

Returning false there is not a soft signal. In Odoo's view-button hook, a falsy result from the before-hook aborts the click completely, before the action is dispatched. That is what makes the status icons inert, and it has a side effect worth knowing: the base beforeExecuteActionButton is what saves the row you are currently editing, so clicking a status icon skips that save too.

One rough edge is visible in the ordering. The flag is set to true before the base implementation is awaited, and the base implementation saves the edited row. If that save is rejected, for example because a required field is empty, the promise rejects and the after-hook never runs, so the flag stays set and every button in the dialog goes quiet. Closing and reopening the wizard clears it. Everything else, including a server error inside the action itself, is handled correctly, because the view-button hook calls the after-hook even when the action throws.

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

Nothing changes. Both the widget file and the controller file are byte-identical between Odoo 19.0 and the development branch, which is rare in a release cycle that rewrote most field widgets onto the new Owl props syntax. Views using it need no attention during an Odoo 20 upgrade.