Daily updates from Odoo
Thursday, January 22, 2026
115 changes
5 changes
Resolved issues and error corrections
This update resolves an issue where work orders were generating errors due to incorrect data handling. The fix ensures that employee IDs are correctly processed, preventing duplicate key errors and ensuring work orders function as expected. This improves the reliability of the work order management process.
Original PR description
The previous loop used `employee.id` as the key, which is undefined in this context because values come from resIds and represent record IDs directly. Steps to reproduce: - Enable work orders - Create a BOM with a work order - Configure 2 Assigned employees - Open the work order in Shop Floor An error is raised because, since `employee` is an integer (the ID), `employee.id` is undefined so odoo founds duplicate keys (all undefined). opw-5417887 Forward-Port-Of: odoo/enterprise#102510
This update fixes an issue where refund and payment batches weren't always merging correctly, leading to duplicate payment records. The change ensures that inbound and outbound payments for the same partner and bank are combined into a single payment, streamlining financial reporting. This improves accuracy and reduces manual effort.
Original PR description
When we register payments for a list of journal entries, the `account.payment.register` wizard computes batches and sometimes merge them together. For instance, this allows to create a single payment if there is an outbound (a bill to pay) and an inbound (a refund to receive) payment to the same bank for the same partner. Instead of creating two payments of -1000 and +500, we only create one of -500. Currently, this mechanism does not always work. That's because the `batch_key` used to decide whether to merge or not refers to a value that is not updated in the loop. Related ticket: opw-5401372 Forward-Port-Of: odoo/odoo#242863
This update fixes an issue where the floating order name displayed during direct sales in the restaurant POS was incorrectly showing the POS reference instead of the tracking number. Now, the order name accurately reflects the tracking number, ensuring accurate order identification and management for restaurant staff. This improves order clarity and efficiency.
Original PR description
Before this commit, when making a direct sale, the floating order name was the pos reference instead of the tracking number. This is now fixed. task-id: 5470874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242359
This update resolves an issue where a deleted floor would reappear in the floor selector after a refund was processed on a related order. The fix filters out inactive floors, ensuring the floor selector only shows active tables. This improves the user experience and data accuracy within the restaurant point-of-sale system.
Original PR description
Task: [#5421683](https://www.odoo.com/odoo/project/1737/tasks/5421683) --- !!!! WARNING !!!! The bug is no longer reproductible since the refacto of the floor plan. --> PR [https://github.com/odoo/odoo/pull/239681](https://github.com/odoo/odoo/pull/239681) I just kept the tour test for good measure. --- **Steps to reproduce:** * Create a new floor with one table * Create and pay an order on that table * Delete the floor * Refund one line of the order ==> The deleted floor is shown again in the floor selector, without its table. This happens because the deleted floor is loaded when fetching the table of the order in the Ticket Screen. If an order is linked to a table that belonged to a deleted floor, that floor is loaded again and displayed in the floor selector. **Fix:** Filter out inactive floors from the floor selector. Forward-Port-Of: odoo/odoo#240276
This update resolves an issue preventing non-administrator website editors from saving images they upload from Unsplash. The fix ensures the user creating the attachment has the necessary permissions, eliminating a security warning and improving the editor's functionality. This allows website editors to seamlessly integrate Unsplash images into their designs.
Original PR description
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in…
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in a view - Replace the image with an unsplash image and then save Result: the save fails without any message shown, and there is a security access WARNING in the logs. Note: a similar scenario can be done for a restricted editor that is editing a HTML field it has write access to. Issue: to save a model with res_id 0, we need to either be admin (base.group_system) or the record creator. Since 9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype neutering of happening, we create the attachment as SUPERUSER. Then when we modify the attachment url (for unsplash images), we have no access right to the attachment since we are not the creator. Fix: create the attachment with the current user, and only use SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't have write access right to ir.ui.view, which in normal use case should only happen for "Restricted Editor"). This way the image is created by the user that uploaded it and not SUPERUSER. opw-4850611 opw-5387258 opw-5489219 Forward-Port-Of: odoo/odoo#245085 Forward-Port-Of: odoo/odoo#219472
1 change
Resolved issues and error corrections
This update resolves an issue where the 'Pending' button in the manufacturing order workflow incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the employee actively working on the operation is impacted, improving workflow efficiency and preventing unnecessary resource allocation.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#103853
Forward-Port-Of: odoo/enterprise#1035532 changes
Resolved issues and error corrections
This update resolves an issue where the 'Pending' button in the manufacturing order process incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the productivity record associated with the currently logged-in employee is stopped when the 'Pending' button is clicked, improving workflow efficiency.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#103853
Forward-Port-Of: odoo/enterprise#103553This update fixes an issue where refund and bill payments for the same bank and partner weren't always combined into a single payment. The change ensures that outbound (bills) and inbound (refunds) payments to the same bank and partner are automatically consolidated, reducing the number of payments created and simplifying accounting processes. This improves efficiency and accuracy.
Original PR description
When we register payments for a list of journal entries, the `account.payment.register` wizard computes batches and sometimes merge them together. For instance, this allows to create a single payment if there is an outbound (a bill to pay) and an inbound (a refund to receive) payment to the same bank for the same partner. Instead of creating two payments of -1000 and +500, we only create one of -500. Currently, this mechanism does not always work. That's because the `batch_key` used to decide whether to merge or not refers to a value that is not updated in the loop. Related ticket: opw-5401372 Forward-Port-Of: odoo/odoo#242863
1 change
Resolved issues and error corrections
This update fixes an issue where embedded actions within folders were hidden from the interface, preventing users from managing or deleting them. The change ensures that embedded actions remain visible and accessible through the folder's action list, streamlining the user experience and allowing for proper management of related actions.
Original PR description
### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881 Forward-Port-Of: odoo/enterprise#100395
1 change
Miscellaneous changes
This pull request represents the initial stages of work within the Odoo Enterprise project. It includes preliminary changes and requires further refinement and testing. The goal is to implement new features and improvements to enhance the core functionality of the platform.
Original PR description
Pending message
2 changes
Resolved issues and error corrections
This update fixes an issue where Swiss payslips generated from payruns were named 'new payslip' instead of including the employee's name and pay period. The change ensures that PDF payslips now accurately display the employee's name and the relevant time period, improving clarity and compliance for Swiss payroll reporting.
Original PR description
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of…
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>" ## Reproduction Steps 1. Install the app l10n_ch_hr_payroll. 2. Make sure you use a Swiss company. 3. Go to Payroll and click on the Payslips tab > payslips. 4. Click on Pay Run. Select Switzerland: ELM salaries and click Continue. 5. Select an employee for which you'd like to generate the payslip. 6. Click on the employee row in the list view. 7. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - <employee name> - <time period>" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5253811
This update fixes an issue where test bank statement imports would create records in the database even after failing. The change ensures that test imports don't trigger reconciliation processes, preventing unintended data creation. This improves the reliability of test data and simplifies troubleshooting.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard 1) - On "Bank" journal card, select "Import File" option in dropdown menu - Upload a file containing a lot of statements…
**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard
1) - On "Bank" journal card, select "Import File" option in dropdown menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
2) - Open "Bank" journal
- Select "Import records" in the cog menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
3) - Open "Bank" journal
- Click on "Upload" button
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.
**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.
**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).
opw-54369373 changes
Resolved issues and error corrections
This update corrects a bug that caused the kitchen printer to print blank tickets when using the self-ordering kiosk feature in Restaurant mode. The fix ensures that the printer only prints when order lines are present, aligning with the expected behavior of the system. This prevents unnecessary printing and potential confusion for staff.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer)
This update resolves a potential infinite loop issue that could occur when generating product combinations, specifically with multi-checkbox attributes. The fix ensures that product lines without values are excluded, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a minor issue in the way Odoo transmits ELM (Employers’ Ledger and Monetary Summary) data for Swiss payroll. The change ensures that a snapshot is only created if one doesn't already exist, optimizing the process and preventing unnecessary data duplication. This improves efficiency and reduces potential processing delays.