Daily updates from Odoo
Thursday, March 26, 2026
14 changes · 17.0
Resolved issues and error corrections
This change resolves an issue where tests were failing due to reliance on demo data that's no longer available in the testing environment. The fix automatically creates a new partner when needed, ensuring test stability and consistent results. This improves the reliability of our automated testing process.
Original PR description
4d844b7f3b570d7c3d978c6f10c351c48553df0b was a backport that was developed when demo data was installed during CI. However, time has passed, and demo isn't installed anymore causing the following:…
4d844b7f3b570d7c3d978c6f10c351c48553df0b was a backport that was developed when demo data was installed during CI.
However, time has passed, and demo isn't installed anymore causing the following:
```python
Traceback (most recent call last):
File "/data/build/enterprise/sale_amazon/tests/test_amazon.py", line 541, in test_sync_orders_replacement
"partner_id": self.env.ref("base.res_partner_1").id,
File "/data/build/odoo/odoo/api.py", line 596, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/data/build/odoo/odoo/addons/base/models/ir_model.py", line 2215, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/data/build/odoo/odoo/tools/cache.py", line 104, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/data/build/odoo/odoo/addons/base/models/ir_model.py", line 2208, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: base.res_partner_1
```
This commit creates a new partner on the fly instead.
runbot-241943This update clarifies the error message displayed when an upsell start date is set too close to the next invoice date. The change ensures users receive a more understandable explanation, preventing confusion and streamlining the subscription process. This improves the overall user experience and reduces potential support requests.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032
This update fixes an issue where users were incorrectly prompted for passwords on encrypted PDFs that didn't actually require them. The change now accurately checks if a password is needed before attempting a download, ensuring a smoother and more reliable experience for users accessing signed documents. This resolves a previous bug impacting document accessibility.
Original PR description
Related ticket: https://www.odoo.com/odoo/project/49/tasks/5400441 Previously, if a user went to download a document, we would check if it was encrypted. If so, we would redirect to ask for a password. But the problem with that is, not all encrypted documents require passwords. In that case, we would ask for a password when none existed, thus blocking the user from downloading the document. Now we check if a password is required to access the document instead of whether the document is encrypted. That way, we won't redirect to ask for a password when there is no password. Docs about PdfFileReader's `decrypt` method, before and after a major change: https://pypdf2.readthedocs.io/en/2.3.0/modules/PdfReader.html https://pypdf2.readthedocs.io/en/2.12.0/modules/PdfReader.html
This update resolves an issue where salespeople couldn't create sales orders for other users without administrator access, resulting in an access error. The fix allows salespeople to add other users as customers when creating sales orders, improving usability and workflow. This change was implemented by backporting a previous solution.
Original PR description
**Behaviour:** Creating an SO with another user as customer causes an access error when not logged as an admin. **Steps to reproduce:** - log in as Demo (or any non administrator account) - create a SO and add Mitchell Admin as the customer - when saving you should see an access error related to modifying res.users This is caused by a write on the SO's partner triggering an access check since the partner is related to another user: https://github.com/odoo/enterprise/blob/30d755ce704f5869c8bf7065c4f35b19b2ffec39/delivery_ups_rest/models/sale_order.py#L25-L27 https://github.com/odoo/odoo/blob/5ed7be8f3c2cf96c269b09dca5ae15481c6ac8bd/odoo/addons/base/models/res_partner.py#L769-L771 The solution is a backport of https://github.com/odoo/enterprise/pull/77999. opw-5962004
This update corrects an issue where the CSV data files for the l10n_pe and l10n_ec modules relied on country names (like 'Peru') instead of unique IDs. This caused upgrade errors when users renamed countries in the settings. The fix replaces country names with stable XML IDs ('base.pe', 'base.ec') to ensure reliable data import and module upgrades.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_pe` or `l10n_ec` module. - Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ", "Ecuador" → "ECUADOR"). - Upgrade the…
### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
"Ecuador" → "ECUADOR").
- Upgrade the module.
### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").
During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:
```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id | name | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE |
+-----+----------------------------------------------------------------------+------+
```
### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.
### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador
Using XMLIDs ensures consistent resolution regardless of name changes
or translations.
opw-6015302
upg-3950261
tbg-2492
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where invoices sent via Peppol were creating duplicate documents in the system. The change ensures attachments are synchronized only once during the dedicated document linking phase, streamlining the Peppol invoice process and improving data accuracy.
Original PR description
When sending an invoice via Peppol, the PDF and XML attachments are logged in the chatter. This automatically triggers a synchronization with the Documents app. However, the Peppol sending flow also includes a dedicated document linking step later in the process. This caused the same attachments to be registered as documents twice. This commit skips the document synchronization during the initial chatter logging step. The attachments will now only be synchronized once during the dedicated linking phase. Note: ec6e559 prevented duplicate attachments in the chatter with some cleanup code, but this cleanup code runs after the document has already been created and does not remove the document, resulting in duplicate documents, which this commit fixes. Task-6030468
This update fixes a problem where quotation emails were sending the document name in English, regardless of the recipient's language setting. The change now uses the translated document name from Odoo, ensuring recipients receive emails with the correct terminology in their preferred language. This improves the user experience for international customers.
Original PR description
The quotation email template built the document label from hardcoded English strings (quotation/order), so the text remain untranslated for recipients in another language. Use `sale.order.type_name` instead, which provides the document name in the proper language context. opw-6031392
This update automatically sets the correct analytic account when creating new items from the gross margin smart button within analytic accounts. Previously, new records didn't link to the appropriate account, leading to data inconsistencies. This change ensures accurate tracking and reporting for analytic data.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624
This update optimizes the testing process for the Live Chat module by pre-generating a key asset bundle. Previously, this bundle was rebuilt repeatedly during tests, causing performance slowdowns. This change significantly reduces test execution time and improves overall stability.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all").
This update optimizes testing by pre-generating the `bus.websocket_worker_assets` bundle. Previously, this bundle was rebuilt repeatedly during tests, causing performance slowdowns. This change significantly reduces test execution time and improves overall system stability.
Original PR description
This commit sets the `bus.websocket_worker_assets` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +900 times with a db "all").
This update resolves an issue where credit notes created through 'Reverse and create invoice' lost the original invoice's source information, leading to discrepancies in reports. The fix ensures that the source invoice is correctly linked and displayed on the credit note's PDF, improving traceability and report accuracy.
Original PR description
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source,…
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a potential issue where forum URL title requests could hang indefinitely, causing delays. A timeout has been implemented to prevent the system from being blocked, ensuring a smoother and more responsive forum experience for users. This improves overall forum stability and performance.
Original PR description
Add a timeout to the requests done by /forum/get_url_title to avoid blocking indefinitely Forward-Port-Of: odoo/odoo#254607
This update ensures that Odoo correctly maintains translation caches for related fields, even when calculations are re-run using different language versions of those fields. Previously, changes to translated fields could prematurely clear these caches, leading to performance issues. This fix improves the efficiency and responsiveness of Odoo when working with multi-language data.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug where modifying a recurring event's base time caused duplicate meeting notifications and data loss in Outlook. The fix ensures Microsoft IDs are preserved when an event is a follow-up, preventing these synchronization problems.
Original PR description
When an attendee syncs a recurring event where the first occurrence (base event) was modified by the organizer, `_write_from_microsoft` falsely triggers the destructive recreation path. This happens because `_has_base_event_time_fields_changed` compares the exception's modified time against the seriesMaster's pattern time, detecting a "change" even though the master hasn't changed. This causes: - All non-base events lose their microsoft_id and ms_universal_event_id - The base event gets recreated without Microsoft IDs - A duplicate event is pushed to Outlook on the next odoo2microsoft sync - Spurious "join the meeting now" notifications are sent to attendees Add a `follow_recurrence` guard so that when the base event is an exception (follow_recurrence=False), the non-destructive else branch is taken instead, preserving all Microsoft IDs.