Friday, May 22, 2026
14 changes · saas-18.4
Resolved issues and error corrections
This fixes a time zone-related issue that could make an automated Time Off test fail at certain times of day. The change improves confidence in test results without changing employee-facing functionality.
Original PR description
Issue: ----------------------------------- At certain times of the day (e.g., around midnight UTC), the test would fail deterministically ``` test_allocation_stats_with_duplicate_leave_type_names…
Issue:
-----------------------------------
At certain times of the day (e.g., around midnight UTC), the test would fail deterministically
```
test_allocation_stats_with_duplicate_leave_type_names
self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10)
AssertionError: 0.0 != 10
```
Cause:
-----------------------------------
This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date)
At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10.
Solution:
-----------------------------------
Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood.
Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759)
Related PR: https://github.com/odoo/odoo/pull/261680
Forward-Port-Of: odoo/odoo#265717
Forward-Port-Of: odoo/odoo#265703In POS Restaurant, removing a general note now correctly clears the message badge on the “Send to Kitchen” button. This prevents staff from seeing a false indicator that there are pending note changes, reducing confusion during order handling.
Original PR description
Steps to reproduce:
-----------
- Open POS Restaurant
- Add a General Note
- Remove the General Note
- The message badge on “Send to Kitchen” remains visible
Issue:
-----------
Removing a General Note set `general_note` to `undefined`, which was
detected as a change and kept the badge visible.
Fix:
--------------
Normalize empty General Notes to an empty string ("") so removing a note
restores the correct initial state.
Task-6101501
Related PR: odoo/enterprise#113514
Forward-Port-Of: odoo/odoo#265652
Forward-Port-Of: odoo/odoo#258632The Point of Sale product information popup now shows the total available stock for the product template instead of only one selected variant. This gives store staff a more accurate stock view when checking products with variants, reducing confusion during sales.
Original PR description
When opening product info in POS for a product with variants and inventory tracking, Units Available was computed from the selected variant (or first variant), which is incorrect for this popup. It should display the product template available quantity. Partial backport of : 6f3fe739c1af9bbe5f1a61f32431ba5c5aed3e12 Steps to reproduce: ------------------- * Open a POS session. * Long press a storable product with inventory tracking enabled and variants. (e.g. Customizable Desk) > Observation: Units Available shows variant quantity instead of template quantity. Why the fix: ------------ The product info popup is template-oriented and must show template stock values. This fix updates `get_product_info_pos` to use template available quantity for all variants. opw-5703723 Forward-Port-Of: odoo/odoo#250627
Imported UBL invoices now keep lines that total zero because they were fully discounted, instead of treating them as empty. This helps businesses reconcile supplier bills accurately when discounts, eco-taxes, excise charges, or returnable packaging are present.
Original PR description
`_import_ubl_invoice_add_base_lines` filters out every imported line whose `total_included_currency` is zero, on the assumption that a zero-amount line carries no useful information. This is correct for truly empty rows, but wrong for 100%-discounted lines, an ecotax or excise row, or a returnable-packaging entry nets to zero precisely because the supplier discounted it entirely, and the line still carries data the customer needs to reconcile the bill against the original document opw-6176349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265284
Jordan POS electronic invoices could be rejected by Jofotara when rounding produced a tiny negative discount amount on an invoice line, even when no discount was intended. This fix ensures per-line discount amounts are always sent as non-negative values, helping valid POS invoices and refunds pass submission checks.
Original PR description
Before this commit: 1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3) 2. Send the order to Jofotara Jofotara rejects the…
Before this commit:
1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3)
2. Send the order to Jofotara
Jofotara rejects the invoice because the AllowanceCharge/Amount on the invoice line is a small negative value like -0.000000001 with the error `"EINV_MESSAGE":"discount cannot be negative"`
This happens because _add_document_line_gross_subtotal_and_discount_vals computes the discount as: gross_subtotal - total_excluded_currency
where gross_subtotal goes through two independent rounding steps (round unit price, then round unit_price * qty). When the quantity is indivisible, the reconstituted gross_subtotal can land just below total_excluded_currency by a floating-point epsilon, producing a tiny negative discount. The same subtraction also produces a legitimate negative value for refund lines (negative quantity), which was already handled by abs() in _add_pos_order_discount_vals for the document-level total but was left unguarded at the per-line level.
After this commit:
Apply abs() to vals[f'discount_amount{currency_suffix}'] in _add_pos_order_line_allowance_charge_nodes so that discount_amount_currency is always non-negative.
opw-6183423
Forward-Port-Of: odoo/odoo#265159Users can now clear the date in the Accrued Expense Entry wizard without triggering an error. This prevents an interruption when working from purchase orders and keeps the accounting workflow usable even when the date field is temporarily empty.
Original PR description
Currently, error occurs when user removes date on Accrued Expense Entry wizard. Steps to replicate: - Install `purchase` and `accountant` with demo. - Open any Purchase Order > Click on cog menu >…
Currently, error occurs when user removes date on Accrued Expense Entry wizard.
Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.
Error:
```
File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
if not record.reversal_date or record.reversal_date <= record.date:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'
```
Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.
Solution:
- Added a conditional check for `date` before the date comparison.
[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67
No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262568Fixed an issue where product search results on the shop page could appear cut off when page content was placed above the search bar. This keeps shoppers able to see and select all search suggestions, improving usability during product discovery.
Original PR description
On /shop, when a snippet block sits above the searchbar, the search dropdown was rendered partially hidden behind that block (cropped/unreadable items). Steps to reproduce: =================== 1. Go…
On /shop, when a snippet block sits above the searchbar, the search dropdown was rendered partially hidden behind that block (cropped/unreadable items). Steps to reproduce: =================== 1. Go to /shop. 2. Add a snippet block above the searchbar. 3. Type in the searchbar. => Observed: search results appear cropped, with upper items hidden behind the snippet block above. Root cause: =========== the products grid column (`#products_grid`) has `overflow: auto`, https://github.com/odoo/odoo/blob/d9bb1c1dc90f97b63b87ad762fc4ab36abf7e05f/addons/website_sale/static/src/scss/website_sale.scss#L442 which clips any absolutely-positioned descendant that extends past its bounds. The dropdown's containing block is the searchbar `<form>` (position: relative), which lives inside that column. When the dropdown grew (or flipped to dropup) and extended outside the column, the part outside was clipped, and any positioned snippet siblings above the column painted over the clipped area. Fix: ====== while the dropdown is mounted, lift the `overflow: auto` on its ancestor `div.col` so the menu can extend past the column and paint on top of other content. Done from JS so no SCSS rule has to target the searchbar-specific column. opw-6216317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265558
The HTML editor's Caption button is now included in translation support. This helps users working in different languages see a fully localized editing experience.
Original PR description
Currently the "Caption" button in the HTML editor is not translatable. This commit fixes that.
This fix standardizes how spreadsheet date ranges are displayed so they no longer vary between Chrome versions. It helps keep dashboard and spreadsheet filter behavior predictable and prevents version-specific test failures.
Original PR description
Some dependencies in the chrome build changed between chrome 145 and 148 which changes the output value of luxon.Interval.toLocaleString, more specifically, some space characters were changed and the tests can pass or not depending on the chrome version they run with. This revision forces a standardized output. task-6233171 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
A recent update caused errors when downloading signed documents through the Sign app. This fix corrects a problem related to how Odoo handles PDF compression, specifically with newer versions of the pypdf library. The change ensures documents download correctly without errors.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/enterprise#117999 Forward-Port-Of: odoo/enterprise#117756
This update resolves an issue where the generic tax report wouldn't display an error message when dealing with negative net values. The fix ensures the report accurately checks for tax discrepancies, even when balances are negative, preventing misleading results.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update removes a redundant step in creating embedded actions within Odoo. Previously, manual translations were required; now that embedded actions automatically inherit translations from their linked actions, this workaround is no longer necessary. This simplifies the process and ensures consistent translations.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#116793 Forward-Port-Of: odoo/enterprise#116369
This update corrects a translation issue in the Odoo Gantt view. The button used to toggle display modes was not correctly translated, preventing users from seeing the view in their preferred language. This fix ensures all users can consistently access and understand the Gantt view's options.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
This update resolves an issue where constant fields within signing documents would become empty during the signing process, leading to signing failures. The fix ensures that default field values are retained when auto-fields return empty strings, preventing the 'Some required items are not filled' error and improving the reliability of the signing workflow.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign template. - Add a sign item with read only true and linked model and auto_value field set. - Send document for signing. - Try to sign the document. Issue: - Signing fails with "Some required items are not filled". - Constant readonly fields become empty during signing flow. Cause: - In `_populate_constant_items()`, the default field value was always replaced by `_get_auto_field_value()`. - When no reference document was set, `_get_auto_field_value() `returned an empty string. - This caused an empty value to be stored in `sign.request.item.value`. Solution: - Keep the default field value when auto-field resolution returns an empty string. - Only replace the value when a valid auto-field value is found. task-6229776