Skip to content

[18.0][OU-FIX] base: align extension view types with their parent#17

Open
eantones wants to merge 1 commit into
18.0from
18.0-fix-base-align_extension_view_types
Open

[18.0][OU-FIX] base: align extension view types with their parent#17
eantones wants to merge 1 commit into
18.0from
18.0-fix-base-align_extension_view_types

Conversation

@eantones

Copy link
Copy Markdown
Member

Old databases carry extension views (mode='extension') whose stored type doesn't match their parent view's: older Odoo versions stored a wrong derivation (e.g. the form default on a list-view extension, or tree on a search-view extension) and never validated it. Odoo 18 validates the resolved arch root against type on every module update, so each of these rows becomes a hard ParseError the first time its owning module is updated after the migration:

odoo.tools.convert.ParseError: while parsing .../base_iso3166/views/country_view.xml
The root node of a form view must be <form>, not <list>

The invariant an extension view must satisfy is simply "same type as its parent" — this adds _align_extension_view_types() to the base 18.0.1.3 pre-migration, right after the existing tree→list rename so the alignment lands on the renamed values.

Found on a live 14→18 migration: two such rows (a list-view extension typed form written in 2024, a search-view extension typed tree written in 2026), both produced by normal module updates on the source database years before the migration, harmless on every version before 18.

Old databases carry extension views (mode='extension') whose stored
``type`` doesn't match their parent view's: older Odoo versions stored a
wrong derivation (e.g. the 'form' default on a list-view extension, or
'tree' on a search-view extension) and never validated it. Odoo 18
validates the resolved arch root against ``type`` on every module
update, so each of these rows becomes a hard ParseError the first time
its module is updated after the migration ("The root node of a form
view must be <form>, not <list>").

Align them with the parent's type — the invariant an extension view
must satisfy — right after the tree->list rename, so the alignment
lands on the renamed values.

Found on a live 14->18 migration: two such rows (a list-view extension
typed 'form' since 2024, a search-view extension typed 'tree'), both
written by normal module updates on the source database years before
the migration.
@eantones eantones added the oca-candidate Contains commits of ours that will be proposed to OCA at submit time. label Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

oca-candidate Contains commits of ours that will be proposed to OCA at submit time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant