Daily updates from Odoo
Saturday, March 14, 2026
46 changes · saas-19.2
Resolved issues and error corrections
This update corrects a recent change that was causing incorrect time formatting in the attendance list. The systray button for attendance has been moved to the right for improved display, and demo data has been adjusted to accurately reflect timesheet durations. This ensures accurate attendance tracking and reporting.
Original PR description
Task-5956044
This update addresses several usability issues within the timesheet grid, particularly in the systray view. It includes fixes for display accuracy, expanded descriptions, and improved user interface elements like button labels and icons, ultimately streamlining timesheet management.
Original PR description
Task-5956044
This update fixes a previous limitation that prevented sales products from being reinvoiced. With the new Services and Materials upselling flow, the ability to reinvoice sales products is now enabled, aligning with current business processes. This change ensures consistent and flexible reinvoicing options across all product types.
Original PR description
This commit fixes an issue where the reinvoicing policy option was only available for `purchase_ok` products. The `expense_policy` field was originally limited to expense-related use cases, which is why it was not shown for `sale_ok` products. However, with the introduction of the new Services and Materials upselling flow in Sales, this restriction is no longer valid. The reinvoicing policy should therefore also be available for `sale_ok` products. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent tour update was causing a crash due to incomplete data synchronization. This fix adds a brief delay to ensure all data is fully updated before the tour finishes, preventing the error. This improves the stability and reliability of the tour experience.
Original PR description
The crash occurs due to the test case introduced in PR https://github.com/odoo/odoo/pull/240366. The data is not fully synced with the backend when the tour execution completes, which leads to a crash. This commit introduces a delay to ensure that the data is properly synchronized with the backend before the tour finishes. Runbot-241918
This update corrects a reporting issue where Odoo's code analysis tool (cloc) incorrectly counted installed design themes as custom modules. Removing a specific module that previously handled this exclusion has resulted in themes being included in the analysis. A new 'test_themes' module has been implemented to address this and ensure accurate code reporting.
Original PR description
In saas-19.2 the module theme_common was remove, this module was use by the cloc to ignore the addons in the same folder. Since it has been remove, all the themes installed count as custom modules. Of course we want to avoid that, so we need a new beacon modules: test_themes sounds good. opw: 6036549, 6035869, 6035726, 6035293, 6031718, .... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where component pick transfers weren't correctly linking to all relevant manufacturing orders (MOs) when using a two-step manufacturing process (pick then manufacture). The fix ensures that all MOs associated with a sales order are linked to the pick transfer, improving order fulfillment accuracy. This prevents missed production steps and potential delays.
Original PR description
Current behavior --- When confirming 1 SO with 2 products with 1 BoM and 1 Rerouting Rule with 0 min/max, with warehouse rule pbm (2 steps: Pick then manufacture), it creates a picking transfer with…
Current behavior --- When confirming 1 SO with 2 products with 1 BoM and 1 Rerouting Rule with 0 min/max, with warehouse rule pbm (2 steps: Pick then manufacture), it creates a picking transfer with only 1 MO attached. Expected behavior --- The picking transfer should have 2 MO's. Steps to reproduce --- 1. Create 2 Products with different BoM's, keep per-product routes empty. 2. Set reordering rules for both to route: Manufacture. 3. Go to warehouses config and set manufacture rule to 2 step (pick -> manufacture) 4. Confirm a SO with those 2 products. Cause of the issue --- If we don't have any Make-to-Order routes for a product, the Make-to-Stock default rule of the warehouse would be used. In such case, all MO's related to such OP (orderpoint/warehouse) would be linked into one picking. The stock.picking model uses related fields to compute product_ids, which calculates relation using next(...) in the ORM. This takes only the first MO's stock move and ignores the second, hence ignoring other production groups. Fix --- Instead of using related fields, use compute to access every relavent production ids. --- opw-5442012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249996
A bug was causing leave accruals to be missed in February. This update corrects a calculation error that was incorrectly applying accruals based on the previous year's carry-over date, ensuring accurate accrual calculations for each month.
Original PR description
steps to reproduce: ------------------- 1. Install Time Off 2. Go to Configuration > Accrual Plans 3. Create an accrual plan: * Set the accrued gain time to "At the start of the accrual period" * Set…
steps to reproduce: ------------------- 1. Install Time Off 2. Go to Configuration > Accrual Plans 3. Create an accrual plan: * Set the accrued gain time to "At the start of the accrual period" * Set the carry-over time to "At the start of the year" 4. Create a milestone: * Set the number of accrued days to 1 * Set the accrual frequency to "monthly" and the carry over to "None.Accrued time reset to 0" 5. Go to Management > Allocations 6. Create an allocation: * Set the start date to 2025-01-01 * Set the accrual plan to the one created above 7. Use future allocations to check accruals current behavior: ----------------- - On 2026-01-01 --> accrued days = 1 (correct) - On 2026-02-01 --> accrued days = 1 (should be 2) - On 2026-03-01 --> accrued days = 2 (delayed accrual, off by one month) cause of the issue: ------------------- Commit 30c7011 introduced a condition that accrues time off on the carry over date: https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/hr_holidays/models/hr_leave_allocation.py#L559 This incorrectly evaluates accruals across the carry over period instead of restricting to the current month, causing February accruals to be skipped. **Reason February accruals are skipped:** https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L559-L561 https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L541-L544 * After January, the last_executed_carryover_date is set to 2026-01-01. * Therefore, February uses last_executed_carryover_date = 2026-01-01. * The condition evaluates as true for February: ```python3 last_executed_carryover_date <= allocation.nextcall <= carryover_period_end 2026-01-01 <= 2026-02-01 <= 2026-02-01 ``` As a result, the February accrual is skipped. **Why it works correctly in March:** * After February, the last_executed_carryover_date is updated to 2027-01-01. * March now uses this updated date: ```python3 last_executed_carryover_date <= allocation.nextcall <= carryover_period_end 2027-01-01 <= 2026-03-01 <= 2027-02-01 ``` The condition is not satisfied, so accruals are processed correctly. solution: ---------- Add a condition to check if the loop has already run for the current carryover period. This ensures the system avoids applying the carryover twice, allowing subsequent accruals to process as expected. opw-5020834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253409 Forward-Port-Of: odoo/odoo#227646
When a bill import fails, Odoo now displays a clearer message in the chat indicating an error occurred and attaching the original XML file. This prevents confusion for users and provides more information for troubleshooting failed imports, particularly those from Peppol.
Original PR description
When a bill import (including Peppol) fails, an empty bill is created with the XML attached in the chatter, which can be confusing for users. This commit adds a clearer chatter message indicating that an error occurred and that the incoming XML is attached. task-5932172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250586
This update fixes a minor visual issue where the down payment percentage in sale orders displayed a slight floating-point inaccuracy. The fix ensures that the percentage is rounded correctly, providing a more precise and professional display for users. This improves the user experience when processing payments.
Original PR description
Issue: --- Due to this issue, a small floating point is shown in down payment percentage of a sale order. Steps to reproduce: --- 1- Create a sale order with lines. 2- From `other info` tab, uncheck `online signature` and check `online payment`, and set it to 14 percent. 3- Click on preview. 4- Click on `Accept & Pay`. The percentage shown is `14.000000000000002`, which is unexpected. Fix: --- By setting the percentage as `float` widget it will be rounded properly: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/odoo/addons/base/models/ir_qweb_fields.py#L185-L208 opw-5975047 Forward-Port-Of: odoo/odoo#253205 Forward-Port-Of: odoo/odoo#252169
This update resolves a display issue where the 'Threads' popover in the Discuss app was unexpectedly wide. The fix adjusts the popover's styling to ensure it has a consistent, limited width, and allows content to scroll if needed. This improves the overall user experience for this key feature.
Original PR description
Before this commit, the "Threads" action in Discuss app had its popover width that would take the browser width. This happens because, althought there's a classname to limit its size…
Before this commit, the "Threads" action in Discuss app had its popover width that would take the browser width. This happens because, althought there's a classname to limit its size (`o-mail-Discuss-threadActionPopover`), this was applied on a part of popover and was ignored due to `mw-100 w-100`. This commit fixes the issue by replacing the classname `.o-mail-Discuss-threadActionPopover` with 2 CSS rules for all action panels in popover: ``` .popover:has(ActionPanel) => max-width .popover .ActionPanel-content => max-height ``` These 2 rules handle popover sizing as desired: fixed width for all these popovers, and max-height on the content part of the action panel. This fixes the problem of limited width for both 'Threads' and 'Invite People' popovers, in addition to handle scrollable content thanks to max-height. Before / After <img width="911" height="384" alt="Screenshot 2026-03-10 at 16 12 23" src="https://github.com/user-attachments/assets/f4b77fdb-f946-4d71-904a-d0b273fbe955" /> <img width="915" height="398" alt="Screenshot 2026-03-10 at 16 12 10" src="https://github.com/user-attachments/assets/b2e461e7-a39a-4698-bae0-421d9d87eccb" /> Forward-Port-Of: odoo/odoo#253437 Forward-Port-Of: odoo/odoo#253100
This update ensures that Danish SEPA payments are correctly formatted with the necessary FIK reference information. The change refactors the XML generation process to handle country-specific reference formats, making the system more robust and compliant with Danish regulations. This prevents errors and ensures accurate payment processing.
Original PR description
Issue: - A related PR introduced Danish FIK payment references on customer invoices. - The generated SEPA payment XML did not include this reference, resulting in missing structured communication for Danish payments. IMP: - Extended the SEPA payment XML generation to include the Danish FIK reference when present. - Refactored the structured reference XML builder to use lxml elements instead of string-based XML construction, ensuring proper escaping of structured references. Impact: - Ensures compliant Danish SEPA payments with correct FIK references. - Makes SEPA XML generation future-proof for country-specific structured references containing non-numeric characters. Related PR: https://github.com/odoo/odoo/pull/240829 Task: 5401553 Forward-Port-Of: odoo/enterprise#102612
This update resolves an issue where users without write access to product templates couldn't print labels. The change adjusts how access rights are checked, now permitting label printing for users with read-only permissions. This ensures all users can utilize the product label printing feature.
Original PR description
## Issue Users who do not have the "write" right access on `product.template` cannot print product labels. ## Steps to reproduce 1. Install *Sales* (`sale_management`) 2. In Settings > User &…
## Issue Users who do not have the "write" right access on `product.template` cannot print product labels. ## Steps to reproduce 1. Install *Sales* (`sale_management`) 2. In Settings > User & Companies > Users, make sure Marc Demo does not have any write access on `product.template` 3. Log in as Marc Demo 4. In Sales > Products > Products, open a product and click *Print Labels* from the cogwheel menu 5. **An Access Error is shown, saying that the operation is allowed for the `Products/Create` group.** ## Cause [This commit](https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e) removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`: https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239 When a `group_ids` field is added to the action, this check is no longer performed. opw-5914988 Forward-Port-Of: odoo/odoo#248672
This update removes a temporary feature that automatically disabled longpolling after device connection errors. Previously, the system would wait 5 minutes before switching to WebSocket. Now, with the recommended LNA setup, the system assumes a correctly configured network and automatically recovers from errors, improving reliability.
Original PR description
We used to disable longpolling for 5 min after a failure, in order not to lose time while making requests to an unreachable device, and jump directly to WebSocket. As we now recommand using LNA, clients should have a correctly configured network: if an error occurs the next one should work correctly. We then removed the longpolling auto disable feature. Forward-Port-Of: odoo/enterprise#108778 Forward-Port-Of: odoo/enterprise#108335
This update corrects a naming inconsistency within the HR Payroll module. The template's name was previously set to a subdirectory, which has now been updated to align with standard Odoo module naming conventions. This ensures better organization and clarity within the system.
Original PR description
Currently in hr_payroll, the template name is set as l10n_be_hr_payroll.DropdownSelectionBadge. Generally, it should follow the module name. Therefore, in this commit, I replaced l10n_be_hr_payroll with hr_payroll Forward-Port-Of: odoo/enterprise#110243
This update fixes an issue where the system couldn't correctly process invoices with embedded PDFs (like Peppol invoices). The change ensures that thumbnails are generated properly for these types of attachments, improving the visual representation of invoices within the system. This enhances the user experience when viewing and managing invoices.
Original PR description
The pdf_first_page route failed when called on non-PDF attachments that contain an embedded PDF (e.g. XML invoices generated via Peppol). This fix makes the route correctly extract and process the embedded PDF, allowing proper thumbnail generation in those cases. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251260 Forward-Port-Of: odoo/odoo#236864
This update fixes a display issue with XML invoices received through Peppol. Previously, the preview page showed unnecessary information, preventing thumbnail generation. Now, thumbnails are correctly displayed for these invoices, improving the user experience and ensuring proper invoice viewing.
Original PR description
Before this commit: - The preview page of XML invoices received via Peppol was split into two parts: one showing the PDF preview, and another showing the plain HTML of the PDF viewer page - Thumbnail were not generated for these XML invoices After the commit: - The second part of the preview (Text part) was removed. As the users won't be interested to see the raw XML content of the invoice, neither the plain HTML of the pdf preview page. - Thumbnails now are correctly generated for the XML invoices. Notes: This fix is part of the bug-fix task to ensure users can correctly open XML invoices received via Peppol. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#109100 Forward-Port-Of: odoo/enterprise#100137
This update addresses an issue where the Odoo upgrade process was creating unnecessary data in the system's registry. Specifically, custom models were being repeatedly processed during upgrades, leading to performance slowdowns. This change ensures a more stable and efficient upgrade experience.
Original PR description
During upgrades we observed an uncontrolled growth of the mappings `field_depends` and `field_depends_context` in the registry. The Field instances that serve as keys are duplicated for custom models. This comes from the fact that custom models are completely reloaded during registry setup, even incremental setup. To avoid duplication we consider custom models to be re-setup, which they actually are.
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Xavier Dollé (xdo) <xdo@odoo.com>
Forward-Port-Of: odoo/odoo#253377This update resolves a potential error in the HTML Builder component that could occur when asynchronous operations complete in a changed context. The fix ensures that the builder gracefully handles situations where the underlying component or related elements are no longer available, preventing unexpected errors and improving overall stability. This enhances the reliability of dynamic content generation.
Original PR description
[FIX] html_builder: make async useDomState robust to destroyed context Option components may define an asynchronous `useDomState`. When the asynchronous part of the callback resolves, the execution context may no longer be valid. For example, the editing element, iframe, or even the component itself may have been destroyed in the meantime. This change ensures that async `useDomState` handlers safely abort when their context is no longer available, preventing unnecessary errors from being thrown. task-6003213 Forward-Port-Of: odoo/odoo#252998 Forward-Port-Of: odoo/odoo#251931
This update fixes a potential issue with how Odoo handles WebSocket sessions when a connection closes. Previously, session rotation wasn't correctly disabled for the '/websocket/on_closed' route, which could lead to unexpected behavior. This change ensures session rotation is properly disabled in this scenario, improving stability and reliability of the WebSocket connection.
Original PR description
In [1], session rotation was disabled for websocket routes. However, the `/websocket/on_closed` route was forgotten. This commit ensures session rotation is also disabled for this route. [1]: https://github.com/odoo/odoo/pull/250826 opw-5445323 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#253766 Forward-Port-Of: odoo/odoo#253615
A bug was preventing users from deleting files when pressing the backspace key within the HTML editor. This update corrects a technical issue related to how the HTML editor's deletion functionality interacts with editable elements. The fix ensures files can now be properly removed.
Original PR description
Steps to reproduce: =================== 1- Go to website & add a file using /file or /upload file 2- Click on the file box and press backspace -> Nothing happens. Cause: ====== After this commit [1], `is_node_editable_predicates` was added to prevent color from being applied to the file box so when removing the file box, The delete plugin's removeNode checks `isNodeEditable(node)` which returns false for the file box and thus prevents it from being removed. Solution: ========= a non-editable node that sits inside an editable parent should still be removable so now : node is not removable if !isNodeEditable(node) & its parent is also not contentEditable [1]: https://github.com/odoo/odoo/pull/226927/changes/7f4eedd76c833f3a162070563f3982a1fbdb77c7 opw-5995236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252764
This update resolves an issue preventing users from setting up Amazon accounts when using multiple companies within Odoo Enterprise. The fix allows access to all company accounts during the onboarding process, ensuring compatibility with connected Amazon accounts. This improves the onboarding experience for users managing multiple businesses.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078 Forward-Port-Of: odoo/enterprise#110081 Forward-Port-Of: odoo/enterprise#109590
This update resolves latency issues experienced on iOS devices when interacting with the Point of Sale and self-ordering systems. The fix involves adjusting how the system responds to touch input on iOS, ensuring a smoother and more responsive user experience. Additionally, pinch-zoom functionality has been disabled to improve performance.
Original PR description
On IOS devices, there was a latency issue when hitting different elements in the POS and self. Actually, the issue is because IOS devices don't react in the same way as Android devices. IOS adds a delay of +/-300ms when the element is not considered as a button. Instead of replacing a lot of elements with a button element we can add the parameter role="button". I also disabled the pinch zoom in the POS, self and preparation display. It's mandatory to add the parameter touch-action: pan-x pan-y to the * selector. task: 5976364 enterprise pr : https://github.com/odoo/enterprise/pull/109483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253014 Forward-Port-Of: odoo/odoo#251198
This update resolves latency issues experienced by users on iOS devices when interacting with the Point of Sale system. The fix addresses differences in how iOS and Android devices respond to user input, ensuring a smoother and more responsive experience. Additionally, pinch-zoom functionality has been disabled to improve performance.
Original PR description
On IOS devices, there was a latency issue when hitting different elements in the POS and self. Actually, the issue is because IOS devices don't react in the same way as Android devices. IOS adds a delay of +/-300ms when the element is not considered as a button. Instead of replacing a lot of elements with a button element we can add the parameter role="button". I also disabled the pinch zoom in the POS, self and preparation display. It's mandatory to add the parameter touch-action: pan-x pan-y to the * selector. task: 5976364 community pr : https://github.com/odoo/odoo/pull/251198 Forward-Port-Of: odoo/enterprise#110104 Forward-Port-Of: odoo/enterprise#109483
This update fixes a technical issue where archiving a product linked to an open restaurant order caused a 'TB' error in the POS. Previously, archiving a product associated with a future order also triggered this error. This change ensures a smoother POS experience by correctly handling product archiving scenarios.
Original PR description
When we archived a product which was in a open order not already synced with the backend, when we went back to the POS, a TB appeared. In the same way, if we had an order in the future with a product and we closed the POS, archive the product and went back to the POS, the same TB appeared. task: 6002762 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252796 Forward-Port-Of: odoo/odoo#252211
This update prevents an infinite loop in the credit note claim status polling process. The fix restricts the cron job to only process invoices, addressing a technical issue where credit notes were incorrectly polled, leading to unnecessary processing and potential delays. This improves system stability and efficiency.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
This update fixes a problem where the media editor in the product page editor would sometimes get stuck loading indefinitely. The fix ensures the UI is always released after an action, regardless of its completion, and improves the editor's responsiveness. This prevents frustrating delays for users adding media to product pages.
Original PR description
*: website_sale Commit [1] added a UI block when doing a reloadable operation, and unblocked it once the action finished. However, if the action didn't complete, `ui.unblock` would never be called,…
*: website_sale Commit [1] added a UI block when doing a reloadable operation, and unblocked it once the action finished. However, if the action didn't complete, `ui.unblock` would never be called, leaving the UI blocked indefinitely. To reproduce the issue in website_sale: - Install Website & eCommerce - Go to /shop page - Open a product page - Open the editor - Click on the main product image - In the "Images" section > Click on "Add more" in the Extra media field - Popup shows up but it loads indefinitely Fix this by always calling `ui.unblock` regardless of the reload outcome. Also move the media dialog opening to `load`, which runs before the UI is blocked, passing the selected media as `loadResult` to `apply`. [1]: https://github.com/odoo/odoo/commit/453b7eb8e038ee8e8a54de16fc1a45fb2fab573a Co-authored by: Robin Lejeune (role) <role@odoo.com> opw-6003505, opw-6006393, opw-6016898, opw-6013484, opw-6014383 Forward-Port-Of: odoo/odoo#253490 Forward-Port-Of: odoo/odoo#252755
This update resolves an issue where purchase orders created with the Dropship route were missing the required 'Dropship Address' field. The fix ensures that this field is correctly populated when setting the delivery type to 'Dropship', allowing users to confirm purchase orders without errors. This improves the Dropshipping process and prevents order confirmation failures.
Original PR description
## Issue When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address*…
## Issue
When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address* (`purchase.order.dest_address_id`). It is problematic because that field is both readonly and required to confirm the order.
## Steps to reproduce
1. Install *Stock* (`stock`), *Purchase* (`purchase`) and *Sales* (`sale_management`)
2. In Settings, enable *Dropshipping* and *Replenish on Order (MTO)*
3. Create a Product P
- Set a vendor in the Purchase tab
- Enable the *Buy*, *Dropship* and *Replenish on Order (MTO)* routes
4. Create a Sales Order
- Any Customer
- Product P
- Confirm the Sales Order
5. Click on the *Purchase* smart button
6. Set the *Delivery To* (`purchase.order.picking_type_id`) field to *"Dropship"*
7. **The _Dropship Address_ (`purchase.order.dest_address_id`) field appears, but it's empty and readonly. The purchase order cannot be confirmed, as the field is required and cannot be updated.**
## Cause
When confirming a Sales Order, the created Purchase Order has a `dest_addres_id` set by `StockRule._prepare_purchase_order`:
https://github.com/odoo/odoo/blob/19.0/addons/purchase_stock/models/stock_rule.py#L350
At that point, the `picking_type_id` of the PO is set to `"Receipts"`, which `default_location_dest_id` is the user's Stock, and the `usage` of that location is set to `"internal"`. When `_compute_dest_address_id` is triggered, it starts by calling the method in `sale_purchase`:
https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/sale_purchase/models/purchase_order.py#L25-L30
Which calls the one in `purchase_stock`:
https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/purchase_stock/models/purchase_order.py#L80-L82
Which sets the `dest_address_id` to `False`. This impacts the rest of first `_compute_dest_address_id`, as the PO does not have a `dest_address_id` anymore, its value will never be updated by the `_compute_dest_address_id` methods.
## Fix
The `dest_address_id` should only be set when dropshipping. The easiest way to do so is to override the `_compute_dest_address_id` in the `stock_dropshipping` module by following a similar logic as in `sale_purchase`:
https://github.com/odoo/odoo/blob/7a39185f83d0daca207c8007512f4700537c7e88/addons/sale_purchase/models/purchase_order.py#L25-L30
opw-5426322
Forward-Port-Of: odoo/odoo#252590
Forward-Port-Of: odoo/odoo#245284This update fixes a problem where AI translations on the Odoo SaaS platform would fail after multiple requests due to rate limits. The fix reduces the number of simultaneous requests and now displays a helpful message if some translations are skipped, ensuring a smoother user experience. This prevents complete translation failures.
Original PR description
Scenario: - be on odoo SaaS instance - be on non-translated page with enough content to do 4 requests to /html_editor/generate_text (that are done in chunk of 2000 characters per request currently) -…
Scenario:
- be on odoo SaaS instance
- be on non-translated page with enough content to do 4 requests
to /html_editor/generate_text (that are done in chunk of 2000
characters per request currently)
- open the editor and use "Translate to {lang}" (ai translation)
Result: you see a message "Connection lost. Trying to reconnect..." and
after waiting 10-20 seconds, no translation are inserted in the page.
In reality the requests after the 3 first ones were cancelled (with
error 429 too many requests) by nginx, and the 3 first ones worked
correctly but their result was not used because of the error of the
other ones.
Fix:
- decrease the number of concurrent request from 5 to 3 which is the
current default for this route on SaaS
- adapt the code so if there is errors on one request, successfull
requests will still be applied with the text "Translation Error.
{number} text blocks were skipped during translation. Please try
again." for the blocks that were missed.
This way even if there is an error, the translation is not totally
blocked and doesn't need to be restarted from zero (making it impossible
in the original scenario).
Side note: the number of text blocks not translated was a multiplication
of the total number of text blocks by the number of failed response.
This fix adapts it to just the total of words substrating the number of
translation applied.
opw-5892402
Forward-Port-Of: odoo/odoo#253683
Forward-Port-Of: odoo/odoo#250611This update fixes a calculation error in the equity reports. Previously, `equity_unaffected` accounts were incorrectly using outdated currency rates. The change reorders a key statement to ensure these accounts now utilize the correct, current rate conversion, leading to more accurate financial reporting.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update fixes a bug where loyalty discounts weren't applied to sales orders using different currencies when the total amount was below a threshold. The change ensures the order's currency is used for discount calculations, guaranteeing discounts are applied correctly for all sales, regardless of value. This improves the accuracy of loyalty program rewards.
Original PR description
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1.…
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1. Install Sales app and l10n_cl and loyalty module 2. Switch to CL Company 3. Go to Sales > Products > Discount & Loyalty 4. Create a new program and change the rule's minimum purchase to 0.00 5. Go to Sales and create a new quotation for customer Acme Corporation and add any product 6. Change the sale order line unit price to 0.4 and click on Reward 7. No discount is applied Problem: The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency. Solution: Pass the order currency when computing the discountable amount opw-5946975 Forward-Port-Of: odoo/odoo#252756 Forward-Port-Of: odoo/odoo#250153
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) AFIP responsibility types from creating 'Export Invoices' documents. The fix ensures that these companies can properly generate export invoices, aligning with Argentinian tax regulations. This change improves functionality for a key segment of Odoo users.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Create a Argentinian company with "AFIP Responsibility Type" set to "IVA Sujeto Exento" (VAT exempt) - Switch to the created company - In Accounting settings, set up "AFIP Web Services" - Create a journal for export invoices - Create a customer with "AFIP Responsibility Type" set to "Cliente del Exterior" - Create an invoice - Select the created customer - Try to set the document type for export invoices **Issue:** It is not possible to select "(19) EXPORT INVOICES" as "Document Type" for companies having "AFIP Responsibility Type" set to "IVA Sujeto Exento". It is not because the company is "VAT exempt" that it should not be able to create an export invoice. opw-5974268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252232
This update resolves an issue where loyalty reward products were sometimes hidden within the Point of Sale (PoS) system. This change ensures that reward products are always visible and selectable during transactions, improving the customer experience and preventing lost sales. The fix was part of a larger effort to maintain the stability and reliability of the Odoo POS module.
Original PR description
Before this commit, a product used as a loyalty reward could be hidden in the PoS. opw-5918550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251285 Forward-Port-Of: odoo/odoo#248481
This update fixes an issue where 'ship later' orders were incorrectly showing a zero total cost due to stock valuation delays. The fix now uses the product's standard price when stock hasn't been valued, ensuring accurate order costing and preventing incorrect calculations for FIFO/AVCO order types. This improves the reliability of pricing and reporting for these orders.
Original PR description
When "ship later" is selected, stock moves are created at order time but not yet valued. This caused `_compute_total_cost` to set `total_cost = 0` for FIFO/AVCO order lines because `_get_price_unit()` returns 0 on unvalued moves, and the existing fallback to the refunded line's cost only covered the refund case. Fix by also falling back to `product.standard_price` when the move cost is zero, `shipping_date` is set, and the line is not a refund. opw-5997872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251799
This update ensures that refunds processed through the backend of Odoo now accurately reflect the positive price shown in the user interface. Previously, refunds created through the backend had incorrect negative pricing, leading to discrepancies. This fix standardizes the refund display across all channels for improved accuracy and consistency.
Original PR description
Before this commit, when creating a refund from backend, the refunded lines had negative price, which is not the case when creating a refund from the UI. This commit makes sure that the refunded lines have positive price. opw-5459378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249548
This update fixes a problem where payment processing through Authorize.Net would sometimes fail due to a system conflict. By adding a temporary lock to payment records, Odoo now safely handles retries and ensures payment tokens are used correctly, preventing charges from being incorrectly marked as failed.
Original PR description
Currently, when processing a payment through Authorize.Net, a concurrent update (e.g., from a background cron job) can trigger a PostgreSQL `SERIALIZATION_FAILURE` right after the API request succeeds. Because Odoo automatically retries the request upon this failure, the second attempt sends the same One-Time-Use (OTS) token. Authorize.Net rejects the reused token ("Invalid OTS Token"), causing a successful charge to be incorrectly marked as failed in Odoo.
This commit introduces a pessimistic lock (`FOR NO KEY UPDATE`) on the `payment_transaction` record before making the call to Authorize.Net. This serializes access to the transaction row, ensuring that any lock waits or serialization failures occur *before* the single-use token is consumed, allowing Odoo's automatic retry mechanism to succeed safely.
opw-5475032
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252370
Forward-Port-Of: odoo/odoo#249088This update fixes a potential issue where the Point of Sale system wasn't reliably displaying orders correctly. The change ensures the system waits for all order items to fully load before rendering, preventing display problems caused by delays in data processing or UI animations. This improves the overall user experience for Point of Sale transactions.
Original PR description
Updated the assertion to use the :count() pseudo-selector directly in the trigger. Instead of synchronously throwing an error as soon as .ticket-screen mounts, the framework will now correctly wait for the exact number of .order-row elements to render, resolving timing issues with pending requests or UI animations. build_error-241246 Forward-Port-Of: odoo/odoo#253781
When `selection` is a recordset, `==` is an unsupported operand type Forward-Port-Of: odoo/odoo#253661
Original PR description
When `selection` is a recordset, `==` is an unsupported operand type Forward-Port-Of: odoo/odoo#253661
This update resolves an issue preventing proper printing using wkhtmltopdf. The HTML Editor has reverted to a more reliable static file box implementation, addressing a previous bug. This change ensures consistent printing functionality across the Odoo platform.
Original PR description
Purpose of this commit: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/odoo/pull/216572 enterprise: https://github.com/odoo/enterprise/pull/108999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251752 Forward-Port-Of: odoo/odoo#251098
This update restores a previous implementation of the static file box within the Knowledge articles module. This change resolves a printing issue that was occurring with wkhtmltopdf, ensuring that knowledge articles can now be correctly printed. The fix was necessary after a previous update introduced a problem.
Original PR description
### Purpose of this PR: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/enterprise/pull/88929 community: https://github.com/odoo/odoo/pull/251098 Forward-Port-Of: odoo/enterprise#109376 Forward-Port-Of: odoo/enterprise#108999
This update enhances the 'My Team' filter in Odoo's Live Chat reports. It now accurately includes not just the current user's chat records, but also those of their direct managers, providing a more complete view of team activity. This ensures reporting is more comprehensive and reliable.
Original PR description
Replace the department-based domain with a hierarchy-based domain in livechat reports. The new filter includes the current user's records and the records of employees whose manager is the current user. task-6030147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253567
This update resolves conflicts in how transactions are managed for our German Point of Sale (POS) system, specifically related to Fiskaly reporting. The changes ensure that transactions are correctly handled, preventing errors and improving data accuracy by intelligently managing transaction states and isolating transactions to individual terminals.
Original PR description
Changes:
- cancelActiveTransactions: use the TSS-scoped endpoint
/tss/{tss_id}/tx and filter results by client_id so only orphaned
transactions from this terminal are cancelled, never those from
other POS sessions sharing the same TSS
- transactionCall: on non-retryable errors (400 revision conflict or
terminal state mismatch), call _handleTransactionStateConflict which
GETs the actual transaction state and recovers:
- Cancelling already CANCELLED → silent success
- Finishing already FINISHED → return existing tx data
- Finishing a CANCELLED tx → create a fresh transaction and finish it
- handleFiskalyCancellation: correctly reset transactionState to
inactive on the uiState after cancellation
opw-5972708
Forward-Port-Of: odoo/enterprise#110400
Forward-Port-Of: odoo/enterprise#109996This update resolves an issue where a key field wasn't properly loaded in the point-of-sale system. By adding this field, the system now functions correctly, ensuring accurate data and improved performance for point-of-sale operations. This change enhances the overall reliability of the POS module.
Original PR description
Before this commit, the field iface_fiscal_data_module was not loaded in the pos_self_data, which caused it to be unavailable in the js side of the pos. This commit adds the field to the list of loaded fields, making it available for use in the js code. opw-6034196 Forward-Port-Of: odoo/enterprise#110519
This update optimizes the process of deleting calls in our VoIP system. Previously, deleting related mail activities or messages caused significant delays due to inefficient database searches. By adding indexes, we’ve dramatically sped up these deletions, improving overall system responsiveness and reducing potential bottlenecks.
Original PR description
Description ----------- Commit odoo/enterprise@5751f93c53d3cf37ae8cb627fb8d10a81b7b8833 adds a few new `Many2one` fields, but they're are not indexed, leading to a `Seq.Scan` on `voip.call` when deleting a `mail.activity` or `mail.message`, whos tables are usually large. This commit adds an index on the fields to speed up the deletion. Benchmark --------- Deletion of a `mail.activity` on a database with a `voip.call` table with ~13M rows. (on hot) | Before | After | |--------|---------| | 2.3s | 0.85 ms | Forward-Port-Of: odoo/enterprise#110622
This update corrects a minor visual issue with the Odoo menu toggle. Previously, some browsers would display a broken or incomplete arrow due to a missing unit in the CSS. This change ensures the arrow appears correctly and consistently across all browsers, improving the overall user experience.
Original PR description
Before this commit, some browsers showed a warning or, even worse, dropped this CSS rule because the unit was missing. This line ensures that the tip of the arrow is rounded instead of truncated. 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#253557
This update fixes a problem in the Invoicing Dashboard where the date fields weren't correctly matching invoice data. The change ensures the dashboard uses 'Invoice Date' for matching, which is the most accurate field for this dashboard. This improvement was made after a previous deletion was corrected.
Original PR description
The Date field matching is wrong. Since we are in an Invoicing Dashboard, the best field to match would be "Invoice Date" anyway rather than "Date" Other field matchings were deleted by mistake with commit c6ad6e87bd0d1c64f7a983f9b067b9e460cb998a reported by LUVG opw-5462246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244285
This update resolves an error preventing users from applying the 'My Department' filter in the Time Off module. The issue stemmed from insufficient permissions to access a specific data field within employee records. This fix ensures the filter functions correctly for all users, improving usability.
Original PR description
Steps to reproduce: 1- Install Time off app with demo data 2- Log in as Marc Demo 3- Go to Time Off > Overview 4- Enable My Department filter Issue: An access error is raised because of not having enough rights to access the field version_id on hr.employee. task-5948520 Forward-Port-Of: odoo/odoo#249237