Daily updates from Odoo
Thursday, May 21, 2026
14 changes · 19.0
Enhancements to existing features
This update improves the configuration for GT Electronic Data Interchange (EDI) branches. Specifically, VAT information is no longer inherited, while key credentials for the EDI connection are now consistently managed. Additionally, configuration settings are now properly displayed for these branches, ensuring accurate setup and operation.
Original PR description
While creating branches for GT country, VAT shouldn't be inherited, while Infile credentials (l10n_gt_edi_ws_prefix, l10n_gt_edi_infile_token, l10n_gt_edi_infile_key) should. At the same time, config keys should also appear for branches on settings task-[6087168](https://www.odoo.com/odoo/project/967/tasks/6087168)
This update enables users to reset statement lines directly within the Kanban view, mirroring functionality from previous versions. Previously, resetting required deleting individual reconciliations, which was inefficient for users with many transactions on a single line. This change streamlines the process and improves usability.
Original PR description
This commit adds the possibility to reset a statement line in kanban view like in the previous versions. Function is still there but no UI button was tied to it. This is a problem if you have many reconciliations on one statement line, we do not want to delete them one by one. opw-6015838 Forward-Port-Of: odoo/enterprise#111107
Resolved issues and error corrections
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 corrects a bug in the German Point of Sale (POS) module that was caused by recent accounting changes. Specifically, a calculation error related to change amounts was fixed to ensure accurate payment processing, particularly when the change is negative. This ensures correct cash payment type handling for remaining order amounts.
Original PR description
Since the refactoring of the accounting in the pos, the change getter on the pos is returning a value different from 0 if the change is bigger than 0. If it is smaller, it returns 0 and remainingDue should be used to know the remaining due of an order. In l10n_de_pos_cert, the change was checked in _createAmountPerPaymentTypeArray to enter an if. In javascript, a negative value in an if statement is truthy so when the change was negative, the code entered the if statement which is not the case anymore. We add an if with the remainingDue to add the remaining due as a cash payment type if there is still an amount due runbot-error: 241251
This 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 fixes an issue where the End Balance columns in the Romanian Trial Balance reports were displaying incorrect totals when the report hierarchy was enabled. The fix eliminates double-counting of account groups, ensuring accurate financial reporting and consistency across all trial balance reports.
Original PR description
### Issue before this commit: The total row for the End Balance columns in the Romanian 4-column and 5-column Trial Balance reports displayed incorrect values when the report hierarchy was enabled. ### Steps to reproduce the issue: 1. Downaload Accounting and l10n_ro 2. Switch to RO company 3. Go to Trial Balance report and be sure that Posted Entries, Accrual Basis are setted on Hierarchy and Subtotals 4. See that the End Blance both debit and credit is not correct ### Cause of the issue: The _custom_line_postprocessor method iterated over all report lines indiscriminately, adding account group subtotals to the running accumulator and causing duplicate counting. ### Reason to introduce the fix: To eliminate group double-counting and providing consistency with the totals in all the trial balances reports. opw-6146200
This update resolves an issue where extremely long invoice references in the general ledger report caused the PDF generation process to fail due to excessive file open operations. By limiting the display name length, we prevent the PDF from becoming overly large and ensure reports generate successfully, even with many batched invoices.
Original PR description
The display name of the account.report.line in the general ledger report has the format of: INVOICE NAME (invoice refs) In the case where a client has hundreds of sales orders batched to a single…
The display name of the account.report.line in the general ledger report has the format of: INVOICE NAME (invoice refs) In the case where a client has hundreds of sales orders batched to a single invoice, the ref can become extremely long, e.g.: INV/2026/00001 (S12123, S12152, S12159, S12140, S12165, S12161, S12162, S12110, S12099, S12124, S12145, S12128, S12114, S12131, S12097, S12185, S12154, S12133, S12190, S12118, S12116, S12102, S12155, S12153, S12158, S12150, S12100, S12142, S12121, S12122, S12111, S12187, S12172, S12177, S12095, S12117, S12144, S12137, S12092, S12138, S12186, S12182, S12112, S12148, S12183, S12101, S12178, S12119, S12169, S12115, S12146, S12093, S12126, S12160, S12163, S12129, S12098, S12151, S12096, S12174, S12120, S12130, S12147, S12180, S12191, S12164, S12141, S12105, S12136, S12139, S12109, S12106, S12104, S12103, S12175, S12179, S12188, S12113, S12173, S12167, S12171, S12134, S12094, S12184, S12166, S12170, S12125, S12135, S12143, S12176, S12189, S12156, S12181, S12107, S12157, S12132, S12149, S12127, S12108, S12168...) Because the length of the account.report.line is unchecked in account_general_ledger.py label builder, the pdf can clog to one or two account.report.lines per page, skyrocketing the pdf page length. As wkhtmltopdf processes the report from html to pdf it makes a system call openat() to the /tmp/report.footer.tmp.x.html file for EACH page of the pdf. You can see the TODO comment in the spoolTo function in wkhtmltopdf (both in Odoo and the original repo) saying that the header and footer need to be freed, on each page processing, not just null pointed. https://github.com/odoo/wkhtmltopdf/blob/2c884bd1545b8a639847de22f24754ee5a6fc44c/src/lib/pdfconverter.cc#L794 I verified that that the number of openat calls to the /tmp/report.footer.tmp.x.html file equals the exact number of pages in the pdf to be generated if the report HAD generated successfully by setting the footer input into _run_wkhtmltopdf to None, generating the report without footers, then separately running an strace on wkhtmltopdf when the report fails to generate. See related ticket linked at bottom. The linux machine used on sh instances has a ulimit -n of 1024 file descriptors. Because the footer file descriptors accumulate, once a pdf has about 1010+ pages (~a dozen fd's are allocated for other purposes), over 1024 file descriptors are opened and the system fails with: Wkhtmltopdf failed (error code: -6). Message: QEventDispatcherUNIXPrivate(): Unable to create thread pipe: Too many open files QEventDispatcherUNIXPrivate(): Can not continue without a thread pipe Since wkhtmltopdf is archived and Odoo has a replacement in development, I suggest that we limit the display_name of the account.report.line to 200 to keep the bloat minimized, preventing one account.report.line's name from taking up an entire page of the general ledger pdf. This allows many more batched invoices to be shown in the report and a much greater time range of data to be printed without hitting the fd limit. I suggest changing it at the general ledger report level rather than in the account.move.line _compute_display_name function, as we probably still want to see the full display_names at the invoice level. On runbot, the machine has different memory constraints than on sh / local, so it hits the following error before the one above: Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum file number of subprocess reached. Message : 1. newdb -n test_gl -v 19.0 2. ensure ulimit is set to 1024 in shell that runs odoo instance by running ulimit -n 1024 to mimic ulimit of sh environment 3. run db with python3 odoo-bin, ensuring high enough memory constraints to simulate multi worker sh instance, i.e. --limit-memory-soft=12884901888 --limit-memory-hard=1288490188 4. install sales, accounting, stock 5. install demo data 6. create invoices with 100+ associated sales orders 7. generate the pdf 8. Increase the amount of invoices till the general ledger page count hits ~1010+, where you will hit the error. opw-ticket-6201508 closes #
This update resolves an issue where the delivered quantity for dropship products was incorrectly set to 1 in certain sales order scenarios. The fix ensures that the delivered quantity accurately reflects stock pickings and confirms the correct quantity is calculated upon purchase order confirmation. This improves the accuracy of dropship order fulfillment.
Original PR description
### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the…
### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the related task > Products > Add 1 unit of P - Go back to the sale order > an RFQ has been created #### > The delivered quantity of P is set to 1 ### Cause of the issue: Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83 provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237 The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198 Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute). Fix: The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167 opw-6104326 Forward-Port-Of: odoo/enterprise#115760
This 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 addresses a client issue where printing failed when the LNA (Local Network Automation) feature wasn't available. The fix involved correcting a missing key check in the printing process, ensuring reliable printing functionality regardless of LNA status. This resolves a reported problem impacting printing operations.
Original PR description
Based on the ticket below the client is experiencing an issue when printing without LNA. This PR fixes the missing key check opw-https://www.odoo.com/odoo/project/49/tasks/6232008
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.