Daily updates from Odoo
Thursday, December 4, 2025
9 changes · 17.0
Resolved issues and error corrections
This update corrects a display issue in the general ledger report where journal items were incorrectly linked to the wrong account groups. The fix ensures that journal items are accurately associated with the corresponding account group, improving report accuracy and data reliability. This resolves a user-reported problem.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867
This update fixes an issue where unnecessary slashes were appearing in Odoo reports due to empty comment fields. The change ensures reports are formatted correctly, removing the extraneous slashes and improving data accuracy. This resolves a minor formatting problem that could potentially cause confusion or errors in report generation.
Original PR description
Since 17.0, we added a / when there was no comment in the comment section of the xml. This is wrong and should be left empty. opw-5242381
This update introduces a command-line option to prevent Odoo from automatically installing modules during upgrades. This addresses a complex issue where outdated databases can cause upgrade failures and business logic problems. The new feature provides greater control over the upgrade process.
Original PR description
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the…
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the addition. It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules. This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested. This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules. It is open to discussion to change this to a config option, with or without a module list **Initial solution (alternative to avoid a config)** --dev skipautoinstall **Current solutions** (command line param) --skip-auto-install **Maybe in the future but unlikely** (more flexible) --skip-auto-install=all --skip-auto-install=web_enterprise,iap (krma suggestions) --skip-auto-install=* --skip-auto-install=web_*,iap Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places) Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust.
This update fixes an issue where a virtual keyboard would unexpectedly appear when selecting dates or times on mobile devices. The change now hides the keyboard and cursor on small screens, resulting in a smoother and more user-friendly experience for mobile users. This improves usability and reduces frustration.
Original PR description
Steps to reproduce: In a module, add a field with tracking=True on any model Change this field on any record, to force the creation of a tracking value Remove the field from the code Update the…
Steps to reproduce:
In a module, add a field with tracking=True on any model
Change this field on any record, to force the creation of a tracking value
Remove the field from the code
Update the module
Result:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2558, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/custom/odoo/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2487, in _process_end_unlink_record
record.unlink()
File "/home/odoo/custom/odoo/addons/mail/models/ir_model_fields.py", line 52, in unlink
'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
File "/home/odoo/custom/odoo/addons/mail/models/models.py", line 181, in _mail_track_get_field_sequence
self._fields[fname], 'tracking',
KeyError: 'field_name'
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a potential issue where printing failed on Windows systems. By adding a catch-all error handler around the printing process, the system is now more robust and reliable when generating print jobs. This ensures consistent printing functionality for users.
Original PR description
This commit adds the try/except block around print_raw method of the virtual iot box to allow catching exceptions when printing on Windows
This update increases the time allowed for sending log data from the IoT box to the database, resolving previous issues that caused frequent errors. The change extends the timeout to 10 seconds and adjusts the log sending frequency to 12 seconds, ensuring more reliable data transmission and reducing disruptions.
Original PR description
Currently the request to send logs to the db from the iot box is at 0.5s timeout. This leads to many exceptions and failed requests. This commit sets the timeout for such requests to 10s (previously 0 5s) and the frequency of sending logs to every 12s (previously 0.5s)
In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an Access Error when trying to open an invoice. Among the Accounting groups, only *Accounting / Read-only* does not inherit from *Accounting / Invoicing*, which means that only the users in *Accounting / Read-only* could not access the invoices. By granting read rights to both *Accounting / Invoici
Original PR description
In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an…
In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an Access Error when trying to open an invoice. Among the Accounting groups, only *Accounting / Read-only* does not inherit from *Accounting / Invoicing*, which means that only the users in *Accounting / Read-only* could not access the invoices. By granting read rights to both *Accounting / Invoicing* and *Accounting / Read-only*, we ensure that any user belonging to an Accounting group can see the invoices from the Veri\*factu module. ### Steps to reproduce: 1. Install *Accounting* (`accountant`) and *Spain - Veri\*Factu* (`l10n_es_edi_verifactu`). 2. Go to Settings > Users & Companies > Users and select a user. 3. In the *Access Rights* tab, set the user's *Accounting* access right to *"Read-only"*. 4. Log out, then log back in as the user selected in step 2. 5. Go to Accounting > Customers > Invoices and select any invoice. 6. An access error pops up. opw-5343391
This update addresses a technical issue where form changes were causing confusing error messages. The fix adds a fallback to capture more information about these errors, providing better insight for developers. This improves the stability and reliability of Odoo forms.
Original PR description
Related to https://runbot.odoo.com/odoo/error/234669: somewhere somehow an onchange warning is malformed (it's not a mapping) and the Form is unable to cope with it, leading to a rather unhelpful error. TBH I don't understand how it can happen as `onchange` has a rewriting layer between the `warning` out of onchange methods and the one it sends to the client. And most of the `onchange` overrides are preprocessing not post. And the two overrides which do postprocess modify `values` in place. Add a fallback to attempt to get more insight into this error.
This update resolves a bug where the aged receivable report wasn't displaying invoices correctly when the invoice due date was removed. The fix ensures consistent data retrieval by aligning the report's query with the invoice data, preventing inaccurate report results. This improves the reliability of financial reporting.
Original PR description
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this…
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this entry <img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" /> Observation: - on clicking the entry, when redirected to list view, there are `0` records. Issue: - The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)` https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226 - while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view - This creates inconsistencies between two. https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394 opw-5237298