Friday, May 22, 2026
12 changes · saas-18.3
Resolved issues and error corrections
A recent update to Odoo's document processing caused errors when downloading signed documents. This fix corrects a problem related to how PDF compression was handled with newer versions of the pypdf library. By moving the compression step, the download process is now reliable.
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/odoo#265699 Forward-Port-Of: odoo/odoo#265304
A recent update caused errors when downloading signed documents through the Sign app. This fix addresses a compatibility issue with a newer version of the pypdf library, ensuring documents are downloaded correctly. The change ensures compression happens only on the correct object, resolving the error.
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#117971 Forward-Port-Of: odoo/enterprise#117756
A test was failing due to a mismatch between the timezone used in the test and the date calculations within the HR holiday allocation system. This update ensures that all date calculations are performed using UTC, resolving the issue and preventing incorrect leave allocation counts. This fix improves the reliability of the holiday calculations.
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#265703This update resolves an issue where the generic tax report wouldn't display error messages when dealing with negative net values. The fix ensures that the report accurately checks for tax discrepancies, even when balances are negative, preventing misleading error notifications.
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 resolves an issue where Jofotara was rejecting invoices due to extremely small negative discount amounts. The change ensures that discount amounts are always non-negative by applying an absolute value function, preventing errors and ensuring proper invoice processing with Jofotara.
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#265159This update resolves an error that occurred when users removed the date field in the Accrued Expense Entry wizard. The fix adds a check to ensure the date field has a valid value before performing comparisons, preventing a type error. This ensures the wizard functions correctly when users adjust date information.
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#262568This update fixes an issue where re-invoiced expenses on sales orders incorrectly displayed the total expense amount as the unit price. The fix ensures the quantity of the expense is properly reflected on the sales order line, accurately calculating the cost. This improves the accuracy of sales order pricing.
Original PR description
Currently, when re-invoicing an expense paid by company, the line added to the sale order will show a price unit equal to the whole expense amount. Steps to reproduce: - Create a new Expense Category with Re-Invoice Costs set to 'At cost' - Create a new Expense, set the new category, and set Paid By to 'Company' - Set Quantity to greater than 1, and Customer to Re-Invoice to any Sales Order - Confirm and Submit Journal Entry on the Expense record Issue: - On the linked Sales Order you will see the total of the expense is used as the unit price This occurs because we don't pass the quantity to the move line creation vals, which then default to 1. In turn, when the sale order line is added, the unit price will be based on the move line vals but the quantity will match the expense. opw-5883290 Forward-Port-Of: odoo/odoo#246816
A recent update to the l10n_be_coda module incorrectly commented out a test instead of updating it. This fix ensures that the test runs properly, maintaining the functionality of the Belgian accounting integration. This resolves a minor issue that could have prevented test execution.
Original PR description
Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef task-none Forward-Port-Of: odoo/enterprise#117924
This update corrects a translation error in the Odoo Enterprise Gantt view. The button used to toggle display modes was not properly translated, preventing users from seeing the view in their preferred language. This fix ensures all users can access and understand the Gantt view's settings.
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 two issues related to sending deliveries via eTransport in Romania. Specifically, it corrects errors when transporting goods across national borders and when invalid eTransport tokens are used. Instead of displaying tracebacks, the system now provides clear validation messages within the delivery document.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747This update fixes a visual issue where the background color of selected table cells wasn't accurately displayed in the toolbar. The changes include a new system to calculate and show cell background colors, ensuring consistent and correct color representation when selecting table cells, even when empty cells are involved.
Original PR description
Before this commit: the background color of selected table cells isn't shown in the toolbar. After this commit: we have a background color processor in the table plugin to calculate the background color of selected cells. The color and background color are also properly reset to update the selected color when selecting an empty table cell. table_selectionchange_handlers is created to make sure the selected color is updated after it. task-5976046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263088 Forward-Port-Of: odoo/odoo#252011
This update fixes a translation issue within the HTML editor's move tooltip functionality. The fix ensures that tooltips are correctly translated for all users, resolving a previous display problem. It also includes a security enhancement to prevent potential cross-site scripting vulnerabilities.
Original PR description
Currently the move tooltip in the HTML editor is not translated because the exporter can't see `_t()` calls in tagged template literal. This commit fixes the issue by moving the call outside of the template literal. Forward-Port-Of: odoo/odoo#265991