Friday, June 5, 2026
9 changes · saas-18.2
Enhancements to existing features
The profiling tool now records database query timing more safely and commits collected data after a time limit during sampling. This helps avoid losing profiling information during long or heavy operations, improving diagnostics for performance investigations.
Original PR description
Modify the query collector so that it add an entry before the query runs and updates the time after it runs. use the async collector periodic sampling to commit the profiler after a time limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248541 Forward-Port-Of: odoo/odoo#215034
Resolved issues and error corrections
This fixes an issue where employees in negative time zones could see an incorrect “Out of Office until” date in Discuss. The displayed leave end date now stays accurate regardless of the user’s local time zone, reducing confusion when contacting colleagues who are away.
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#267677 Forward-Port-Of: odoo/odoo#267479
Fixes an issue where clicking the translation button while creating or editing a record could trigger an error instead of opening the translation dialog. This helps users manage translated field values without interruptions, including in CRM tag configuration and similar editable list screens.
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 Forward-Port-Of: odoo/odoo#267914
French PDP reporting flow forms now handle missing period dates safely during setup or editing. This prevents crashes when creating new or incomplete records, improving reliability for users working with French e-invoicing reporting flows.
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 Forward-Port-Of: odoo/odoo#268002
This fix lets users with invoicing access view invoices that reference French PDP reporting flows without being blocked by access restrictions. It helps avoid interruptions when opening invoice screens that need to check e-reporting status or related actions.
Original PR description
Allow invoicing users to read PDP reporting flows. Invoice views can read PDP flow relations to evaluate e-reporting-related fields or buttons. Users with invoicing access could open the invoice but were blocked when Odoo tried to read the linked PDP flow. runbot.build.error-939457 Forward-Port-Of: odoo/odoo#268462
This fixes an issue where saving an Odoo configuration could accidentally remove an existing custom binary path setting. Businesses using this setting can now update and save configuration files without losing that important environment-specific value.
Original PR description
Have a configuration file with a "bin_path" entry. Use that config file and --save it. The "bin_path" entry is removed from the new config file, it should had been persisted. The problem is common to all "undocumented options", options that did not exist in `config.py` before ConfigCleaner(7) and that were not created upon --save. We can argue about creating or not those options upon --save with the default config, but what's sure is that when the option be set in the config file, then it must be persisted across saves. Task-6106771 Reference-to: 80007415d621 ([REF] core: ConfigCleaner(7) remove deprecated options) 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 corrects a previous issue where all e-commerce invoices were automatically formatted as CFDI (Mexican electronic invoicing). Now, invoices generated from the website will only be CFDI to public when explicitly required, aligning with standard business practices and customer data privacy.
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#119171 Forward-Port-Of: odoo/enterprise#116061
This update fixes a potential issue where closing a POS session could incorrectly identify and block the cancellation of transactions belonging to other POS terminals. The change now ensures that only transactions associated with the specific POS terminal are retrieved, preventing errors and improving the reliability of session closure. This enhances the overall stability of the POS system.
Original PR description
Before this commit, when closing a POS session, it fetched all active transactions via generic /tx endpoint, which returns transactions across all TSS. Attempting to cancel a transaction belonging to another TSS raised:
"Not a Transaction of TSS <tss_id>"
Fix by scoping the fetch to /tss/<tss_id>/tx so only transactions of the current TSS are returned, and appending client_id as an additional filter to avoid touching transactions from other POS terminals sharing the same TSS. A JS-side client_id check is kept as a defensive safety net before the cancellation loop.
opw-6243187
Forward-Port-Of: odoo/enterprise#118662This update resolves an issue where users were blocked from uploading documents to requests linked to records they didn't have full access to. By adding a special permission bypass, users can now upload documents regardless of their direct access rights to the related record, 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 Forward-Port-Of: odoo/enterprise#113698