Thursday, May 21, 2026
14 changes · 19.0
Resolved issues and error corrections
The Polish e-invoicing template now uses the bank account currency in the account description instead of incorrectly using the invoice currency. This helps ensure invoices sent to KSeF contain accurate payment account information when invoice and bank currencies differ.
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
The IoT connection handling now ignores expected request cancellations instead of treating them as connection failures. This prevents unnecessary fallback behavior when a new listener is added, improving connection stability for IoT services.
Original PR description
In odoo/odoo#260931, new logic was added to raise an 'unreachable' error in the case where a longpolling listen request failed. This error was then used by the IoT HTTP service to fallback to a websocket listener. However, due to an oversight this 'unreachable' error was also being triggered whenever the longpolling listen request was aborted, which happens whenever a new listener is added. This commit fixes the issue by checking the error type and only sending the 'unreachable' error if the request was not aborted. opw-6175686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Imported Peppol vendor bill XML files are now included in the bill's chatter, not just stored as hidden attachments. This makes it easier for accounting users to find and review the original electronic invoice from the normal document history.
Original PR description
**Steps to reproduce:** 1) Install l10n_be and configure Peppol demo mode. 2) Open debug mode, search for 'Peppol: retrieve new documents' in scheduled action. 3) Open the generated vendor draft bill. 4) Observe that the imported XML is present in attachments but not in chatter. **Cause:** In the (`_import_ubl_invoice_post_processing()`) https://github.com/odoo/odoo/blob/27cc9b920ad6818563b471dd3391548913790ef3/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L3344 chatter attachments were built from: `self._import_attachments(invoice, collected_values['tree'])` This only includes embedded extra documents and emits the source imported XML attachment. As a result, the XML remained stored on the move (ubl_cii_xml_file) but was not linked to the chatter message. **Solution:** Include the source attachment when building the chatter attachment set. opw-6197738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Polish electronic invoice exports now include the customer reference entered on the invoice. This helps businesses keep KSeF submissions aligned with their internal and customer-facing invoice references.
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
The user rights popover now scrolls when its content is too tall, preventing information from overflowing outside the visible area. This makes permission settings easier to review and use, especially when many options are shown.
Original PR description
This PR adds the `overflow-auto` class to the popover component to enable scrolling and prevent content overflow. **Task-ID: 6137031**
Product detail sections on ecommerce pages now blend with the selected website background instead of forcing a white block. This improves the visual consistency of shops using custom background images or colors.
Original PR description
When a background is set on the website, we can't remove the background of the product information card making the design unaesthetic Steps to reproduce: 1. Install eCommerce 2. Go to Website and click on Edit in the top right corner 3. Open the "Theme" tab, set an image (not plain white) to the website's background and save 4. Go to the shop and open any product 5. The product details are shown on a white block that disrupts the background image Issue: We set a background-color on `#product_details` with value `$body-bg` which is an opaque white Solution: Remove the white background of `#product_details` opw-6214514
Fixed an issue where restaurant kitchen notifications could show incorrect item names when using languages such as French. This ensures staff see accurate preparation summaries when sending orders to the kitchen.
Original PR description
Steps to reproduce: ------------------- 1. Set the user language to French. 2. Configure a preparation display. 3. In PoS, add 2 products of different categories (e.g. 2 starter and 1 main) 4. Send to kitchen -> Toast shows "2 starter et 1 €, envoyé à la cuisine" instead of "2 starter et 1 main, envoyé à la cuisine". What's happening: ----------------- The summary is built with a regex that uses `$1` to replace the ", <last_item>" with an "and <last_item>", however, this `$1` in languages other than english is being translated, in our case to `1€`, and the regex replacement logic does not work properly anymore. The fix: -------- Use `formatList` to join the items, it uses the user language to apply locale-specific joining rules. opw-6149616
This update corrects a visual issue where the project sharing notebook was using dark styles, causing a conflict with the light mode theme. The team removed a specific style file to ensure consistent appearance across all Odoo Enterprise environments.
Original PR description
The project sharing notebook previously used dark-themed styles, which conflicted with the light mode .Removing the notebook.dark.scss file from the imported files in the manifest. task-4922564
This update fixes a visual issue where the bottom rows of the Profit & Loss report were clipped when the screen was resized. The fix adjusts the report's wrapper height to ensure all data is visible, regardless of screen size. This improves the user experience for all users accessing this report.
Original PR description
Steps to reproduce: ------------------- 1. Go to Accounting > Reporting > Profit and Loss. 2. Resize the window so the report doesn't fit vertically. 3. Scroll to the bottom Observation: the last…
Steps to reproduce: ------------------- 1. Go to Accounting > Reporting > Profit and Loss. 2. Resize the window so the report doesn't fit vertically. 3. Scroll to the bottom Observation: the last rows are not reachable!! Why this happens: ----------------- The report content is inside a wrapper that has `height: 100%`, so the wrapper takes the full height of its parent. But the wrapper is placed below the action bar, so we end up with a wrapper taller than the space it actually has. Example: the parent is 700px and the action bar is 100px. The wrapper still get 700px which is the parent height, but it starts below the action bar, so its bottom 100px is below the visible area. The rows in this 100px are not reachable. The fix: -------- Set `min-height: 0` on the wrapper. This way it can shrink and take only the available space, not the full parent height (In our example, the wrapper height will now be 600px, so with the action bar, it adds up to 700px, the height of the parent). Before (at full scroll): "Net Income" clipped <img width="1309" height="990" alt="image" src="https://github.com/user-attachments/assets/e1b6bfd6-a6dd-4b73-8a27-a49c8dca03de" /> After (at full scroll): <img width="1310" height="991" alt="image" src="https://github.com/user-attachments/assets/e17fc283-e3c8-455d-85cd-dacdd1fc9537" /> opw-6173522
This update corrects a bug where users could trigger an error when entering spaces in the 'Forecasted Demand' or 'Forecasted Stock' fields within the MRP planning module. The fix ensures that blank input is handled correctly, preventing the error and maintaining data integrity. This improves the user experience and prevents potential data issues.
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#117052This update fixes an error that previously prevented users from creating new helpdesk teams. The issue occurred when the system attempted to use a default email template after clearing all helpdesk stages. The fix ensures the template exists before attempting to use it, preventing a 'NoneType' error and ensuring team creation functionality.
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
This update corrects a bug where certain test types were incorrectly visible during quality control setup. The change addresses an optimization in Odoo's database queries that inadvertently allowed these test types to be displayed. This ensures that only relevant manufacturing control types are available, improving data accuracy.
Original PR description
### Issue: The `Print Label`, `Register Production`, `Register By-products`and `Register Consumed Materials` are all available in the test types at control point creation. ### Expected behavior:…
### Issue:
The `Print Label`, `Register Production`, `Register By-products`and `Register Consumed Materials` are all available in the test types at control point creation.
### Expected behavior:
These test types are only meant for manufacturing operations and are supposed to be hidden by the field domain:
https://github.com/odoo/enterprise/blob/f56aa85b4ad32c5d9ad5593df1366d72e88da0e4/mrp_workorder/models/quality.py#L102-L104 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24
### Cause of the issue:
Since saas-18.1: 5ef007a2116e528b796ebe80fb291ba5f1a94c8f domains are optimised into equivalents SQL clause with better sql performances. This optimization results in the following match for boolean fields:
`('field', '=', True)` -> `('field', 'in', OrderedSet([True]))`
`('field', '=', False)` -> `('field', ' not in', OrderedSet([True]))`
Because of these:
https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1058-L1079 https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1215-L1236
Now the issue is that the specific `search_method` of the `allow_registration` field is then called with this optimized domain: https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L860-L866 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24
And since `value` is defined as a non empty ordered set in both cases it the search method returns a True leaf as search domain.
opw-5915197
Forward-Port-Of: odoo/enterprise#117068This update resolves an issue preventing normal users from canceling approval requests they created. The fix utilizes 'sudo' to grant the correct permissions, allowing users to successfully cancel their own approvals and streamlining the workflow.
Original PR description
Issue: - A user who created an approval request could cancel it. But a rights error appeared during the cancellation. Steps to Reproduce: - Create an approval being a normal user. - Try to cancel the approval. - A ValidationError is raised eventhough the approvals can be cancelled by creator of it. Fix: - Changed the cancel action to use the sudo for the user who created the task and can cancel it Impact: - Users can cancel their own approval requests without errors. Task: 6123104 Forward-Port-Of: odoo/enterprise#114189
This update fixes a bug where calls were not accurately reflecting the number of open tickets associated with their parent partners. Previously, open tickets on child partners weren't counted. Now, all open tickets linked to a call's parent partner are correctly displayed, providing a more complete view of support requests.
Original PR description
Unlike most of *_count fields on res.partner, for example ticket_count, open_ticket_count didn't take into account of its child partners. To reproduce: 1. create parent parent P and child partner C 2. create a ticket for partner C and put it in a unfold stage 3. call partner P and open form view of this call the open ticket count on the smart button is 0 instead of 1 In this commit, we change it that when a child partner has open tickets, they will also be counted as parent partner's.