Thursday, May 21, 2026
7 changes · saas-18.2
Resolved issues and error corrections
The Polish e-invoice template now uses the bank account currency in the account description field instead of the invoice currency. This prevents incorrect currency information from being sent to KSeF when an invoice and the recipient's bank account use different currencies.
Original PR description
**STEP TO REPRODUCE** 1. Create a partner with a bank account and setup its currency. 2. Create an invoice using a different currency. 3. Send the invoice to Ksef. 4. Notice the generated xml contains the invoice currency in the field OpisRachunku, but it should be the bank account currency instead. opw-6150563 Forward-Port-Of: odoo/odoo#263842
Polish KSeF FA(3) invoice exports now include the customer reference entered on the invoice. This helps businesses keep their e-invoice records aligned with customer purchase references and reduces manual reconciliation work.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice and fill the customer reference field (other info tab). 2. send the invoice to ksef. 3. Open the generated fa3 file, and notice there is no mention of the customer reference. Ticket [link](https://www.odoo.com/odoo/project.task/6150812) opw-6150812 Forward-Port-Of: odoo/odoo#263797
Printed invoices now avoid showing tiny extra decimal amounts for very large prices, such as displaying 528,000,000.000001 instead of the intended amount. This improves the accuracy and professionalism of customer-facing PDF documents.
Original PR description
Issue: - Create an invoice with a line having a price of `528,000,000.00` - Print the invoice -> pdf displays `528,000,000.000001` Cause: In `value_to_html` from `ir.qweb.field.float`, we compute the maximum precision that we can get from the value, to avoid parasite digits. The maximum is 15, so if a number has 11 digits, we won't ask for a precision higher than 4. But in `float_round`, they multiple the value with its precision, then add `epsilon` (a small value). So we're now working with a 16 digits float, which is what we want to avoid. Solution: Reduce the maximum precision from one digit before calling `float_round`. opw-6012129 Forward-Port-Of: odoo/odoo#260955
This fixes an internal Time Off test that could fail around midnight because dates were interpreted differently across time zones. The change makes the test use a clear start date, improving reliability of automated checks without changing user-facing behavior.
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#265703This update resolves an issue where users could trigger an error when entering spaces in the 'Forecasted Demand' or 'Forecasted Stock' cells within the Master Production Schedule. The fix ensures that blank input is handled correctly, preventing the error and maintaining data integrity.
Original PR description
## Steps to Reproduce:
1. Install `mrp_mps` module.
2. Manufacturing > Planning > Master Production Schedule
3. Click on "Forecasted Demand" or "Forecasted Stock" of any product.
4. Click `<SPACE>` and then `<ENTER>`.
## Error:
`ValueError: could not convert string to float: ' '`
## Cause:
When a user enters whitespace(' ') in a **Forecasted Demand** or **Forecasted Stock** cell, the string bypasses the existing `isNaN/empty` checks at [1]. Then the raw whitespace string passes to the ORM call, where `float(' ')` raised a ValueError.
## Fix:
This commit trims the value so that blank input is treated the same as an empty string, and the cell reverts to its original value.
[1] - https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/mrp_mps/static/src/components/line.js#L128
sentry-7473062917
Forward-Port-Of: odoo/enterprise#117052A previous issue prevented users from creating new helpdesk teams due to an error when the system attempted to use a missing email template. This update ensures the template exists before attempting to use it, resolving the error and allowing teams to be created successfully. This improves the usability of the Helpdesk module.
Original PR description
Currently, an error occurs when a user tries to create a helpdesk team record. **Steps to Reproduce:** - Install the `helpdesk` module without demo data. - Go to `Settings` > `Technical` > `Email` >…
Currently, an error occurs when a user tries to create a helpdesk team record. **Steps to Reproduce:** - Install the `helpdesk` module without demo data. - Go to `Settings` > `Technical` > `Email` > `Email Templates` and delete the `Helpdesk: Ticket Received` template record. - Go to `Helpdesk` > `Configuration` > `Stages` and remove all records. - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams` and click `New` to create a record. `AttributeError: 'NoneType' object has no attribute 'id'` When the user deletes all stages, the system attempts to create a new stage and assign the "Helpdesk: Ticket Received" mail template to it [1]. However, if this template record does not exist, accessing its id raises the error. This commit ensures that the template record exists before accessing its id, otherwise, None is passed as the default value. [1]: https://github.com/odoo/enterprise/blob/32187f79fb0a595497a5e77db4b22b417b03b8dd/helpdesk/models/helpdesk_team.py#L34 sentry-7482994877 Forward-Port-Of: odoo/enterprise#117446
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. By moving the compression step, the download process is now stable and 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/enterprise#117931 Forward-Port-Of: odoo/enterprise#117756