Daily updates from Odoo
Navigate
Branch
Sunday, October 5, 2025
17 changes
4 changes
Resolved issues and error corrections
Fixed an issue that caused an error when Italian users opened Tax Returns after switching the interface language to Italian. The Submit button is now identified reliably regardless of translation, improving access to Italian tax return workflows.
Original PR description
Steps: - Install 'l10n_it_xml_export' and switch to an Italian company - Install the Italian language - In Accouting Dashboard, configure the Tax Returns - Open the Tax Returns - Make sure you have a button 'Submit', review something if necessary - Switch the language to Italian - Traceback The xpath uses `text()` to select the element but the text in views is translated so the xpath does not work in all languages except English. We remove the check on text, `@name='action_submit'` should be enough. Ticket [link](https://www.odoo.com/odoo/project.task/5106966) opw-5106966 Forward-Port-Of: odoo/enterprise#96096
Romanian SAF-T reports now keep partner details even when their balance is zero, helping reports pass required customer/supplier identity checks. The update also avoids exporting empty general ledger lines while retaining the source document information and improves report processing efficiency.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#96317 Forward-Port-Of: odoo/enterprise#95804
Mexican electronic invoices no longer replace a missing invoice date with the current Mexico City date when posted. This avoids mismatches between invoice and due dates and makes invoice behavior more predictable.
Original PR description
At the moment, when an invoice that uses a CFDI is posted, the invoice date (if not already existing) is set to the current date in the Mexico City timezone. This default behaviour is just weird, and even if there might have been technical reasons for it in the past, these are no longer valid. This can also cause the default invoice date to be different from the default due date, which causes unexpected behaviour in tests. We therefore remove this override. runbot-233041 Forward-Port-Of: odoo/enterprise#96303
The mail app now correctly recognizes incoming emails from existing contacts when resetting prior bounce flags. This helps prevent contacts from remaining incorrectly marked as bouncing and avoids related discussion access issues when replying by email.
Original PR description
Incoming bounce email linked to a partner in the db is incrementing (in `message_receive_bounce`) the message_bounce value during the handling of the bounces (in `_routing_handle_bounce`) If later, an email linked to a partner existing in the db (and having a message_bounce > 0) is received (and not bounce). The `_routing_reset_bounce` is called to reset the message_bounce. However, prior to this fix, due to not normalizing the `email_from` contained in the `msg_dict`, well, the record having this value was never found and thus, not reset to 0. In 4935208, some of the user were unlinked for mail.discuss.channel when replying to one of the received email. opw-4935208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229889 Forward-Port-Of: odoo/odoo#227273
2 changes
Resolved issues and error corrections
This fixes an issue where a contact's email bounce status was not cleared after they later sent a valid incoming email. It helps prevent contacts from being incorrectly treated as unreachable and avoids unintended removal from mail discussion channels when replying by email.
Original PR description
Incoming bounce email linked to a partner in the db is incrementing (in `message_receive_bounce`) the message_bounce value during the handling of the bounces (in `_routing_handle_bounce`) If later, an email linked to a partner existing in the db (and having a message_bounce > 0) is received (and not bounce). The `_routing_reset_bounce` is called to reset the message_bounce. However, prior to this fix, due to not normalizing the `email_from` contained in the `msg_dict`, well, the record having this value was never found and thus, not reset to 0. In 4935208, some of the user were unlinked for mail.discuss.channel when replying to one of the received email. opw-4935208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229889 Forward-Port-Of: odoo/odoo#227273
The website cookie policy now points visitors to the current Google Analytics 4 cookie information instead of an outdated page that no longer works. This helps users access accurate privacy information when reviewing analytics cookie details.
Original PR description
The previous URL for Google Cookie usage pointed to the legacy Universal Analytics page, which is no longer available since July 1, 2024. Steps to reproduce: 1. Go to Website Settings and enable the Cookies Bar. 2. Visit /cookie-policy on the website. 3. Click on the link "Analytics cookies and privacy information." 4. Observe that the page is no longer available. This commit updates the link to point to the current Google Analytics 4 documentation, ensuring users can access the correct cookie policy information. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229594
3 changes
Resolved issues and error corrections
This fixes an error that could appear when users switched Odoo to Italian while working with Italian tax returns. The Submit button is now found reliably regardless of the displayed language, preventing a traceback and keeping the tax return flow usable.
Original PR description
Steps: - Install 'l10n_it_xml_export' and switch to an Italian company - Install the Italian language - In Accouting Dashboard, configure the Tax Returns - Open the Tax Returns - Make sure you have a button 'Submit', review something if necessary - Switch the language to Italian - Traceback The xpath uses `text()` to select the element but the text in views is translated so the xpath does not work in all languages except English. We remove the check on text, `@name='action_submit'` should be enough. Ticket [link](https://www.odoo.com/odoo/project.task/5106966) opw-5106966 Forward-Port-Of: odoo/enterprise#96096
This fix makes by-products display more accurately in the Shop Floor workflow, including where they appear and what quantities are shown. It also streamlines tracked by-product entry by opening the correct creation dialog, reducing confusion for manufacturing operators.
Original PR description
Shop Floor by-products fixes: - show by-products not linked to a workorder only on mo card - do not show locations for by-products - always show quantity done / to consume quantity - clicking (+) on tracked by-products now opens the create quant dialog rather than the quants list view task: 4781451 Forward-Port-Of: odoo/enterprise#96118 Forward-Port-Of: odoo/enterprise#91341
The Spanish Modelo 303 VAT return calculation now ignores unrelated tax tags when preparing closing entries. This helps ensure VAT return closing entries are accurate and avoids incorrect accounting results for affected Spanish tax reports.
Original PR description
Before this commit the domain of the modelo 303 would take into account irrelevant tax_tags, causing the closing entry to be incorrect. Fixed this by adding an additional domain to the _get_vat_closing_entry_additional_domain function. Forward-Port-Of: odoo/enterprise#96209 Forward-Port-Of: odoo/enterprise#96106
8 changes
Resolved issues and error corrections
Fixed an issue that could block Italian companies from opening or submitting tax returns after switching the interface language to Italian. The change makes the submit button detection language-independent, preventing a traceback and improving reliability for localized users.
Original PR description
Steps: - Install 'l10n_it_xml_export' and switch to an Italian company - Install the Italian language - In Accouting Dashboard, configure the Tax Returns - Open the Tax Returns - Make sure you have a button 'Submit', review something if necessary - Switch the language to Italian - Traceback The xpath uses `text()` to select the element but the text in views is translated so the xpath does not work in all languages except English. We remove the check on text, `@name='action_submit'` should be enough. Ticket [link](https://www.odoo.com/odoo/project.task/5106966) opw-5106966 Forward-Port-Of: odoo/enterprise#96096
This fix prevents website pages from crashing when a social sharing cover image was saved with a full domain in its URL. It helps existing Odoo 19.0 websites keep working correctly after changing domains or using multiple domains.
Original PR description
In 17.0 up to master, website_meta_og_img for newly added cover image should be a relative URL instead of an absolute URL since 27th september 2025 commit 4c5d9861e389534f9ca684b9faa1ce6289df5639. This solves an issue in 19.0 where: - if you have a website_meta_og_img field with absolute URL - and then you change domain or have multiple domain => you would get an error 500 on the page with that website_meta_og_img But for existing 19.0 instances that have set custom website_meta_og_img before the fix, the issue could still happen at any moment they change domain. This fix allows to have an absolute URL in website_meta_og_img and modify it on the fly only in 19.0 version. note: a migration script (the same than [1] but in 19.0 to saas-19.1) should be added to ensure there is no remaining absolute URL. [1]: odoo/upgrade@5408746b110d660901645b9c7b9aa9cee7aaf235 opw-5101875 opw-5102079 opw-5105258 opw-5107443 opw-5111474 opw-5112343 opw-5113844 opw-5114544
Creating a payroll pay run no longer triggers an error in the Swiss payroll localization. This helps payroll teams proceed with pay run setup without being blocked by a system traceback.
Original PR description
Currently on master when you try to create a pay run it creates a traceback, mentioning that _get_valid_version_ids is given 7 arguments and only 6 were taken, this probably happens because the overloaded function in Swiss l10n wasn't adapted task: 5082011
The AI field picker now prevents the same field from being selected more than once and clearly marks fields that are already selected. Long field names also wrap correctly, making them easier to remove when needed.
Original PR description
before this commit: When you press Enter in the field picker, it will always pick the same field again, even if it is not visible. After this commit: A field can only be selected once, and it stays visible in the list. Added a visual check to show that the field is already selected. Forward-Port-Of: odoo/enterprise#93890
Posting Mexican CFDI invoices will no longer automatically replace a missing invoice date with the current Mexico City date. This avoids inconsistent invoice and due dates, making invoice behavior more predictable and reducing test-related surprises.
Original PR description
At the moment, when an invoice that uses a CFDI is posted, the invoice date (if not already existing) is set to the current date in the Mexico City timezone. This default behaviour is just weird, and even if there might have been technical reasons for it in the past, these are no longer valid. This can also cause the default invoice date to be different from the default due date, which causes unexpected behaviour in tests. We therefore remove this override. runbot-233041 Forward-Port-Of: odoo/enterprise#96303
Fixed an issue where a contact's email bounce status was not cleared after they later sent a valid incoming email. This helps prevent valid contacts from being treated as unreachable and avoids incorrect removal from email discussion channels.
Original PR description
Incoming bounce email linked to a partner in the db is incrementing (in `message_receive_bounce`) the message_bounce value during the handling of the bounces (in `_routing_handle_bounce`) If later, an email linked to a partner existing in the db (and having a message_bounce > 0) is received (and not bounce). The `_routing_reset_bounce` is called to reset the message_bounce. However, prior to this fix, due to not normalizing the `email_from` contained in the `msg_dict`, well, the record having this value was never found and thus, not reset to 0. In 4935208, some of the user were unlinked for mail.discuss.channel when replying to one of the received email. opw-4935208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229889 Forward-Port-Of: odoo/odoo#227273
Romanian SAF-T exports now correctly include partners even when their balance is zero, ensuring each partner can still be identified as a customer or supplier. This helps avoid validation errors in official Romanian reporting while also improving report query efficiency.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#96351 Forward-Port-Of: odoo/enterprise#95804
The website cookie policy now links to the current Google Analytics 4 documentation instead of an unavailable legacy page. This helps visitors access accurate information about analytics cookies and privacy from the cookie policy page.
Original PR description
The previous URL for Google Cookie usage pointed to the legacy Universal Analytics page, which is no longer available since July 1, 2024. Steps to reproduce: 1. Go to Website Settings and enable the Cookies Bar. 2. Visit /cookie-policy on the website. 3. Click on the link "Analytics cookies and privacy information." 4. Observe that the page is no longer available. This commit updates the link to point to the current Google Analytics 4 documentation, ensuring users can access the correct cookie policy information. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229594