[booking_engine] -u all fails: view validation can't see manual related field x_resource_id on rental.order.wizard.line

[cliffkujala]

Module

• Module: booking_engine version 1.15
• Repo: odoo/industry, branch 19.0 (reproduced at commit 2841d7040)
• Odoo: 19.0 Enterprise (version_info = (19, 0, 0, FINAL, 0))

Summary

booking_engine is a data-only module: all of its custom fields are manual ir.model.fields records loaded from data/ir_model_fields.xml (80 manual fields, 13 of them related, 24 compute). Several are related-of-related chains.

Installing the module works fine, and a targeted upgrade (-u booking_engine) works fine. But a global upgrade (-u all) crashes during the module's own view validation, because the manual related-field chain is not reflected into the in-memory registry before data/ir_ui_view.xml is validated in the same load pass.

The whole registry build is rolled back, so -u all cannot complete on any database that has booking_engine installed.

Steps to reproduce

1. Install booking_engine (e.g. via the Campsite industry pack) on an Enterprise 19.0 database.
2. Run a global update:

   odoo-bin -c <conf> -d <db> -u all --stop-after-init
   

3. Registry load fails.

Actual result

odoo.tools.convert.ParseError: while parsing .../booking_engine/data/ir_ui_view.xml:31
Error while validating view near:
<form __validate__="1">
  <sheet>
    ...
Field "x_resource_id" does not exist in model "rental.order.wizard.line"

View error context:
{'file': '.../booking_engine/data/ir_ui_view.xml',
 'line': 3,
 'name': 'rental.order.wizard.form.booking_engine',
 'view.model': 'rental.order.wizard',
 'xmlid': 'rental_order_view_inherit'}

No "field cannot be set up / ignored" warning is emitted beforehand — the field is simply not present in the registry at validation time.

Expected result

-u all completes, exactly as -u booking_engine does.

Root cause analysis

The failing view references a manual related field:

data/ir_ui_view.xml (record rental_order_view_inherit, model rental.order.wizard):

<xpath expr="//list//field[@name='product_id']" position="after">
  <field name="x_resource_id" readonly="1"/>
</xpath>

The field is a manual related chain defined in data/ir_model_fields.xml:

<!-- rental.order.wizard.line.x_resource_id -->
<record id="rental_order_wizard_x_resource_id" model="ir.model.fields">
  <field name="ttype">many2one</field>
  <field name="model_id" ref="sale_renting.model_rental_order_wizard_line"/>
  <field name="name">x_resource_id</field>
  <field name="relation">resource.resource</field>
  <field name="related">order_line_id.x_resource_id</field>
</record>

<!-- sale.order.line.x_resource_id -->
<record id="model_sale_order_line_x_resource_id" model="ir.model.fields">
  <field name="ttype">many2one</field>
  <field name="related">planning_slot_ids.resource_id</field>
  <field name="model_id" ref="sale.model_sale_order_line"/>
  <field name="name">x_resource_id</field>
  <field name="relation">resource.resource</field>
  <field name="store" eval="False"/>
</record>

So the chain is:
rental.order.wizard.line.x_resource_id → order_line_id.x_resource_id
→ sale.order.line.x_resource_id → planning_slot_ids.resource_id
(the last link is the core sale_planning field, which is stable).

During a targeted upgrade these manual fields are already resident in the registry from server startup, so the view validates. During -u all, booking_engine's data/ir_ui_view.xml is validated in the same load pass that re-reflects the 80 manual fields, and the manual related-of-related chain is not yet attached to rental.order.wizard.line when the view is validated — hence the ParseError.

x_resource_id is just the first field to trip this; other related/computed manual fields in the same module are exposed to the same ordering hazard.

Suggested fixes (any one)

• Ship the x_ fields that are referenced in views (at least x_resource_id on sale.order.line and rental.order.wizard.line) as Python fields in a small models/ layer, so they are instantiated during registry.load() before any view validation; or
• Guarantee manual ir.model.fields are reflected into the registry before the module's own views are validated during a global upgrade.

Workaround

Avoid -u all on databases with booking_engine installed; upgrade modules in a targeted manner (-u booking_engine / -u <changed_modules>) instead.

[cliffkujala]

Anyone else facing this?

[cliffkujala]

Still reproducible a month later, now on booking_engine 1.16 (branch 19.0 at 6aa50d82d, 2026-07-04). Same crash, same field, during a routine -u all on an Enterprise 19.0 database:

odoo.tools.convert.ParseError: while parsing .../booking_engine/data/ir_ui_view.xml:31
Field "x_resource_id" does not exist in model "rental.order.wizard.line"

One additional finding since the original report, which explains why the log gives no hint about the real cause: the field is not merely "not yet reflected" — it is added to the registry and then silently dropped. _setup_fields() in odoo/orm/model_classes.py catches any exception raised while setting up a manual field and pops the field from the model without logging anything:

for name, field in model_cls._fields.items():
    try:
        field.setup(model)
    except Exception:
        if field.base_field.manual:
            # Something goes wrong when setup a manual field.
            bad_fields.append(name)
            continue
        raise

for name in bad_fields:
    pop_field(model_cls, name)

During the -u all pass, setting up the manual related-of-related chain (rental.order.wizard.line.x_resource_id → order_line_id.x_resource_id → planning_slot_ids.resource_id) raises at some point, the field is popped with no log line, and the first visible symptom is the unrelated-looking view validation error that rolls back the whole registry build. Even a _logger.warning in that except branch would make this diagnosable from the log — that part is arguably an odoo/odoo issue rather than an industry one, but the module-level fix suggested above (ship the view-referenced x_ fields as Python fields) would resolve this report either way.

Impact remains: no database with booking_engine installed can complete a global update. We have had to add guards to our update tooling that refuse -u all whenever booking_engine is installed. I am also opening an Odoo Enterprise support ticket referencing this issue, since the module is OEEL-1.

Happy to provide a full -u all log or test a patch.

[cliffkujala]

Odoo support confirmed they do not support installing Industries from the config files addons path(s). They only expect users to import the Industry modules as ZIP files from the GUI.

Which means they will always be skipped on a command line module update run.