Thursday, June 4, 2026
7 changes · 18.0
New functionality added to Odoo
This update expands Odoo's SII (Societat Impostaria Informàtica) functionality to include support for the Hacienda Foral de Navarra tax agency. It addresses a specific requirement for Navarra businesses to use a different endpoint and XML namespace declarations when submitting invoices, ensuring compliance with local regulations. This addition allows companies to accurately report SII data to the Navarra tax authority.
Original PR description
The Hacienda Foral de Navarra uses the same SII XML format as AEAT but sends invoices to a different endpoint. Additionally, Navarra requires explicit XML namespace declarations in the SOAP envelope header, which the standard zeep serializer does not include by default. This adds the Navarra tax agency as a new option in the company SII configuration, defines its production and test endpoints, and injects the required namespaces in the request header when the Navarra agency is selected. task-5946583 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves an issue where spreadsheet formulas in the Account module were sending company IDs as strings, leading to server errors. The change ensures company IDs are converted to numbers, handling both numeric and null values correctly for accurate calculations. This improves spreadsheet stability and reliability.
Original PR description
Current behavior before PR: - The `ODOO.CREDIT`, `ODOO.DEBIT`, and `ODOO.BALANCE` formulas passed `companyId.value` directly to the server without converting it to a number. - If a user passed company_id as a string (e.g., '1' from a cell), it was sent to the server as a string, causing a server error. Desired behavior after PR is merged: - `companyId` is converted using toNumber() before being passed to the getter and the server, so '1' becomes 1. - null is preserved as-is (no company filter) while any non-null value is safely cast to an integer. Task: [6240005](https://www.odoo.com/odoo/project/2328/tasks/6240005) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266009
This update fixes an issue where the 'Out of Office until...' date displayed in the Discuss chat was incorrect when users were in negative timezones. The fix ensures the date is always shown in UTC, resolving a display discrepancy and improving the accuracy of leave information for employees and managers.
Original PR description
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce:…
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce: ---------------------------------------- - Change the timezone of the user to "America/Toronto" for example - Have an employee currently on leave until tomorrow - Open discuss to chat with this employee - The "Out of Office until..." shows today's date Cause: ---------------------------------------- When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone). Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date. Solution: ---------------------------------------- Add `timeZone:"UTC"` in the options to avoid the timezone conversion. opw-6252040 Forward-Port-Of: odoo/odoo#267479
This update resolves an error that occurred when users clicked the 'translate' button in the CRM module. Specifically, the issue stemmed from how the system handled record saving in different view types, leading to a technical error. This fix ensures the translate button functions correctly across all scenarios.
Original PR description
Currently, an error occurs when the user clicks on the translate button. **Steps to Reproduce:** - Install the `CRM` module. - Go to `settings` and in `Languages` add 1 more language. - Go to `CRM` >…
Currently, an error occurs when the user clicks on the translate button. **Steps to Reproduce:** - Install the `CRM` module. - Go to `settings` and in `Languages` add 1 more language. - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`. - Click `New` and, in the `Name` field click the `translate button` on the right. **Behavior in 18.0** When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, the translation dialog shows the translated value on the second click. **Behavior in saas-19.1** `AssertionError: Invalid falsy real id` Error: After this [recent commit], when the user clicks on the translate button, if the record has a root record, the root record is saved before opening the translation dialog. However, in the case of an editable DynamicList view, the record does not have a root record so saving the record returns a promise instead of the resolved value [1]. Because of this promise, the condition fails [2], and the translation dialog is opened with a falsy ID since the record is not yet saved [3]. In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f). This commit ensures that await is used so the resolved value is returned after the record is saved before opening the translation dialog. [recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be [1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23 [2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26 [3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41 sentry-7384270487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a potential error in the PDP reporting flows that could occur when new or incomplete flow records are created. The fix ensures the system handles missing due dates gracefully, preventing crashes during form creation. This improves the stability and reliability of the reporting process.
Original PR description
PDP reporting flows compute their period status from the due period dates. On a new or incomplete flow record, those dates can still be empty during form/onchange initialization. The compute then tried to compare today's date with `False`, which could crash generic form creation. This patch makes the compute handle missing period dates before doing date comparisons. runbot.build.error-939459
This update resolves an issue where users were prevented from uploading documents to requests linked to records they didn't have full access to. By adding a '.sudo()' function during the attachment creation process, users can now upload documents regardless of their specific access rights, improving workflow efficiency.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099
This update corrects a previous issue where website orders automatically generated CFDI invoices, which was unnecessary and potentially problematic. Now, invoices are only created for website orders when the customer provides all required information, aligning with standard e-commerce practices. This ensures a smoother and more accurate order process.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#116061