account_merge_wizard_lines_one2many

Charts of accounts accumulate duplicates: the same account created twice with slightly different codes, or two localization packages contributing overlapping entries. Odoo has a wizard that finds those candidates, groups them, and lets you choose which one survives the merge.

The interface problem is that the wizard shows two different kinds of row in one list. Some rows are group headings, telling you which duplicates belong together, and the rest are the individual accounts with a checkbox each. This widget is the renderer that keeps those apart.

It builds on Odoo's shared section list, the same machinery that renders sections on sale orders, and adapts it in three small ways: it uses a different field as the section title, it disables sorting, and it keeps one column visible on section rows that the base renderer would have hidden.

Merging accounts is irreversible in practice, because the entries move and the losing account is gone. So the wizard's whole job is to be readable enough that someone can make the right choice without opening each account. Grouping is what makes that possible: you compare within a group rather than across a list of two hundred rows.

The alignment detail is a good example of how much small layout decisions matter on a screen like this. If the group heading did not line up with the account names underneath it, the eye would have to work to associate them, and on a screen where the cost of a mistake is high, that friction turns into errors.

The practical advice for anyone about to use the wizard is to work group by group and save nothing until the whole list has been reviewed, because the choice within one group can change what you want to do in another when the same account appears twice.

The core usage

<field name="line_ids"
       widget="account_merge_wizard_lines_one2many">
  <list>
    <field name="is_selected"/>
    <field name="info"/>
    ...
  </list>
</field>

Both field names matter: one is the title column, the other is the column kept visible on section rows for alignment.

The section rows

<!-- rows carrying a display type render as sections -->
<field name="display_type" column_invisible="True"/>

Section detection comes from the shared section list, which uses the display type convention rather than a boolean flag.

What sorting does

# nothing. isSortable returns false for every column,
# with a source comment saying it makes no sense here

The list is grouped, so reordering it by a column would scatter the groups.

The renderer overrides three methods, and the most interesting is the one about a hidden column.

In the shared section list, a section row collapses: most columns are hidden so the title can stretch. Here that would hide the selection column too, and because that column sits before the title, hiding it would shift the group heading left relative to the account names below. The renderer therefore intercepts the cell class for that specific column on section rows and removes the hidden class, so the column keeps its width and everything lines up. The source carries a comment saying exactly that, which is rare enough to be worth quoting the intent of.

The second override decides which columns survive on a section row: only the title column and the selection column, with the title given a colspan covering everything else. That is a narrower set than the survey or eLearning equivalents, which keep the drag handle instead.

The third is a flat refusal to sort, again with a comment explaining that sorting a wizard list does not make sense. Because the rows are grouped by section, sorting by any column would interleave groups and destroy the grouping the whole screen depends on.

The one Odoo 20 change is a rename: the method that picks the section columns takes a longer name on the development branch, matching a rename in the shared base. It has no visible effect but will break a custom module that overrode the old name.

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

One rename, no behavior change. The method that selects which columns survive on a section row is renamed to match the shared section list's own rename. The title field, the deliberately visible selection column and the disabled sorting are all identical.