Friday, June 5, 2026
18 changes · saas-18.3
Enhancements to existing features
This update aligns the default VAT reporting frequency for Norwegian businesses within Odoo Enterprise to bi-monthly (every 2 months). This change simplifies reporting for our Norwegian customers, matching the most common reporting practice in Norway and reducing potential administrative burden. It’s a straightforward improvement to the accounting process.
Original PR description
Set the default VAT periodicity for Norwegian companies to every 2 months, aligning with the most commonly used reporting frequency in Norway. task-6209940
This update enhances the Odoo profiling tool by automatically tracking the time taken for database queries. Previously, profiling data was incomplete. Now, the system captures query execution times and commits this data periodically, providing more accurate performance insights.
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#250383 Forward-Port-Of: odoo/odoo#215034
Resolved issues and error corrections
This update resolves an issue where the Profitability report's Cost of Goods Sold dashboard didn't display information when multiple invoices were associated with a project. The fix ensures that all related journal entries are correctly identified and shown, regardless of the number of invoices.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_project_stock` and Accounting. 2. Create a storable product with **Real-time valuation** and configure the COGS account in the product…
Steps to reproduce: ------------------- 1. Install `sale_project_stock` and Accounting. 2. Create a storable product with **Real-time valuation** and configure the COGS account in the product category expense account. (Ensure you have enabled automatic & analytic accounting from accounting>config.) 3. Create a project with a specific analytic account and ensure the project is billable. 4. Create a sale order with the created product and set the same analytic account in the analytic distribution. 5. Confirm the order, deliver the product, generate the invoice, and post it. 6. Open the project and go to the *Profitability* report. 7. Click on the **Cost of Goods Sold** dashboard item. 8. Repeat steps 4–7 with multiple invoices. Issue: ------ When there is only one invoice, clicking the COGS dashboard item correctly displays the related move lines. However, when there are multiple invoices, the action opens with empty results. Cause: ------ `_get_action_for_profitability_section` sets `res_id` only when a single record exists. When multiple records are present, `res_id` becomes `False`, which causes the action to open without results. https://github.com/odoo/odoo/blob/8f79d407724f40ba8e48f1747b2e87311b7fb49e/addons/project_account/models/project_project.py#L78-L83 Solution: --------- When `res_id` is not set, search `account.move` records using the domain to retrieve the relevant move IDs, then apply a proper domain to display all related COGS journal items. opw-5949261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267097 Forward-Port-Of: odoo/odoo#253639
This update fixes a bug in the spreadsheet account formulas that were causing errors when users entered company IDs as text. Now, all company IDs are automatically converted to numbers, ensuring the formulas function correctly regardless of the input format. This improves the reliability of the spreadsheet calculations.
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#268187 Forward-Port-Of: odoo/odoo#266009
This update resolves an error that occurred when users clicked the 'translate' button in the CRM module. The issue stemmed from how the system handled record saving in different view types, leading to a technical error. This fix ensures the translation dialog opens correctly regardless of the view type, improving user experience.
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
This update resolves an issue where the invoice creation process would sometimes fail due to the invoice line not being fully added before the next step in a guided tour. Adding a brief delay after product selection ensures the invoice line is created correctly, preventing tour failures and improving overall stability.
Original PR description
When a product is selected from the kanban view, the tour sometimes returns to the invoice form before the product is fully added. As a result, the invoice line is not created and the `.o_field_product_label_section_and_note_cell` element is missing from the table, causing the next tour step to fail. Add a short delay after selecting a product to ensure it is fully added to the invoice before proceeding with the following steps. runbot-238400 Forward-Port-Of: odoo/odoo#261295
This update resolves an issue where the IRN number wasn't being saved when sending invoices via e-invoicing with email in the Indian localization. The fix ensures the attachment ID is saved correctly, guaranteeing accurate IRN recording for e-invoices.
Original PR description
**Issue**: Sending invoice through e-invoicing with email in Indian localization will not save the IRN number on the invoice because of a cache issue on the attachment id. **Steps to reproduce**: Install l10n_in_edi_gstr module. Create an invoice and send it through e-invoicing with email option. The IRN number will not be saved on the invoice. **Causes**: When sending the invoice through e-invoicing with email option, the attachment id is not saved on the invoice before calling the method _l10n_in_edi_send_invoice(). This causes a cache issue and the IRN number is not saved on the invoice. **Fix**: Save the attachment id on the invoice after the creation of the attachement. opw-6243256
This update resolves an issue where users were unintentionally able to select properties within the field selector widget. The fix adds a new option to the widget and includes a corresponding test to ensure proper functionality. This improves the user experience and prevents potential data entry errors.
Original PR description
- Backporting this [commit], for adding the `allow_properties` option to `field_selector` widget in `saas-18.2` for using the functionality in linked enterprise commit. - Also, added a test for `allow_properties` option. - For forward ports, only the test will be merged, as `allow_properties` is already included in the original commit. [commit]: https://github.com/odoo/odoo/pull/215767/changes/7cd18c07b5e008bff072d10375c908eb77434fde sentry-7378769090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257833
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 period dates gracefully, preventing form creation failures and improving data reliability. This ensures accurate reporting calculations.
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 update resolves an issue where Peppol XML invoices with tax percentage information were failing to import correctly, resulting in empty bill creation. The fix addresses a parsing error within the UBL invoice processing module, ensuring accurate tax calculations and bill generation from these invoices.
Original PR description
Steps to reproduce: - Upload a Peppol XML bill having the tax percent reported under "TaxTotal/TaxSubtotal/Percent" Issue: Bill will be created empty. The chatter will report the error ``` Error importing attachment 'bill.xml' (type=account.edi.xml.ubl_bis3): This specific error occurred during the import: float() argument must be a string or a real number, not 'lxml.etree._Element' ``` opw-6227637 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/6227637) Forward-Port-Of: odoo/odoo#266307
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used, improving the accuracy and clarity of the exported data. This enhances the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119282 Forward-Port-Of: odoo/enterprise#112995
This update fixes the visibility of specific fields related to Saudi Arabia's tax regulations within the Odoo system. Now, these fields are only displayed for contacts and companies operating in Saudi Arabia, ensuring data accuracy and compliance. This change prevents irrelevant information from appearing in other company contexts.
Original PR description
This commit fixes the visibility logic of `l10n_sa_edi_additional_identification_*` fields. - `l10n_sa_edi_additional_identification_scheme` is now visible only when both the contact and the current company is Saudi. - `l10n_sa_edi_additional_identification_number` is visible for all contacts, but only when the current company is Saudi. This ensures the fields follow the intended localization scope and prevents them from appearing in non-Saudi company contexts. task-5881754
This update optimizes how Odoo processes QWeb templates, specifically addressing a performance issue related to template compilation. The change reverts a recent Markupsafe update that introduced a slower method for handling template tags, resulting in faster processing times. This ensures smoother and more responsive Odoo performance.
Original PR description
Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex. A problem has been…
Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex. A problem has been spotted with qweb templates that used `striptags` with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better for varying input size. The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either. Apart from that, the old implementation is consistently much more performant, for both small and large inputs. Benchmarks: | Case | Regex ms | Current ms | Speedup | |----------------------------------------------|----------|------------|---------| | plain_text_50k_words | 3.020 | 2.627 | 0.9x ← current_implementation | | unclosed_tag_then_50kb_text | 0.367 | 0.032 | 0.1x ← current_implementation | | unclosed_tag_then_500kb_text | 3.787 | 0.273 | 0.1x ← current_implementation | | multiple_unclosed_open_tags_then_50kb_text | 18.912 | 0.371 | 0.0x ← current_implementation | | multiple_unclosed_open_tags_then_500kb_text | 189.007 | 8.209 | 0.0x ← current_implementation | | unclosed_comment_then_500kb_text | 7.276 | 0.412 | 0.1x ← current_implementation | | 5k_small_tags | 0.986 | 22.096 | 22.4x ← regex_old_implementation | | 20k_small_tags | 4.125 | 492.186 | 119.3x ← regex_old_implementation | | 50k_small_tags | 12.658 | 5499.602 | 434.5x ← regex_old_implementation | | 1k_nested_divs | 0.155 | 0.923 | 5.9x ← regex_old_implementation | | 10k_nested_divs | 1.648 | 48.410 | 29.4x ← regex_old_implementation | | 2k_tags_with_attrs | 1.058 | 12.013 | 11.4x ← regex_old_implementation | | 20k_tags_with_attrs | 13.185 | 6068.755 | 460.3x ← regex_old_implementation | | 2k_multiline_tags | 0.815 | 10.819 | 13.3x ← regex_old_implementation | | 20k_multiline_tags | 8.939 | 4231.768 | 473.4x ← regex_old_implementation | | 1k_comments | 0.222 | 1.292 | 5.8x ← regex_old_implementation | | 1k_comments_hiding_tags | 0.163 | 1.121 | 6.9x ← regex_old_implementation | | 2k_mixed | 0.278 | 2.392 | 8.6x ← regex_old_implementation | | 10k_mixed | 1.400 | 50.959 | 36.4x ← regex_old_implementation | | qweb_shop_200_products | 0.907 | 7.880 | 8.7x ← regex_old_implementation | | qweb_shop_1000_products | 4.296 | 194.647 | 45.3x ← regex_old_implementation | This PR is needed because requirements.txt in Odoo specifies the following dependency: `MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)` This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe. opw-5999688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258643 Forward-Port-Of: odoo/odoo#257889
This 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, the system now allows uploads regardless of user access rights, streamlining the document request process. This ensures all authorized users can contribute documents to requests.
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
This update fixes a display issue where the 'Out of Office until...' date in team discussions was incorrectly showing the previous day when users were in negative timezones. The fix ensures the date is always displayed in UTC, resolving the timezone conversion problem and providing accurate leave information.
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
This update resolves an issue where invoices generated from the Odoo website's e-commerce orders were incorrectly configured to generate CFDI (Mexican electronic invoicing) publicly. The change ensures that invoices are only CFDIed publicly when the customer provides all necessary information, streamlining the process and aligning with business requirements.
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 resolves an issue where invoicing users were unable to access related PDP flow data. By allowing invoicing users to read these flows, the change enables them to properly display and utilize e-reporting-related fields and buttons within invoices. This improves the functionality for invoicing processes.
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 update resolves an issue where participant emails were unintentionally revealed in notification emails within the gamification eLearning app. The fix prevents users from seeing each other's email addresses, enhancing privacy and user experience. This ensures compliance with data protection policies.
Original PR description
**Steps to reproduce:** - Install eLearning app with gamification - Go to Settings > Gamification Tools > Challenges - Set a challenge with multiple participants (portals / internals) - Set its state…
**Steps to reproduce:** - Install eLearning app with gamification - Go to Settings > Gamification Tools > Challenges - Set a challenge with multiple participants (portals / internals) - Set its state to Done - Notification email is sent to every participants - They can see each other in the mail header (portal user can see all other portal users, internal user can see all portal users) **Issue:** Since [1] external recipients are added in the mail header, but this is not adequate for every flows (here there is no need for the participants to be aware of each other). **Fix:** In [2] this issue was mitigated by removing the `'X-Msg-To-Add'` from the header for models which don't need it. Then in [3] the solution was replaced by a more generic approach using `_CUSTOMER_HEADERS_LIMIT_COUNT = 0`. [1] https://github.com/odoo/odoo/commit/42aaaef59d21558438c767c6dd8a21674e5df9df [2] https://github.com/odoo/odoo/commit/e6c13ce4436b3c8b3a2058d2ccf65a7da1b256b2 [3] https://github.com/odoo/odoo/commit/c4dbd868b9c7e26f11db4d2cacef7ffce6c87082 opw-6099745 Forward-Port-Of: odoo/odoo#267192