Daily updates from Odoo
Thursday, January 8, 2026
123 changes · master
Resolved issues and error corrections
This update corrects a bug where packages created using the 'Put in Pack' feature from the SML view were incorrectly located. The issue stemmed from default values being applied during the process, leading to inaccurate package tracking. This fix ensures packages are correctly assigned to their destination after this action.
Original PR description
Putting in pack from the SML view leads to package incorrectly located To reproduce the issue: 1. In Settings, enable "Package" 2. Confirm a delivery with 2 available products 3. Open the SML thanks…
Putting in pack from the SML view leads to package incorrectly located To reproduce the issue: 1. In Settings, enable "Package" 2. Confirm a delivery with 2 available products 3. Open the SML thanks to the smart button 4. Tick a line > Put in pack 5. On the second line, in "Destination Package", look for the package Error: it is impossible to find it When opening the SML thanks to the smart button, we also load a lot of default values: https://github.com/odoo/odoo/blob/1492abd8c6bcfdbc48f730f6767b177aeff54bf7/addons/stock/models/stock_picking.py#L1203-L1221 Those are (obviously) SML specific. However, this context is used when putting in pack. This is a problem since `location_id` is also the field name of a package. As a result, the ORM defines the location of the new package with the default value, i.e. the source location of the SML. This is incorrect. One consequence of this bug is the step 5 of the above use case. When looking for a package, a domain checks its location: https://github.com/odoo/odoo/blob/35feed47622b279abf8e593d8190ea36b64d32fd/addons/stock/models/stock_move_line.py#L51-L55 It must be either `False` or equal to the dest loc, which is not the case with the created package. The root cause of the issue is the uncontrollable propagation of the default values JS side and/or the poor structure of the default key (for instance, the key could contain the model name). Anyway, discussed with PY framework: the matter won't be address that soon. OPW-5215243
This update fixes a crash that occurred when deleting an employee hierarchy element (like a department) while a default filter was applied. The change ensures the system correctly handles record relationships, preventing the 'Missing Record' error and improving stability for employee management.
Original PR description
Reproduce the crash: 1- Create departement in Employees. 2- Create a default filter with child_of or parent_of on the previously created departement. 3- Delete the departement. 4- Go back to Employees => Crash 'Missing Record' This commit adds a check for record exitence in `child_of_domain` and `parent_of_domain` in the case where `_parent_store` is True. This change prevents the `Missing Record` Error. task-5217722 Forward-Port-Of: odoo/odoo#242667 Forward-Port-Of: odoo/odoo#240013
This update ensures Odoo's internal crawler, Odoobot, behaves responsibly when fetching data from external websites. By checking a website's robots.txt file, we now respect the site's rules about which parts of its content can be accessed, preventing unnecessary data retrieval and improving the reliability of our data collection.
Original PR description
### Purpose Add `robots.txt` compliance to the `_fetch_url` helper. Before fetching any URL, we now check the site's `robots.txt` and ensure that our user agent (`Odoobot/1.0`) is allowed to access the requested path. ### Changes - Added `robots.txt` validation using `urllib.robotparser` - Respect disallow rules for the `Odoobot/1.0` user agent ### Why This ensures that our crawler behaves politely, avoids fetching disallowed resources, and provides more transparent failure reporting. --- **Task-ID:** 4779962 Forward-Port-Of: odoo/enterprise#103603 Forward-Port-Of: odoo/enterprise#96369
This update fixes an issue where applying full amounts to bank statement lines was incorrectly triggering tax calculations. This change ensures that tax calculations are only applied to lines that require them, improving the accuracy of financial reporting. It resolves a problem identified after a previous code update.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/5893005187fd67613baaae38e58e126dc9e28544 It could happens that on lines that come from an invoice or a payment (so lines with reconciled_lines_ids. Applying the full amount would trigger the edit_tax_line function which shouldn't be the case since those lines cannot have tax set on them. no task id Forward-Port-Of: odoo/enterprise#103422 Forward-Port-Of: odoo/enterprise#103334
This update resolves an issue where copying content from the Knowledge editor resulted in a loss of plain text formatting. The commit restores the ability to copy and paste plain text, ensuring users can accurately transfer information to other applications. This improves the usability of the Knowledge feature for common tasks.
Original PR description
Since [1] when `vnd.odoo.odoo-editor` was added to the `HtmlViewer` clipboard, the `text/plain` mimetype was lost. This commit restores the plain text version of the clipboard. Steps to reproduce: - In knowledge, lock a page - Select some content - Copy - Paste into a plain text editor => No content was pasted [1]: https://github.com/odoo/odoo/commit/62a7c50b434e3f47ad58e20e96970cbd90b979b6 task-5449435 Forward-Port-Of: odoo/odoo#241741 Forward-Port-Of: odoo/odoo#241642
A visual bug causing a horizontal cursor to appear between cards in the website builder has been resolved. This change disables a plugin that was incorrectly enabling cursor editing and also prevents editing of image figures, ensuring a cleaner and more professional card layout experience.
Original PR description
Since [1] when the selection placeholder plugin was introduced, a horizontal cursor is displayed between cards in website, while that area is not supposed to be editable. This commit disables the `SelectionPlaceholderPlugin` inside the `html_builder`. It also makes the `<figure>` element around images non editable - in order to be able to write a test that does not enforce it to be wrong. Steps to reproduce: - Drop an `s_cards_grid`` block - Put the cursor in a card - Move the cursor with the arrow keys until you leave the card => The cursor was displayed between cards. [1]: https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d task-5383957 Forward-Port-Of: odoo/odoo#242668 Forward-Port-Of: odoo/odoo#240591
This update resolves a bug that caused an error when users canceled image selection in the Salary Configurator. The fix ensures the system correctly handles image uploads and deletions, preventing unexpected errors and improving the user experience. This ensures smooth operation of the employee contract generation process.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** - Install the hr_contract_salary module. - Go to Employee contract and click the Generate Offer. - Click on 'Send By Email' button and open Salary Configurator. - Upload an employee photo the first time. then cancel the image selection the second time. **Issue:** - Error occurs when canceling the image selection on Salary Configurator page. **cause:** - The condition to check whether the file exists properly was missing. **solution:** - Added the missing condition to properly check that file exist. Task-5423390 Forward-Port-Of: odoo/enterprise#103421 Forward-Port-Of: odoo/enterprise#102410
This update fixes a visual issue on the shop page where product images were stacked instead of smoothly transitioning when hovering. By adding a specific CSS class, the system now ensures consistent and animated image replacement across all product list views, improving the user experience. This ensures a more professional and engaging look for product browsing.
Original PR description
Before this commit : --- when the none type hover effect selected on the shop page product hover is supported by default but in this hover transition images are stacked instead of replacing. https://github.com/user-attachments/assets/04801451-842d-4072-bfcf-249767962823 Why this commit : --- adding 'o_wsale_products_opt_img_hover_none' class to manage this image stacking issue The none type is default for all the list layout views hence the image stacking issue observed in all the list views where product image is uploaded in the png without background image. https://github.com/user-attachments/assets/8ad8832f-f2e8-486c-a638-32ea3595493a OPW: 5406434 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241698
This update fixes an issue where the XML parser incorrectly used vendor data instead of customer data when importing sales invoices via drag and drop. Previously, the invoice partner was populated with the vendor's information. Now, the parser correctly uses the customer data from the XML file, ensuring accurate invoice creation and processing for sales transactions. This improves the reliability of the sales journal import feature.
Original PR description
Purpose: The XML parser for the drag and drop feature currently parses the information as if it was for a purchase journal. When using this feature for sales journals, the customer field on the invoice is filled with the vendor's data instead. To fully support sales journal, the XML parser should set the customer field with the customer data defined in the XML file instead. Current Behavior: When drag and dropping an XML file into the Sales journals, the invoice partner is created using the vendor's data. Expected Behavior: When drag and dropping an XMl files in the Sales journals, the invoice partner is created with the customer's data. task 5254692
This update resolves an issue where the appraisal plan start date wasn't being correctly calculated. The previous change removed a key logic piece, and this PR reintroduces it to ensure accurate appraisal scheduling. This ensures appraisals are initiated on the correct dates.
Original PR description
**Issuee:** A recent change (https://github.com/odoo/enterprise/pull/100599/changes) was made to remove duplicate mehtod, but we need to maintain the main logic of setting the `appraisal_plan_start_date` field. This PR reintroduces this logic. Task:5408846 Forward-Port-Of: odoo/enterprise#103385 Forward-Port-Of: odoo/enterprise#102022
This update resolves an issue where delivery validation would fail after splitting a stock move line within a delivery order. Now, when a stock move is marked as picked and then split, the delivery can be validated without errors. This ensures accurate order processing and prevents frustrating backorder warnings for users.
Original PR description
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new…
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new package or a new lot * exit the popup and try to validate the delivery Behavior before this commit: * the stock move in the delivery form remains picked * validation shows a backorder popup, warning of missing quantity Reason: the newly created stock move line is not picked, but this information is not displayed anywhere, so users are not aware of the cause of this issue After this commit: * the stock move is no longer picked after a new move line is added * users can click the "Picked" checkbox in the delivery form manually, which marks all stock move lines as picked as well * after this action, delivery validation proceeds without backorders opw-5345579 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#241790 Forward-Port-Of: odoo/odoo#239089
This update optimizes how the Point of Sale system calculates product prices for paid orders. Previously, the system unnecessarily recomputed prices even after payment, leading to wasted processing time. This change improves the efficiency of the POS system and reduces unnecessary calculations.
Original PR description
Before this commit, the POS system would recompute product prices even for orders that were already paid. This led to unnecessary calculations. opw-5263663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238838
This update resolves an issue where dynamic snippet templates didn't fully reset container widths after a change. The fix ensures all container classes are cleared, preventing outdated styles from persisting and improving the consistency of website layouts when snippets are updated. This results in a cleaner and more predictable user experience.
Original PR description
Steps to Reproduce: 1. Drop a dynamic snippet from debug block. 2. Set the fetched elements to 1. 3. Set the content width to Thin (o_container_small). 4. Change the template of the snippet. When changing a dynamic snippet's template, previously set container widths (e.g., "Thin") could persist even though the option resets. Issue: Only template defined containerClasses were removed, leaving manually set classes like "o_container_small" behind. Fix: All container classes are cleared before applying the new template's containerClasses or falling back to "container". Forward-Port-Of: odoo/odoo#241804
This update corrects errors that were preventing the generation of accurate stock reports for Peru (PLE). The fix involved updating field names and using the correct Odoo API calls, ensuring the reports now reflect inventory data correctly. This resolves a technical issue impacting report accuracy.
Original PR description
## Summary Fix multiple `AttributeError` exceptions when generating PLE 12.1 and 13.1 stock reports: - Use `unspsc_code_id` instead of `unspsc_code` (correct field name defined in `product_unspsc`) - Use `with_context(lang=)` instead of `with_lang()` (correct Odoo API) - Use `categ_id` instead of `category_id` (correct field name on `product.template` and `product.product`) Forward-Port-Of: odoo/enterprise#103004
This update resolves a technical issue that prevented users from correctly selecting a delivery method during checkout on the first interaction. The fix adds a simple check to ensure the necessary webpage elements are loaded before attempting to modify them, ensuring a smooth checkout experience. This improves stability and prevents a frustrating error for customers.
Original PR description
**Description:** - This error occurs when the code attempts to access the classList of a DOM element that has not yet been rendered. Specifically, amountDelivery.querySelector(...) returns null…
**Description:**
- This error occurs when the code attempts to access the classList of a DOM element that has not yet been rendered. Specifically, amountDelivery.querySelector(...) returns null during the first selection of the delivery method, and calling .classList on this null value triggers the traceback.
- The issue is observed only on the first interaction when selecting the delivery method. After refreshing the page, the required DOM element is available, and the checkout flow works as expected.
- To resolve this issue, a conditional check was added to ensure that the DOM element exists before accessing its classList.
- [Reference](https://github.com/odoo/odoo/pull/204358/files#diff-ecbd12f8bbcc7e08a87d7edba111301bb0ca5197137d193323d156809651fcb6R353)
**Steps to reproduce:**
1) Create a fresh database on version saas-18.4.
2) Install the website_sale module.
3) Create a product and add it to the cart.
4) Proceed to the checkout page.
5) Add two delivery addresses for the customer.
6) Configure a delivery method for only one of the delivery addresses.
7) During checkout, select the delivery address that has a delivery method configured.
8) When selecting the delivery method for the first time, a traceback occurs.
- Video [video.webm](https://github.com/user-attachments/assets/b9146fef-cef8-4d16-8556-bbeac9ef6119)
**Traceback:**
```.py
Odoo Client Error
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of null (reading 'classList')
Occured on 51.test.upgrade.odoo.com on 2026-01-07 12:09:06 GMT
TypeError: Cannot read properties of null (reading 'classList')
at Class._updateCartSummary (https://51.test.upgrade.odoo.com/web/assets/1/beaafe8/web.assets_frontend_lazy.min.js:11024:437)
at https://51.test.upgrade.odoo.com/web/assets/1/beaafe8/web.assets_frontend_lazy.min.js:11025:355
at NodeList.forEach (<anonymous>)
at Class._updateCartSummaries (https://51.test.upgrade.odoo.com/web/assets/1/beaafe8/web.assets_frontend_lazy.min.js:11025:337)
at Class._updateDeliveryMethod (https://51.test.upgrade.odoo.com/web/assets/1/beaafe8/web.assets_frontend_lazy.min.js:11022:2353)
at async Class._selectDeliveryMethod (https://51.test.upgrade.odoo.com/web/assets/1/beaafe8/web.assets_frontend_lazy.min.js:11022:54)
```
- opw-5427215
- upg-3715707
Forward-Port-Of: odoo/odoo#242578This update resolves an issue where the product comparison bar was obscured by banner categories on certain pages. The fix removed unnecessary z-index settings that were causing overlapping content. Now, the comparison bar consistently appears correctly, ensuring a better user experience.
Original PR description
Description of the issue: The banner categories snippet (s_banner_categories) had hardcoded z-index values (1, 2, 3, 4) on its grid items. This caused a stacking context issue where grid items with z-index 3 and 4 would overlap the product comparison bottom bar, which uses z-index 3 (default) and 4 (when expanded). Solution in the PR: The z-index values on the grid items were unnecessary since they are positioned using CSS Grid and don't overlap with each other. Removing these inline z-index declarations allow the comparison bar to properly display above all snippet content. After this PR: The comparison bar now consistently appears on top, ensuring users can interact with it without visual interference from page snippets. opw-5426163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242751
This update fixes an issue where invoice names weren't correctly linked to Avalara transactions. The system now recreates transactions after posting to ensure accurate references, maintaining compatibility with Avalara's reporting. This ensures proper tracking of sales transactions with Avalara.
Original PR description
In the external tax refactor [1] I wanted to use the commit endpoint to commit transactions in Avalara after posting. It works, but now transactions on Avalara's side are missing the Odoo invoice name references. It's still possible to cross-reference transactions using avatax_unique_code, but it's less convenient. The reason is that we create transactions for draft invoices. They don't have a name yet. Avalara doesn't have a way to update just the code so we revert back to the pre-refactor approach of recreating the entire transaction right after posting with `'commit': True`. `account_external_tax` calculates the taxes right before `_post()`, so we're reasonably sure they should remain the same. In master we can remove all the commit-specific methods and code. [1] https://github.com/odoo/enterprise/pull/82623 opw-5382268 Forward-Port-Of: odoo/enterprise#103570
This update automatically removes draft IoT Box records on a weekly basis. This prevents unnecessary data storage and improves system performance, particularly for offline pairing scenarios where the app couldn't previously identify when to delete these records.
Original PR description
We now remove automatically draft IoT Box records every day. Draft records are the ones created when clicking "connect" in the IoT app, used to generate a token to identify boxes. If we use the pairing code or auto pairing process, this draft record isn't created until we actually find an IoT Box. But if the method is "offline pairing" and no request is later made by the IoT Box, then the IoT app can't know when to delete the record. The cron job fixes the issue. Forward-Port-Of: odoo/enterprise#103003
This update optimizes the way Odoo searches for items within forms, leading to faster loading times and a smoother user experience. The changes streamline the search process by processing multiple items simultaneously, rather than waiting for each one individually. This enhancement improves overall form performance and responsiveness.
Original PR description
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#242495
This update enhances the speed and efficiency of the spreadsheet dashboards by implementing caching. By using a unique identifier (etag), the system can quickly retrieve existing dashboard data instead of recalculating it each time, leading to a smoother user experience. This change improves performance and reduces server load.
Original PR description
Ensure that the etag is used for caching dashboards. Task: 5441251 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#241834
This update fixes an issue where spreadsheet versions were not being updated correctly in the browser cache after a rename. Now, the system accurately considers spreadsheet metadata (like the name) when generating unique identifiers (ETags), ensuring the latest version is always served. This improves user experience and data consistency.
Original PR description
Etag was computed from the spreadsheet content, but we forget to take spreadsheet metadata (like the name, ...) into account. So when user renames a spreadsheet, the browser still has the old version in cache and does not fetch the new name. This commit ensures that the ETag for spreadsheet data responses also takes into account the metadata of the spreadsheet. This commit also ensures that eTag for dashboards is computed. Task: 5441251 Forward-Port-Of: odoo/enterprise#103143
This update prevents users from attempting to move archived documents (already in the trash) back to the trash view. This simplifies the user experience and avoids unnecessary actions when documents have been permanently removed. The change was made to improve usability and streamline document management.
Original PR description
### Description Do not show the "File > Move to trash” menu entry when the document is already archived (in trash). Task: [5253608](https://www.odoo.com/odoo/project/2328/tasks/5253608) Forward-Port-Of: odoo/enterprise#102773
This update addresses an issue where large .docx files were incorrectly identified with the 'application/zip' mimetype. Increasing the amount of data sent to the mimetype guesser function resolves this, ensuring accurate file type detection for bigger documents when python-magic is used. This improves the reliability of file uploads and downloads.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242624 Forward-Port-Of: odoo/odoo#233266