Thursday, January 15, 2026
2 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where preparation timers for courses within a restaurant order were incorrectly shared. Now, each course has its own dedicated preparation timer, ensuring accurate timing and a better customer experience. This improves the reliability of order preparation workflows.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update resolves a problem that caused Odoo to fail during database upgrades due to tracking computations triggered by a new tax module loading process. The fix disables tracking during the `_load` method execution, preventing errors and ensuring smooth module loading. This improves stability and prevents upgrade failures.
Original PR description
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py…
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.
```py
/home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```
Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.
```py
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
tracking = records.with_context(context)._message_track(fnames, initial_values)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
record._message_log(
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```
This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae
The resulting tracking computation crashes with a KeyError when processing repartition line diffs.
Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.
opw-5467986
upg-3753990
tbg-2380