Daily updates from Odoo
Tuesday, April 28, 2026
44 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where a key test for sharing activity updates between Odoo tabs was unreliable. The problem stemmed from interference with a specific internal route (`/mail/data`). Merging this fix ensures that activity broadcasts function consistently, improving the stability of Odoo's notification system.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260862 Forward-Port-Of: odoo/odoo#260265
This update corrects a recent issue where invoice PDFs in version 19.2 were missing crucial title words and a legal disclaimer. Restoring these elements ensures compliance with Saudi Arabian tax regulations (ZATCA) and maintains the accuracy of our invoices. This change improves the legal standing of our invoices and avoids potential compliance problems.
Original PR description
Since version 19.2, the invoice PDF was missing required title words
("Tax", "Simplified Tax") and the "THIS IS NOT A LEGAL DOCUMENT" warning
due to layout architecture changes.
This commit restores these strings to the invoice header to maintain
ZATCA compliance. The correct wording is dynamically applied based on
the document context.
task-6040091This update fixes a bug that caused errors when repeatedly deleting images from an Image Wall in edit mode. The fix prevents a traceback by ensuring the element still exists in the DOM before attempting to delete it, improving the overall stability of the website editor. This ensures a smoother experience for users.
Original PR description
Error: Cannot read properties of null (reading 'children') Steps to reproduce: 1.Go to Website -> Edit mode. 2.Add an Image Wall snippet. 3.Click on an image, then repeatedly click the Delete button. 4.Traceback occurs. Before this commit: The first delete click correctly removes the target element from the DOM, including its parent. On subsequent rapid clicks, the handler runs again on the same already-removed element. At that point, parentElement is null, so accessing children throws a traceback. After this commit: Added a safety check using `isConnected` in the delete handler to ensure the element is still part of the DOM. If not, the handler returns early. Repeated delete clicks no longer cause a traceback. task-6033622 Forward-Port-Of: odoo/odoo#261341 Forward-Port-Of: odoo/odoo#255733
This update ensures that the Slovak VAT tax reports generated by Odoo comply with the official Slovak XML format. Specifically, it corrects rounding to two decimal places in editable fields, aligning with the required precision specified by the Slovak VAT XSD schema. This ensures accurate data exchange with tax authorities.
Original PR description
As per the Slovak VAT XSD schema, editable fields must use a precision of 2 decimal places. So updating here to ensure compliance with the official XML format. Reference: https://ekr.financnasprava.sk/Formulare/XSD/dph2025.xsd Forward-Port-Of: odoo/odoo#261459
This update resolves an issue where the Planning app would crash when adding a new employee with no calendar, particularly when combined with a public holiday for another company. The fix ensures that the system handles empty resource scenarios gracefully, preventing a critical error and improving app stability.
Original PR description
Issue: ---------------------------------------- When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback. Steps to reproduce:…
Issue: ---------------------------------------- When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback. Steps to reproduce: ---------------------------------------- - Have Planning and Time Off installed - Create a public holiday for another company - Create an employee with no calendar - Open Planning and try to add the new employee - Traceback Cause: ---------------------------------------- This commit 55ce1e3411d0693807d883ac159039b8141ff6b6 added the new method called `_get_flexible_resource_valid_work_intervals()` which will call `_leave_intervals_batch()` on `self.env['resource.calendar']`. In `_leave_intervals_batch()`, the resource list will contain the fully flexible employee and `self.env['resource.resource']`. During the handling of the public holiday we created, we loop through the resource list. The first one is the flexible employee, but it gets skipped by the `continue` as it has a different company. Because of this the variable `tz` still equals `None`. The second resource is `self.env['resource.resource']` which doesn't validate the condition to be skipped. So it reaches the line ```py tz = tz if tz else timezone((resource or self).tz) ``` But `tz` is still `None` and both `resource` and `self` are empty, so it gives `False` to the timezone constructor, which crashes. Solution: ---------------------------------------- Add a default value to 'UTC' to handle this specific case. opw-6107269 Forward-Port-Of: odoo/odoo#259404
This update ensures consistent test tagging across Odoo versions 18 and 19, preventing potential disruptions to automated testing. Previously, an error during nightly tests could disable the entire 'hoot suite' due to an incorrect default tag. This change backports a fix from a larger project to maintain stability and reliability of our testing processes.
Original PR description
When an error is parsed during the nightly, the default test tag is not correct in 18 and 19, what could lead to disabling the complete hoot suite if not taking enough care when disabling a test. This backports part of #234937 to ensure with have the correct tag in all version supporting hoot tests. Forward-Port-Of: odoo/odoo#261618 Forward-Port-Of: odoo/odoo#261526
This update resolves an issue where copying and pasting content from the blog post editor unexpectedly modified the original field. The fix adds a setting to the editor to prevent copying outside of the editable area, ensuring data integrity and preventing unintended changes to the source records.
Original PR description
Problem: When copying the blog post title and pasting it elsewhere, editing the pasted content unexpectedly modifies the original field source. Cause: The copied HTML retains `data-oe-*` attributes, causing the editor to treat the pasted content as a field binding and propagate changes back to the original record. Solution: `contenteditable="true"` should be added on fields (`o_savable`) to prevent copying outside of savable area. Steps to Reproduce: - Copy title of blog post. - Paste it elsewhere in editable. - Edit the pasted text. - Observe the original field source also changes. opw-6105714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258880
This update resolves a performance issue that caused slowdowns and crashes when working with many2many fields containing thousands of records. The change replaces a slow search method with a faster one, ensuring smoother operation and preventing UI freezes when handling large datasets.
Original PR description
### Issue before this commit: When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became…
### Issue before this commit: When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic. ### Steps to Reproduce: Create a computed many2many field. Add it to a form view (can be invisible). Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field. ### Cause of the Issue: In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity. When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity. ### With This Commit: Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets. opw-6122024 Forward-Port-Of: odoo/odoo#261093 Forward-Port-Of: odoo/odoo#260993
This update changes the email address used for automated support responses from iap@odoo.com to noreply@odoo.com. This change improves email deliverability and reduces the risk of incorrect responses to support inquiries.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/odoo#260794 Forward-Port-Of: odoo/odoo#259691
This change updates the email address used for automated support notifications from iap@odoo.com to noreply@odoo.com. This ensures that client responses to support emails are correctly directed to the appropriate team, improving communication and support efficiency.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update resolves an issue where duplicating an employee would incorrectly copy their bank account information, leading to salary payments being routed to the same account for both employees. The fix prevents the bank account from being copied during duplication, ensuring each employee has their own dedicated account.
Original PR description
Steps: - Duplicate an employee. - Check that the bank account is copied. - Modify the bank account on the duplicated employee. - Verify the original employee’s bank account. Issue: - When duplicating an employee, the bank account was copied as well, causing both employees to use the same account. Updating it for one also changed it for the other, leading to both salaries being paid to the same account. Fix: - Set the 'bank_account_id' field to not be copied during duplication, ensuring the field is cleared for the duplicated employee. task-6093406 Forward-Port-Of: odoo/odoo#261505 Forward-Port-Of: odoo/odoo#259405
This update ensures that replacement invoices generated after a cancellation process now include the original invoice's 'Source' (origin) information. Previously, this data was missing, hindering traceability and compliance. This fix maintains accurate links between invoices and Sales Orders, improving reporting and auditability.
Original PR description
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice…
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099
A minor technical issue was resolved where the wrong function was being utilized within the VoIP sales module. This fix ensures accurate processing of VoIP calls related to sales transactions. The change improves the reliability of the sales process.
Original PR description
Shh! We used the wrong function.
This update addresses an issue where Coda bank statement files sometimes lacked the necessary data to populate payment reference fields in Odoo. Without this information, Odoo would default to 'No description' for payment statements. This fix ensures accurate payment tracking and reporting.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
This update resolves an issue where invoice reports were incorrectly matching account IDs, leading to potential reporting discrepancies. The fix ensures that all account IDs in export files align with those defined in the company's general ledger, improving the accuracy of financial reports. This change was part of a larger effort to standardize FAIA XML exports.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#114254 Forward-Port-Of: odoo/enterprise#113455
This update improves the Odoo accounting system for Sri Lanka by incorporating updated chart of accounts (CoA) and tax settings. These changes align the system with standard Sri Lankan accounting practices, ensuring accurate financial reporting and compliance.
Original PR description
Updates the CoA with new accounts, updated taxes, and adjusted default account mapping to better reflect standard Sri Lankan accounting practice. Enterprise PR: https://github.com/odoo/enterprise/pull/114768 task-6141758 Forward-Port-Of: odoo/odoo#260920
This update simplifies the setup of financial accounts by reducing the complexity of Balance Sheet formulas. It also adds new lines for equity and liabilities, providing a more accurate and flexible reporting structure for Sri Lankan businesses using Odoo Enterprise. This change enhances the flexibility of the COA setup.
Original PR description
Reduces Balance Sheet account code formulas from 3-digit to 2-digit prefixes to make the COA setup more flexible. New equity and liability lines are also added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/260920 task-6141758 Forward-Port-Of: odoo/enterprise#114768
This update resolves an issue preventing account return tours from functioning correctly across all Odoo localization modules. The fix addresses a missing tag that caused errors, specifically related to a missing 'super call' during form submissions. This ensures all users, regardless of their Odoo localization, can utilize the account return tour functionality.
Original PR description
Before, the account return tour was not running with every l10n installed du to a missing tags. This leads to errors that were not catched like missing super call on a submit action. Forward-Port-Of: odoo/enterprise#115290
This update corrects a mismatch in Transaction IDs between sales and purchase invoices and their corresponding general ledger entries. Previously, the system used different identifiers, leading to potential errors in financial reporting exports (FAIA). This change ensures data consistency and accurate reporting.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
A bug in a test for the restaurant point-of-sale module caused order data to be incorrectly updated. The fix addresses a timing issue where test actions interfered with server synchronization, leading to lost user information. This ensures test results are reliable and accurate.
Original PR description
In the tour test_customer_alone_saved, the test was creating an order, then go on the ticket screen and then come back on the product screen to change the customer to go again on the ticket screen and come back on product screen to check that the customer did not changed. The problem was that when going to the ticket screen the first time, the order was synced with the server but the answer might come after the test changed the customer. When going the second time on the ticket screen, the order was changed with the information of the backend and the user was lost. This is all due to the test that are too fast. runbot-error: 238467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253587
This update resolves a critical issue where deleting sign templates caused document corruption and broken lineage tracking. The fix ensures documents remain intact and accurately link back to their original versions, regardless of the number of sign templates created. This enhances data integrity and reliability for document signing workflows.
Original PR description
Steps to reproduce: Bug 1 (The Crash): 1. Open Documents app, select a PDF, and click Action > Sign. 2. In the Sign app, delete the newly created Sign Template. 3. Return to the Documents app. 4. A…
Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.
Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.
Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI.
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.
Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.
Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.
Task: 5432116
Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167This update resolves a failing test related to WorldLine integration within our self-order point-of-sale system. The fix ensures that the test only runs if both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are installed, preventing errors and improving test reliability.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed. Forward-Port-Of: odoo/enterprise#115282
This update resolves an issue preventing the Odoo database from correctly processing data from IoT devices. A missing field was added to the subscription messages, ensuring the database can now successfully receive and process updates from these devices. This improves the reliability of IoT data integration.
Original PR description
In odoo/odoo#260380, a new required field was added to the websocket `subscribe` message, `check_outdated`. This commit adds this field to the subscribe message sent from the IoT box so that the DB can process it successfully. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows administrators to control when subscription users are automatically reset. Previously, this process was fixed, preventing flexibility. This change improves operational control over subscription management and aligns with evolving business needs.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
This update ensures Odoo accurately reflects the latest Ecuadorian withholding tax regulations (Resolución N.º NAC-DGERCGC26-00000009) for 2026. The changes involve updating unit tests to align with these new percentages, ensuring accurate reporting and compliance for our Ecuadorian clients.
Original PR description
In accordance with the implementation of the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. Unit tests are updated to be based on the new withholding percentages. BP #110343 Forward-Port-Of: odoo/enterprise#112957 Forward-Port-Of: odoo/enterprise#110712
This update resolves a bug preventing correct invoice creation when discounts are applied to sales orders using foreign currencies. The fix ensures accurate allocation of discounts across different currencies, preventing unbalanced invoice errors. This improves the reliability of financial reporting and invoicing processes.
Original PR description
**STEP TO REPRODUCE** 1. Install the sale and accounting module. 2. Create 2 products, and setup each one with a different income account. 3. From the accounting settings, setup an account for Invoice Line discount -> Customer Invoice account. 4. Enable a currency, and create a pricelist for this currency. 5. Create the following SO: pricelist -> the pricelist you created previously. currency rate : 0.000717398539 line a: product_a, price 10, discount 57.85% line b: product_b, price 70, discount 57.85% From this SO, try to create an invoice. It will fail, saying the invoice it tried to create is unbalanced. opw-5974048 Forward-Port-Of: odoo/odoo#257897
This update fixes a bug in the bank statement reconciliation process. Previously, the system incorrectly matched bank transactions from different companies with the same UUID, leading to inaccurate journal entries. The fix ensures that both the bank statement and payment belong to the same company hierarchy, preventing foreign transactions from being incorrectly added.
Original PR description
ticket-5992100 When auto-reconciling bank statement lines, the end-to-end UUID lookup correctly checked that matched AMLs and their payment belong to the same company hierarchy, but missed checking that the payment also belongs to the same company hierarchy as the bank statement line itself. This allowed a payment from an unrelated company (sharing the same end-to-end UUID from an inter-company bank transfer) to be matched against another company's bank transaction, pulling foreign tax lines into the wrong company's journal entry. Fix by adding the same parent-path company check between the bank statement line and the payment. Forward-Port-Of: odoo/enterprise#114881 Forward-Port-Of: odoo/enterprise#113279
This update resolves an issue where the quick create feature for product variants in the Bill of Materials form was incorrectly creating new, unrelated product templates instead of variant products. To ensure correct variant creation, the 'quick create' option has been disabled, requiring users to create variants directly on the product template. This prevents data inconsistencies and ensures accurate product tracking.
Original PR description
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create".…
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create". Issue: --- Using quick create on the Product Variant field does not create a variant of the selected product template. Instead, it creates a completely new, unrelated `product.template`. This is because the `create()` method on `product.product` is overridden to call super() with context `create_product_product=False`, which suppresses direct variant creation and forces creation through `product.template` instead, see [1]. **Why passing `default_product_tmpl_id` does not help:** One might expect that passing `default_product_tmpl_id` in the field context would cause the newly quick-created `product.product` to be linked to the already-selected `product.template`. However, because of the `create()` override above (introduced in [commit]), the variant creation is always redirected to `product.template`, ignoring any `default_product_tmpl_id` passed in context. It is therefore not possible in any case to quick-create a `product.product` that is correctly and directly linked to the currently selected `product.template`. Fix: --- Disable the "Create" and "Create and Edit" options. Since there is no way to quick-create a `product.product` that is correctly linked to the currently selected `product.template`, the user must create the variant directly on the product template first. [1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368 [commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8 opw-6127738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261316 Forward-Port-Of: odoo/odoo#259776
This update corrects a technical issue where the AI chat window was being opened twice. This fix ensures the AI chat functionality operates reliably and efficiently, preventing potential performance problems. The change improves the overall user experience for the AI chat feature.
Original PR description
This commit removes a double call to the `thread.openChatWindow` from the `ai_chat_launcher_service`.
This update resolves a bug where basic receipts were incorrectly generated in the Point of Sale chatter even when the feature wasn't enabled. It now ensures basic receipts are only created when the option is specifically selected and prevents multiple receipt image types from being generated at once. This improves the reliability and consistency of Point of Sale reporting.
Original PR description
Before this commit: =================== - Basic receipt was generated even when the option was not selected. - Both basic and full receipt images could be generated simultaneously. After this commit: ================== - Basic receipt is generated in chatter only when the option is enabled. - Prevents simultaneous generation of both basic and full receipt images. Task - 6126775
This update resolves an issue where KSeF invoices were being rejected due to empty 'Email' and 'Telefon' tags in the invoice XML. The fix ensures these tags are only included when a buyer's email or phone number is actually provided, aligning with KSeF requirements and preventing rejection errors.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Create and send an invoice to KSeF where the buyer has no email or no phone number 3. KSeF rejects the invoice with error code 450 (semantic verification error) This happens because `Email` and `Telefon` elements are always rendered inside `DaneKontaktowe`, even when their values are empty, producing invalid empty tags. After this commit: Add `t-if="buyer.email"` and `t-if="buyer.phone"` guards on each field so that `Email` and `Telefon` are only rendered when a value is present. opw-6124187 Forward-Port-Of: odoo/odoo#259646
This update fixes an issue where the ‘Ordered Quantity’ on delivery slips was incorrectly calculated, leading to inaccurate reporting of stock movements. Now, the ‘Ordered Quantity’ always matches the actual demand, ensuring accurate inventory tracking when validating receipts with or without backorders.
Original PR description
**Steps to reproduce:** * Install the *Inventory* (`stock`) module. * Create a *Storable Product* and set some *On Hand* quantity. * Go to *Inventory → Operations → Receipts*. * Create a new receipt.…
**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
* Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
* Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.
**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
* Case 1 (Demand=10, Done=8):
* Ordered = 8, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 12, Delivered = 12.
**Expected behavior:**
* Case 1 (Demand=10, Done=8):
* Ordered = 10, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 10, Delivered = 12.
**Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157
CASE- 1
* When validating with *less quantity* and *no backorder*:
* In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
* If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
* where it take quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
* As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.
CASE-2
* When validating with *more quantity* than demanded:
* `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
* The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
* The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
* In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
→ `qty_ordered += 2` → `qty_ordered = 12` ✗ (surplus added to demand)
→ `quantity += 2` → `quantity = 12` ✓
* The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.
* After the fix:
* Case 1 (Demand=10, Done=8):
* Ordered = 10, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 10, Delivered = 12.
* NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully
Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div>
<img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
<img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
</div>
<p><strong>After:</strong></p>
<div>
<img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
<img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
</div>
</details>
---
opw-5874759
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250587A recent update caused newly added overtime lines on attendance records to disappear. This fix disables the ability to add new overtime lines, resolving the synchronization problem and preventing data loss. This ensures accurate work entry tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#261224 Forward-Port-Of: odoo/odoo#248431
This update corrects a bug that was causing overtime work entries to incorrectly generate on previous days. The fix adjusts how work entries are regenerated, considering employee timezones to accurately determine the correct start date for overtime calculations. This ensures payroll reports are reliable.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate…
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#115032 Forward-Port-Of: odoo/enterprise#107266
This update fixes an issue where power buttons within the Knowledge editor were being hidden due to incorrect boundary calculations. The change ensures the editor accurately accounts for margins, guaranteeing that power buttons remain visible and functional for all users.
Original PR description
**Current behavior before PR:** - Power buttons in Knowledge were hidden incorrectly because `editableRect.width` was used as the boundary. Since the editable area has margins applied, this width no longer reflects the actual boundary, causing buttons to be hidden. **Desired behavior after PR is merged:** - Use `editableRect.right + referenceRect.left` instead of `editableRect.width` to determine the correct boundary, ensuring power buttons remain visible in when editable area has margin applied to it. task-6102944 Forward-Port-Of: odoo/odoo#259532
This update resolves two issues impacting how production orders are managed within the Barcode app. Previously, changes to the unit of measure and production quantities were not saved correctly, leading to inconsistencies. Now, these changes are reliably saved and reflected, ensuring accurate production tracking.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114452 Forward-Port-Of: odoo/enterprise#114075
This update resolves issues causing discrepancies between imported BIS3 invoices and their source XML files. The changes improve the accuracy of invoice totals by streamlining the import process and ensuring values are correctly applied. The team has also implemented a new, more manageable testing approach for BIS3 imports.
Original PR description
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be…
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be categorized as: - collecting all the values from the XML to a dictionary object - prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers - write the whole processed values to the invoice (as a single write) - (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests. task-id: 5058687 Co-authored-by: Yosua Nicolaus <yoni@odoo.com> Forward-Port-Of: odoo/odoo#260803 Forward-Port-Of: odoo/odoo#250160
This update enhances the accuracy of invoice imports by adding a key field (`partner`) to the query builder for move lines. This resolves issues with unsynchronized values during import, particularly related to invoices generated with UBL formats. It's part of a larger effort to improve data consistency within the Enterprise version.
Original PR description
This commit is part of a bigger commit on the community side- to refactor the import code of BIS3 Invoice to fix various unsynchronized values issues. task-id: 5058687 Forward-Port-Of: odoo/enterprise#114717 Forward-Port-Of: odoo/enterprise#108356
This update resolves a potential error in the account reports module where clients with custom modules could experience conflicts when querying standard 'state' fields. By explicitly using column aliases in queries, this fix ensures data integrity and prevents ambiguous column references, improving report accuracy.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
This update fixes a recent issue where users needed to manually pair their Bluetooth devices with the IoT Box. The fix resolves a technical problem where the device was forcibly disconnecting Bluetooth connections at startup. Now, supported devices should automatically connect when in range, improving the user experience.
Original PR description
According to the IoT Box documentation written in 10/2019, supported Bluetooth devices should connect automatically whenever they are in range of the IoT Box: https://github.com/odoo/documentation/commit/16f2f26f8ae6d9040195c854da337e0dcbbff955#diff-b5974750d9a7f12db80e4922399a7cacd26228dec979ca0fbb504faac386efc8R27 This behavior had broken at some point, requiring manual pairing via bluetoothctl on the IoT Box to establish a connection. Root causes identified and fixed: - The interface was forcibly disconnecting all already-connected BLE devices at startup, kicking them mid-GATT handshake - No BlueZ pairing agent was registered, causing AuthenticationFailed during the pairing negotiation Automatic connection on proximity is now restored. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only non-closed assets are considered during the sale process, preventing double-entry errors and maintaining accurate fixed asset, depreciation, and gain calculations. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649 Forward-Port-Of: odoo/enterprise#115115
This update fixes an issue where stock quantities weren't always correctly reflected in the unit of measure of purchase orders. It now automatically creates pickings for both partial and empty sale/purchase orders, ensuring accurate stock tracking. Additionally, the demo stock for a key product has been adjusted to prevent negative stock levels in other demo data, maintaining data integrity.
Original PR description
Make sure that the quantity received is in the unit of measure of the purchase order line. Also, when installing stock, create pickings for partial and empty sale/purchase orders. Finally, since creating we're creating more pickings, we need to raise the demo stock of product_product_12 to not be in negative stock for other modules demo data. task 5431550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245281
This update corrects a previous issue where expense cards were not recognizing payments from airlines, car rental agencies, or hotels. The system now includes the necessary Merchant Category Codes (MCCs) to process these transactions, ensuring users can accurately track and categorize their expenses. This resolves a rejection of payments that would otherwise have occurred.
Original PR description
In the expense card, when a payment is made. The card can be filtered to only allow certains category of merchant. However, the 3 ranges of MCC we not added: - Airlines, air carriers: MCC's from 3000 to 3350 - Car Rental Agencies: MCC's from 3351 to 3500 - Lodging, hotels, motels and resorts: MCC's from 3501 to 3999 And since the MCC are not present in the list, they are rejected by default even the card is set to accept all MCCs. task-5486945 Forward-Port-Of: odoo/enterprise#115379 Forward-Port-Of: odoo/enterprise#114154
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes enhance the overall experience for users managing their timesheets within the Odoo Enterprise system. The update focuses on improving usability and streamlining workflows.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness. Forward-Port-Of: odoo/enterprise#114339