Wednesday, June 3, 2026
13 changes · 18.0
Resolved issues and error corrections
This update corrects a bug in the appointment scheduling system's interval inversion function. The fix ensures accurate interval calculations across a range of scenarios, preventing incorrect scheduling and improving overall appointment management. New tests have been added to guarantee this fix.
Original PR description
The [commit](https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c) introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. Forward-Port-Of: odoo/enterprise#107112
This update resolves an issue where the image for a Text Cover block wasn't visible on mobile devices when toggled to be visible. The change adds a minimum height to the image element, ensuring it renders correctly below the 'lg' breakpoint. This improves the user experience for mobile viewers using Text Cover blocks.
Original PR description
Steps to reproduce: =================== 1. Add a Text Cover block to a page. 2. Optionally remove the text column so only the image remains. 3. Open the image column options and set "Visible on…
Steps to reproduce: =================== 1. Add a Text Cover block to a page. 2. Optionally remove the text column so only the image remains. 3. Open the image column options and set "Visible on Mobile". 4. Switch to mobile view. => Image column is empty. Root cause: ============ The image grid item is empty (background-image only) and relies on the parent `.o_grid_mode` being `display: grid` to be sized via `grid-area`. That `display: grid` rule is gated at `media-breakpoint-up(lg)` https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/web_editor/static/src/scss/web_editor.frontend.scss#L66 so below `lg` the item is a normal `display: block` element with no `col-*` class active (it has `g-col-lg-6 col-lg-6`, both `lg`-only) and no `g-height-*` CSS effect outside grid mode. The element therefore collapses to 0 height and the background image paints nothing. This regressed when the mobile-hidden breakpoint was extended from `md` to `lg`: - (See [1]) changed `d-none d-md-block` to `d-none d-lg-block o_snippet_mobile_invisible`. Before that, hiding only applied below `md`, where the image was rarely shown; afterwards the user can ask for it on mobile but gets an empty box. Fix: ==== Give the empty `oe_img_bg` grid item a `min-height` below `lg` so it has something to paint when the user makes it mobile-visible. [1]: https://github.com/odoo/odoo/commit/079575b8ba645e7ec564967698d76a94d18022c1 opw-6228392 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the DIN 5008 delivery slip layout wasn't properly hiding information. The fix involves a change to the CSS that prevents the 'information block' from being overridden, ensuring the DIN 5008 format correctly suppresses unwanted data on the delivery slip.
Original PR description
Steps to reproduce: ------------------- - Install `l10n_din5008` - Configure the document layout as DIN 5008 - Create and validate a delivery order - Print the delivery slip Issue: ------ The…
Steps to reproduce:
-------------------
- Install `l10n_din5008`
- Configure the document layout as DIN 5008
- Create and validate a delivery order
- Print the delivery slip
Issue:
------
The delivery slip still displays the information block (Order, Shipping Date, Total Weight, etc.),
although the DIN 5008 layout is expected to hide it.
Cause:
---------
The DIN 5008 layout made to hides the delivery slip `information` block: https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/l10n_din5008/static/src/scss/report_din5008.scss#L73
Unfortunately, this behavior was broken in this [commit](https://github.com/odoo/odoo/commit/28c1cc6025005cd0937afbc452a722235cc5a38d):
The main purpose of this commit was to fix the alignment of the delivery slip.
As part of the fix, it added `class="report-wrapping-flexbox"`:
https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/stock/report/report_deliveryslip.xml#L49
This prevents the information block from being hidden because of the CSS `!important` property:
https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/web/static/src/webclient/actions/reports/bootstrap_review_report.scss#L59-L62
So when switching to the DIN 5008 format, it tries to hide the information block,
but the `!important` property prevents it from being hidden.
Solution:
------------
Backport this [commit](https://github.com/odoo/odoo/commit/8d588f8198d9057311304e596c009a0795ca6ec7):
In this commit, instead of targeting the `#information_block` itself,
it targets its children and hides all of them except `plan`.
As a result, all other children of the information block become hidden.
Since there is no `!important` rule on the children, they can be hidden successfully.
The information block then becomes empty and nothing is displayed.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/7529dec3-977b-4bee-8c0c-5ce8c09a09e9" />
</div>
<p><strong>After:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/96ed3f8f-c874-4059-a19f-5ea3b380aba3" />
</div>
</details>
Why this fix:
--------------
These two different behaviors up to saas-18.4 and 19.0 led to a misunderstanding.
---
opw-6250072
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA minor issue with the automated testing process (pylint) was identified and resolved. This ensures the quality and consistency of our French localization code, preventing potential errors before release. The fix improves the reliability of our testing framework.
Original PR description
```
FAIL: TestPyLint.test_pylint
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/test_lint/tests/test_pylint.py", line 109, in test_pylint
self.fail(f"pylint test failed:\n\n{r.stdout}\n{r.stderr}".strip())
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: pylint test failed:
************* Module l10n_fr_pdp.tests.test_partner
function already defined line 134 (E0102) at odoo/addons/l10n_fr_pdp/tests/test_partner.py:152
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
```
runbot.build.error-939452This update resolves a bug preventing the correct processing of Peppol XML bills containing tax percentage information. The issue stemmed from an error in how the system interpreted the XML data, resulting in empty bills. This fix ensures accurate bill creation and import from UBL documents.
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)
This update resolves an issue where setting a non-numeric value for the 'next check number' in bank journals caused an error. The fix ensures the system validates the input to only allow numeric characters before attempting conversion, preventing the error and ensuring proper check number management.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where time off allocation titles displayed excessively long decimal values. The change rounds the calculated duration to two decimal places, presenting a cleaner and more user-friendly display of hours. This ensures accurate and easily understandable information for time off requests.
Original PR description
Steps to reproduce: ------------------- 1. Install Time Off 2. Create an employee with a 38-hour working schedule (7.6h/day) 3. Create a time off type with request unit set to "Hours" 4. Create an…
Steps to reproduce: ------------------- 1. Install Time Off 2. Create an employee with a 38-hour working schedule (7.6h/day) 3. Create a time off type with request unit set to "Hours" 4. Create an allocation for this employee with a duration of 8 hours 5. Observe the allocation title displaying a long decimal value. (e.g., 7.999999999999999) Issue: ------ The `number_of_days` is calculated in `_compute_number_of_days` using: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L261-L262 For an 8-hour request on a 7.6h/day schedule, this results in ~1.052631579 days. In `_get_title`, this value is multiplied back to show hours: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L151 This multiplication leads to the long decimal values being displayed in the title. Solution: --------- Round the computed duration to two decimal places using `float_round`. **NOTE:** This issue is already fixed in saas-19.1 (commit 01d86a7). However, **no change** is required in the multi-allocation wizard, as the duration there directly uses user input and is not computed from working hours. opw-6091424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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, reusing precomputed values and preventing unintended overwrites. This results in more accurate and understandable ICP export data.
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#118998 Forward-Port-Of: odoo/enterprise#112995
This update resolves a problem where users were incorrectly denied access to create WhatsApp templates for events. The fix prevents users from creating new templates, ensuring proper access control and preventing the 'User does not have access' error. This improves the event communication process.
Original PR description
Issue: 1) User goes to Event.event Form -> communication tab -> add line 2) Select whatsapp -> type something -> create and edit -> create new template with any model event.registration -> save ( all the way including the event form) 3) reload page -> whatsapp event.mail displays "User does not have access to this record". Fix: add "'no_create_edit': True" to the associated field in the xml to block creation of new mail.templates opw-6037488
This update resolves an issue where the system incorrectly blocked sending invoices to 0225 Peppol EAS partners. Previously, this only worked when the French PDP module was installed. Now, it's enabled by default, ensuring compatibility with all Peppol partners, and resolving a problem with demo data installation.
Original PR description
Previously we blocked the 0225 peppol_eas when `l10n_fr_pdp` is not installed. But you should still be able to send to 0225 partners with just peppol. Since the PDP module is auto installed with the French localization and we block the 0225 EAS server side on the peppol (non-PDP) server it should be fine to just allow it for everyone. It also caused an issue when installing the demo data for the `hair_salon` industry in a French company on trial. opw-6268629
This update fixes a display issue where negative extra prices on combo items were incorrectly shown with a '+' sign or incorrect currency formatting. The change ensures that negative prices are consistently and accurately displayed, improving the clarity and accuracy of the point-of-sale and kiosk interfaces.
Original PR description
When a combo choice has a negative extra price, the POS and Kiosk would incorrectly display a '+' sign in front of the negative price (e.g., '+ -0,30 €'). Additionally, depending on the currency formatting rules, a negative price might be displayed with the minus sign after the currency symbol (e.g., '$ -1.00'). This commit fixes this by conditionally displaying the '+' sign only when the extra price is strictly positive, and handling the minus sign manually to ensure it is always prepended correctly (e.g. '- $ 1.00'). task-id: 6226406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where online orders with 'tax included' products were incorrectly calculating prices. The fix ensures that the displayed unit price and tax-inclusive price accurately reflect the total cost of the product, including the applicable tax. This improves order accuracy for UrbanPiper integrations.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196
This update fixes a potential error that could occur when copying data within the Odoo tools module in Python 3.14. The fix ensures the copy operation is performed reliably, preventing a runtime error caused by the Python Garbage Collector. This improves the stability and reliability of the tools.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947