Daily updates from Odoo
Wednesday, December 10, 2025
25 changes · 18.0
Resolved issues and error corrections
This update fixes an issue where multiple quality checks were being created for the same receiving operation, leading to inefficiencies. The change adds a validation step to ensure only one quality check is generated per operation, streamlining the receiving process and reducing potential errors. This improves data accuracy and operational efficiency.
Original PR description
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations…
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations field). 3. Create a Receipt containing one product. 4. Click the Mark as To Do button. 5. Add another product to the same Receipt and save it. Observation: -------------------------- Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation. Issue: -------------------------- No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation. Solution: -------------------------- Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created. opw-5249233 Forward-Port-Of: odoo/enterprise#100118
This update enhances the stability of the Account EDI client by preventing automatic deletion of connections when the IAP API returns an error indicating a user no longer exists. This resolves past incidents caused by IAP issues, ensuring smoother operation and reducing potential disruptions to account processing.
Original PR description
We already have had multiple IAP-side incidents leading to IAP API returning `no_such_user`. This error code should not lead to user deletion client-side. Thus this commit addresses this by avoiding to archive long-standing IAP connections even when `no_such_user` error is received. Forward-Port-Of: odoo/odoo#234073
This update fixes an issue where invoice reports in the KE (Kenya) localization module were not correctly formatting the total and taxable amounts with commas. The fix removes a duplicate XPath and applies proper formatting options, ensuring invoices display prices accurately for KE customers. This improves clarity and compliance for financial reporting.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578 Forward-Port-Of: odoo/enterprise#100279
This update fixes an issue where the order partner wasn't being correctly updated in the backend after scanning the online payment QR code. Previously, changes to the partner were not reflected in the order details. Now, the system accurately records the updated partner, ensuring accurate transaction tracking.
Original PR description
# Steps to Reproduce 1. Configure a payment method as **Online Payment**. 2. Select a customer and proceed to pay the order. 3. The QR code for online payment is generated. 4. Note: the partner is correctly loaded in the backend. 5. Close the QR popup and change the partner. 6. Scan the QR again and proceed to pay. # Expected Behavior - The transaction should reflect the updated partner, not the previous one. # Actual Behavior - The transaction is recorded under the previous partner. - The partner is not updated in the order. # Issue - Updating the partner does not immediately update the order in the backend from the POS UI. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the QR code popup for online payments was displaying an incorrect order reference (showing a forward slash instead of the actual order name). This change ensures that customers receive accurate order information when making payments via QR code, improving the payment process. The fix was implemented as part of the Odoo 18.0 release.
Original PR description
When using the `POS Online Payment` method, the QR popup was displaying an incorrect order reference (e.g., `/`) instead of the actual order name. Steps to reproduce: 1. Activate a payment method for a `Point of Sale` and set it as `POS Online Payment`. 2. Create an order in the POS and select the configured payment method. 3. When the QR popup appears, the amount is correct but the order name shows `/` instead of the real reference. This fix ensures the correct order name is displayed in the QR popup. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where downpayment invoices weren't correctly reflected in the 'Un-invoiced Balance' calculation within the sales quotation. The fix ensures that downpayments are now accurately considered when determining the amount still outstanding, improving invoice accuracy and reporting. This impacts how sales balances are tracked.
Original PR description
#### Versions: 18.0+ ### Issue: Sales' uninvoiced balance (`amount_to_invoice`) is not updated with downpayments. #### Steps to reproduce: Requires Studio - Enter the Sales app: - Change the list view with Studio: - Add the field `Un-invoiced Balance` (amount_to_invoice) as a new column. - Create a new quotation with a product having the `Ordered quantities` invoicing policy; - Confirm the quote; - Create and confirm a downpayment invoice based on fixed amount; - Go back to the quotation list view: - The "Un-invoiced Balance" field is not updated and still shows the total amount of the quotation. ### Cause: Downpayments have no quantity, so they are not considered in the computation of the uninvoiced balance as they are set to 0 in the method `_compute_amount_to_invoice`: https://github.com/odoo/odoo/blob/70d16283b58ab8f379279de54de81bdb680e0887/addons/sale/models/sale_order_line.py#L1146 opw-5274918
This update fixes an issue where the number of reconciliation entries displayed on the dashboard was incorrect. The system was filtering out draft journal entries, which could be reconciled. Now, all entries, including draft ones, are accurately counted, ensuring users see the correct number of reconciliations available.
Original PR description
Steps to reproduce: - go to daschboard > N to reconcile - validate the first entry - back to dashboard you will N-1 to reconcile - Reset to to draft the journal entry associated with the reconciliation - Reset the bank reconciliation Issue Back to the dashboard you will see N-1 to reconcile but when clicking on it you will have 8 entries to reconcile Cause: We filter out non posted entries. In Odoo, draft entrie can be reconciled. opw-5102016
A minor bug in the HTML editor's testing process was causing intermittent test failures. This update refined the test's targeting to avoid false positives related to the toolbar, ensuring consistent and reliable test results. This improves the overall stability of the HTML editor module.
Original PR description
Because of the toolbar being sometimes opened, the test added in odoo#238735 would sometimes failed. This was due to the selector "span" also targetting the elements in the toolbar. To prevent this test from failing, the selector "span" was updated to be more specific.
This update fixes a problem where blog post publication times were inconsistent during performance tests. The change ensures that tests always produce the same results by freezing time during initial data retrieval, preventing variations in post publication timing. This improves the reliability of our blog performance metrics.
Original PR description
Some blog post are published with a post_date matching the time the test is run meaning that they are not considered published. We have multiple possibilities when _get_url_hot_query is called: - all call to /blog are executed before the publication date: 9 - some call to /blog are executed after the publication date: 11 - only the last call is executed after the publication date: ~40-50 Using freezetime after the publication date ensures a consistent result This can be easily reproduced by freezing the time on the first calls in _get_url_hot_query and not on the last one. Runbot error [55754](https://runbot.odoo.com/odoo/error/55754) Forward-Port-Of: odoo/odoo#239236
This update ensures that users' presence status is accurately reflected after returning from periods of inactivity. Previously, updates were missed if the user hadn't been away during the last status check. This fix guarantees consistent and reliable presence information for users.
Original PR description
Before this commit, the user's presence might not be updated after returning from inactivity. This occurs because the status service only sends an update if the user was away during the previous update. However, this condition doesn't account for cases where the update was never sent. Forward-Port-Of: odoo/odoo#239202
This update corrects a technical issue related to the transmission of Swiss payroll data (ELM). Specifically, it adds a necessary group to the teleworking field in the HR contract and employee models. This ensures accurate reporting to Swiss tax authorities, complying with local regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#101691
This update resolves an issue where scanning a lot in a batch transfer incorrectly updated line quantities. Specifically, when a subline without a lot was scanned, it was incorrectly updating a completed line instead of the intended subline. This change ensures accurate lot tracking and quantity updates during barcode scanning processes.
Original PR description
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create…
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create a storable product tracked by lots and put 10 x lot1 in stock - Create and confirm a delivery for 10 units - Create a batch transfer with your delivery - Process your transfer from the barcode app - Scan one unit of LOT1 and put in pack - Toggle sublines select the 0/9 subline without lots nor package - Scan LOT1 #### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9 ### Cause of the issue: Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot. opw-5340865
This update fixes a problem where payments weren't always being linked to the correct bank account, specifically for tax payments. The change ensures that payments are accurately associated with the intended recipient's bank account, preventing financial discrepancies and improving payment processing reliability. This resolves an issue that could have resulted in incorrect financial records.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Avoid payment wrong initialization when a default value has been set to initialize the `account.payment.register`. Indeed, the `account.payment` also has a `partner_bank_id` property, and so the method `_create_payment`of the `account.payment.register` can initialize payment with wrong `partner_bank_id`. [enterprise#99373](https://github.com/odoo/enterprise/pull/99373) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220)
This update fixes an issue where payroll payments were incorrectly linked to the employee's bank account instead of the correct vendor account (like the IRS). The change ensures payments are accurately assigned to the appropriate bank account, resolving a payment processing error and improving financial accuracy. Automated tests have been added to verify this fix.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`. Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. ## Tests Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error. This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment. [community#235475](https://github.com/odoo/odoo/pull/235475) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220)
This update resolves issues where changes to cover images in nested cards were incorrectly applied to other cards, or where settings leaked between parent and child cards. The fix ensures that image adjustments are now isolated to the specific card being edited, improving the editing experience and preventing unexpected behavior.
Original PR description
This commit fixes three issues occurring when editing nested `s_card` snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover image…
This commit fixes three issues occurring when editing nested `s_card` snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover image option if it contained a child `s_card` with a cover image. Cause: The `querySelector` in `CardImageOption` could detect images inside child snippets. Fix: Now the `querySelector` only searches among direct children of the snippet root element. **Problem 2 - Ratio settings applied to all child cards** Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested cards. Cause: The `we-select` in `s_card` options targeted `.o_card_img_wrapper`, causing the class to apply to all descendants. Fix: The selector is now `>.o_card_img_wrapper`, so the option acts only on the current snippet. **Problem 3 - Parent image positioning leaking to children** Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images. Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements matching `.o_card_img_wrapper`. Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`. task-5349540
This update fixes an issue where mobile invoices incorrectly displayed both purchase and sales taxes. The change copies the tax selection options from the desktop version, ensuring users on mobile devices see the appropriate taxes available for their invoices. This improves the user experience and accuracy of mobile invoicing.
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Create an new invoice - Add an invoice line - Click on the Taxes field => Both purchase and sales taxes are available Solution ======== Copy the domain from the desktop list view https://github.com/odoo/odoo/blob/fcc677e900c2fccb9fa0bd88ef01c559cadfa08a/addons/account/views/account_move_views.xml#L1051-L1055 We also add the corresponding context and options opw-5124536
This update resolves an issue where large product images on the Shop page appeared blurred. The fix ensures product images maintain their original aspect ratio when displayed, providing a consistent and professional look for customers. This improvement enhances the user experience and visual quality of product listings.
Original PR description
Steps to reproduce: =================== 1- Add a product with a very large image width & publish product. 2. Go to the Shop page & type product name. -> The product image is blurred. Cause: ====== The product images have `h-100 w-100` classes which force them to fill the container dimensions exactly, ignoring their intrinsic aspect ratio. Solution: ========= Add the `object-fit-contain` class to the image. This ensures the image scales to fit within the container while preserving its aspect ratio. Side note: `object-fit-contain` class will be added only in version 17.0 In the next versions the class already exists. opw-5258658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238108
This update resolves an issue where data records linked to deleted models remained in the system, potentially causing errors and instability. By cleaning up these records when a model is removed, we ensure data integrity and prevent future problems. This improves overall system reliability.
Original PR description
When a model is unlinked, the `ir.model.data` related to that model wasn't cleaned up. This leaves dangling records that can generate issues. sentry-6938852090 Forward-Port-Of: odoo/odoo#236615
This update resolves an issue where the demo stock data installation incorrectly used US currency, causing problems when existing databases used different currencies (like EUR). The fix ensures the demo data installation works correctly regardless of the company's currency setting, improving data consistency.
Original PR description
Currently in the `_merge_move_itemgetter` the system call `self.company_id.currency_id.decimal_places`. However the demo data of stock create a database with US currency and some `stock.move` in it. If we have an existing database with EUR for example. The upper call will return a `currency_id.decimal_places` since we have multiple currency. The best solution, would be to split `_action_confirm` to do a loop by company. But it would need a small refactoring and we will do a minimal diff to fix this issue. Using the smallest currency among all the company is not always correct but it's a super edge case and we should probably remove this code since it went to far. Close #230965, #234078 Forward-Port-Of: odoo/odoo#239273
This update resolves an issue where SN labels weren't generated and printed correctly when producing multiple units of a product through the manufacturing process. The fix ensures that SN labels are consistently printed for MOs with quantities greater than one, preventing data discrepancies and streamlining production tracking. This improves the accuracy of lot and serial number management.
Original PR description
This commit fixes the issue of not printing Lot/SN labels when generating them on the MO that has more than 1 unit on the quantity to produce. To reproduce the bug: 1- Go to Operation Types → Manufacturing → Hardware → activate the print `Lot/SN Label` (Print When "Create New Lot/SN") 2- Create an MO with quantity of 5 for a tracked product. 3- Click on `Produce All` and use the wizard to generate SNs and produce or confirm the MO. = SNs should be printed but they are not. opw-5347787
This update fixes an issue where users without assigned tasks were not visible in the Gantt view when searching or filtering. The fix simplifies a conditional check within the project task search logic, ensuring the correct user rows are displayed. This improves the usability of the Gantt view for all users.
Original PR description
**Steps to reproduce:** Go to Project Go to All Tasks. Switch to the Gantt view. Search for an assignee who has no tasks assigned. **Cause:** The method was adding multiple conditions for the same field because both if statements were being applied. This made the domain incorrect when searching for users or custom filter on user **Issue:** The searched user’s row did not appear in the gantt view if they had no tasks. **Fix:** Changed the second if to elif so only one condition is applied at a time, ensuring the correct domain is used and the user row is visible. Task-5076701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where assignee rows weren't displayed in the Gantt view when users had no assigned tasks. Now, all users are always visible, and searching by assignee filters results show only unassigned tasks within a specific project, improving usability and reporting accuracy.
Original PR description
**Before this commit:** When searching for an assignee in the gantt view, the corresponding row was not displayed if the user had no tasks assigned. Similarly, when applying a custom filter on the assignee also not working properly. **After this commit:** When searching or filtering by an assignee, the corresponding user row is now always visible in the gantt view, even if the user has no assigned tasks. Custom filters on assignee also work properly. task-5076701
This update removes a restriction on displayed stock quantities in the Odoo Enterprise system. Previously, quantities were limited to sublocations within an operation, but this has been removed to provide users with a more complete view of their stock levels. This change ensures accurate stock tracking and reporting.
Original PR description
In order to fix an issue with stock move line's quants not correctly recomputed, the PR odoo/enterprise#95906 backported a part of 18.2 PR odoo/enterprise#55917. The issue is, this PR also backported unwanted changes, like the restriction of displayed quants. Starting with the 18.2, the displayed quants are restricted to the current operation's sublocations because in this version, clicking on a quant updates the move line's fields. This feature doesn't exist prior to the 18.2 and so, the restriction is not needed. This commit removes this part of the field's compute so users have better visibility of where are their quants. [opw-5357557](https://www.odoo.com/odoo/project.task/5357557)
This update corrects a bug where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly when using unreserved products. The fix prevents multiple validation attempts, ensuring accurate stock tracking and avoiding data inconsistencies. This improves the reliability of transfer processing.
Original PR description
**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696
Forward-Port-Of: odoo/enterprise#95329This update fixes a potential issue where changes to parser rules couldn't be saved after the parser was initially set up. This change ensures that parser rules are consistently applied, preventing unexpected behavior and improving the stability of Odoo's data processing. It's a routine maintenance update to enhance data integrity.
Original PR description
The parser rules cannot be modified once the parser has been instantiated. task-5091744 Forward-Port-Of: odoo/odoo#239046