Daily updates from Odoo
Navigate
Branch
Saturday, March 14, 2026
98 changes
51 changes
New functionality added to Odoo
This update introduces a new interactive onboarding tour within the Field Service Planning module. This tour guides new users through the key features and functionalities, making it easier for them to quickly understand and utilize the system. It improves the user experience and accelerates adoption of this important module.
Original PR description
task-5265667
This update incorporates the National Bank of Georgia (NBG) as a source for automatic currency rates. This is required to comply with Georgian tax regulations, ensuring all transactions are accurately translated into Georgian Lari (GEL) using the official exchange rate. This change improves compliance and reporting accuracy for transactions in Georgia.
Original PR description
This commit adds the National Bank of Georgia (NBG) as a supported service provider for automatic currency rate updates. Purpose: To comply with the Georgian Tax Code (Article 73), taxable transactions must be translated into the national currency (GEL) using the official exchange rate defined by the NBG for the transaction day. Functionality: -Enables fetching official exchange rates directly from NBG. -Automatically handles rates defined for different quantities (e.g, rates quoted per 100 units instead of 1 unit). task-5894623 Forward-Port-Of: odoo/enterprise#107375
This update enables Danish companies to automatically generate official FIK payment references on customer invoices through sales journals. Users simply configure their bank's FIK creditor number, ensuring compliant payments without disrupting existing workflows. This simplifies Danish accounting processes and improves data accuracy.
Original PR description
Before: - Danish companies had to rely on manual or non-standard payment communication on invoices. - They could not generate official FIK payment references. After: - Sales journals can now generate Danish FIK payment references automatically. - Users configure an 8-digit bank-issued FIK creditor number on sales journal. Impact: - Enables compliant Danish FIK payments without changing user workflows. Related PR: https://github.com/odoo/enterprise/pull/102612 taskID-5401553 Forward-Port-Of: odoo/odoo#240829
Enhancements to existing features
This update removes a restriction on outgoing stock sequence codes for Turkish companies, allowing users to include warehouse identifiers. This change ensures compatibility with Nilvera's e-Dispatch requirements while retaining operational flexibility. Additionally, the UI has been slightly improved for easier Nilvera status viewing.
Original PR description
# Description of the issue/feature this PR addresses: Previously, the `sequence_code` of `stock.picking.type` was restricted to exactly 3 characters for outgoing pickings of Turkish companies. This…
# Description of the issue/feature this PR addresses: Previously, the `sequence_code` of `stock.picking.type` was restricted to exactly 3 characters for outgoing pickings of Turkish companies. This was introduced because Nilvera requires a 3-character prefix when sending e-Dispatch documents. However, enforcing a 3-character sequence code prevents users from including warehouse identifiers in the prefix (e.g. `WH/OUT`). Odoo normally relies on this structure to help users filter and distinguish warehouses. With the restriction in place, this functionality was lost. # Desired behavior after PR is merged: This commit removes the 3-character restriction on the sequence code and introduces a computed field that extracts the required 3-character GIB prefix from the sequence code. The computed prefix is used when sending documents to Nilvera, while users can keep meaningful sequence codes for operational use. Additional improvements: - Move the e-Dispatch tab next to "Operations" in `view_picking_form` - Reduce the spacing between the text and reload button for the "Nilvera Status" field in `view_picking_form` task-5964505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Odoo’s accounting system aligns with the latest Peppol codelist version 9.5. This is a necessary step to comply with evolving European regulations for electronic invoicing and improve data exchange with trading partners using the Peppol network.
Original PR description
A new version of codelist (v9.5) has been released. This commit aligns the Peppol EAS field selection with the Peppol codelist v9.5 See the changelog here : https://docs.peppol.eu/edelivery/codelists/changelog.html Updates applied according to the official v9.5 changes. task-5461213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243990
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
7 changes
Enhancements to existing features
This update ensures Odoo’s accounting system aligns with the latest Peppol codelist (v9.5). This is a necessary step to maintain compliance with European regulations for electronic invoicing and improve data exchange with Peppol network partners. The change was made to reflect official updates from the Peppol organization.
Original PR description
A new version of codelist (v9.5) has been released. This commit aligns the Peppol EAS field selection with the Peppol codelist v9.5 See the changelog here : https://docs.peppol.eu/edelivery/codelists/changelog.html Updates applied according to the official v9.5 changes. task-5461213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243990
Resolved issues and error corrections
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 fixes an issue where refund calculations for orders with multiple line items in the Mexican VAT (l10n_mx_edi_pos) module were inaccurate due to incorrect summing of line amounts. The change ensures that refunds are compared correctly against the original order total, preventing errors and ensuring accurate financial processing. This resolves a potential discrepancy in refund amounts.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#108827 Forward-Port-Of: odoo/enterprise#105301
This update resolves conflicts in how transactions are managed for the German Point of Sale (POS) system, specifically related to Fiskaly reporting. The changes ensure that transactions are correctly cancelled or finished, preventing errors and improving data accuracy. This resolves a previous issue impacting transaction processing.
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 POS self-service system. Adding this field ensures the system functions as intended, improving the accuracy and reliability of sales data. This change supports proper reporting and integration within the POS environment.
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 resolves an issue where the menu toggle arrow in the Odoo web interface wasn't displaying correctly in some browsers. The fix ensures the arrow's tip is rounded, preventing it from appearing truncated. This improves the overall visual consistency and 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 that the dashboard now accurately matches against 'Invoice Date' instead of the generic 'Date' field, improving the dashboard's accuracy and usability. This was reported and resolved by LUVG.
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
1 change
Resolved issues and error corrections
This update resolves an issue preventing the POS system from correctly accessing fiscal data information. By adding a necessary field to the loaded modules, this change ensures the POS functionality operates as intended and supports required reporting.
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
2 changes
Resolved issues and error corrections
This update resolves an issue where a key field wasn't properly loaded in the POS self-service system. By adding this field, the system now functions correctly, ensuring accurate data and improved performance for users. This change enhances the reliability of the POS self-service experience.
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 resolves an issue where the menu toggle arrow in the Odoo web interface wasn't displaying correctly in some browsers. The fix ensures the arrow's tip is rounded, preventing it from appearing truncated. This improves the overall visual consistency and 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
26 changes
Enhancements to existing features
This update adds versioning to Odoo's live chat stores, mirroring a recent community change. This ensures that live chat data is consistently tracked and managed, improving data integrity and reliability. It's a necessary step for maintaining the stability of our live chat functionality.
Original PR description
Counterpart of the community PR that adds versioning to the discuss store. Any route returning or sending a store should be versionned via the `mail_route` decorator. community: https://github.com/odoo/odoo/pull/246467
This update adds a button to quickly move all orders to the next stage in the preparation process. When an order reaches the final stage, the preparation status is automatically marked as complete, improving efficiency and reducing manual effort.
Original PR description
In this commit: =============== - We added a `Clear All Orders` button in the sidebar. On clicking that, all the orders will be moved to their next respective stage. - If the order stage is already the last stage, then the order's preparation state is marked as done. Task: 5877460 Forward-Port-Of: odoo/enterprise#105847
This change optimizes the process of generating GST reports by streamlining the database query. Specifically, it removes a complex domain filter that caused performance issues with large datasets, resulting in faster report generation times. This improvement ensures smoother and more efficient report processing.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#110334
Forward-Port-Of: odoo/enterprise#109795Resolved issues and error corrections
This update prevents installation errors when the PostgreSQL user lacks necessary permissions. By checking if the pg_vector extension is already installed before attempting to create it, the update avoids a common error and simplifies the installation process without granting excessive database privileges. This improves stability and ease of use.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.
Forward-Port-Of: odoo/enterprise#110091
Forward-Port-Of: odoo/enterprise#109650This update ensures that German customer addresses are correctly formatted when used with Amazon. Previously, the system incorrectly sent company names as the primary address line, causing delivery validation errors. This change swaps the fields to ensure accurate address formatting and successful delivery.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update focuses on improving the Field Service feature by ensuring migrated functionality remains operational and streamlining the daily workflow for planning users. Key changes include accurate time tracking, enhanced reporting, and UI refinements for better usability.
Original PR description
This commit continues to review the new Field Service to make sure the features migrated from the old Field Service are still available and also improve a bit the flow to facilate the day to day of…
This commit continues to review the new Field Service to make sure the features migrated from the old Field Service are still available and also improve a bit the flow to facilate the day to day of planning users using Field Service feature. In detail, this commit will: - fix traceback and access rights on creation of worksheet - use generated timesheets of the intervention for the report. To do that a new one2many field called `intervention_timesheet_ids` is added in `planning.slot` model. And so instead of relying on 'timesheet_ids' of the slot, which are not necessarily linked to the intervention, we compute the effective hours based on the timesheets generated by the intervention, and use that field in the report and stat button. - change color of trash button in form view in gantt - make sure no planned shifts are not displayed - simplify kanban card when shift is not planned - some relabeling and change worksheet visibility condition in the report - hide resource_ids in calendar popover when empty - hide Field Service report if no customer report - compute is_absent field if shift is not completed - raises a user error when the user tries to reset the state of an intervention in draft if the state was in progress or completed - hides `Hide price on customer report` in settings of planning app if `Customer Report` feature is disabled - add space between worksheet and photos in the portal view and in Field Service report - compute quotations_count field in planning.slot only if the user has sales access - makes sure the context is reset before taking the display name of the customer set to set it to display name of the shift. Because before this commit, when the user creates a new shift and set a customer to the intervention, the display_name of the shift will contain the customer name but also his address which is not really expected. - reorder worksheets data/demo to have the one created in demo data first once the demo data are loaded - relabel email template in field service - order the tracking in planning.slot - reset SO when customer changes - show field service stat button in SO when SO is generated/linked to an intervention. - text white for conflicts tag in kanban otherwise the text is not correctly lisible in light mode. - fix worksheet visibility in portal/report - fix action_complete() and sale_line_id computation when no SO - review card_top of kanban card of planning slot - hide effective_hours and related fields from views/reports - remove group to prevent access errors in SO - hide partner_phone if no partner set on the shift - add photos in field service report - don't allow to add material on draft or published, we should only be able to add material when the intervention is in progress or completed task-5994280 Forward-Port-Of: odoo/enterprise#109963
This update resolves an issue where navigating back from the Helpdesk message search panel on mobile devices resulted in an error. The fix ensures a smoother user experience by implementing a standard navigation pattern for closable components, similar to those used in other parts of the application. This enhances usability and prevents frustrating errors for mobile users.
Original PR description
...in mailboxes on mobile community PR: https://github.com/odoo/odoo/pull/252512 Before this commit, navigating back from a mailbox message search panel on mobile would result in a traceback. Steps to reproduce: 1. Open Discuss on mobile 2. Navigate to bookmarks in bottom bar 3. Open message search 4. Navigate back -> traceback This happens because the `useBackButton` in ActionPanel registers a callback function taken from the env. Said function is missing when the ActionPanel is mounted outside of a chat window or meeting view. This commit fixes the issue by adding a `close` props to ActionPanel, and using that as a callback for back navigation. This is an established pattern for similar closable components like Popover, Dialog and EmojiPicker. task-6013922 Forward-Port-Of: odoo/enterprise#110150
This update corrects an issue preventing basic inventory users from saving delivery records due to incorrect access permissions. The change ensures that only users with the necessary account access rights can modify related data, improving system stability and security. This resolves a restriction on user capabilities within the Odoo Enterprise inventory module.
Original PR description
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld…
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module. Cause of the issue: Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53 Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error. runbot-240937 Forward-Port-Of: odoo/enterprise#109817
This update ensures that the system correctly validates UY CFEs (electronic invoices) by granting necessary permissions to access company data. Previously, users without specific group access would encounter validation errors. This change adds sudo() access to company data, resolving this issue and improving the reliability of the UY CFE processing workflow.
Original PR description
This pull request makes a small update to the `_ucfe_inbox` method in `l10n_uy_edi_document.py` to ensure that company-specific fields are always accessed with the appropriate permissions. This is achieved by using the `sudo()` method when retrieving the `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields from the `company` record. * Ensured that `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields are accessed with elevated permissions by calling `company.sudo()` in the `_ucfe_inbox` method (`l10n_uy_edi_document.py`). Without this fix, if the user doesn't belong to group "base system", it won't be able to validate CFEs, receiving the following message: <img width="1272" height="400" alt="image" src="https://github.com/user-attachments/assets/ec4223fb-5b96-4a3e-babf-2f6a35ecd123" /> Forward-Port-Of: odoo/enterprise#105918
This update prevents a crash when generating invoices for subscriptions with both standard products and timesheet services. Previously, an empty timesheet line caused an error. The fix adds a safeguard to skip invoice lines without sale order links, ensuring invoices can be created correctly regardless of timesheet delivery status.
Original PR description
**Issue:** When generating an invoice for a subscription that contains a mix of regular products (invoiced on order) and timesheet-based services (invoiced on delivery), a traceback can occur if the…
**Issue:** When generating an invoice for a subscription that contains a mix of regular products (invoiced on order) and timesheet-based services (invoiced on delivery), a traceback can occur if the timesheet service has 0 delivered quantity. **Cause:** During the invoice creation process, `_get_reinvoiced_analytic_lines_to_link` iterates over the newly created invoice lines to link analytic lines. It filters the linked sale order lines using `_is_line_reinvoicable()`. If the invoice only contains standard products (because the timesheet line was skipped due to 0 delivery), `so_lines` evaluates to an empty recordset. then calling `_get_range_dates` causes a treace beack because it needs to ensure that ther is at least 1 order `self.ensure_one()` **Fix:** Added a safeguard (`if not so_lines: continue`) inside the loop. If an invoice line does not contain any reinvoicable sale order lines, it is now safely skipped, allowing standard subscription lines to be invoiced alongside undelivered timesheet lines without crashing. task: 5966725 Forward-Port-Of: odoo/enterprise#108685
This update corrects a technical issue where outdated database records related to HR work entries were present. These records have been permanently removed as part of a system update, ensuring data integrity and preventing potential future problems. This change improves the stability and efficiency of the HR payroll module.
Original PR description
The records `hr_work_entry.access_hr_work_entry_officer` and `hr_work_entry.access_hr_work_entry_system` no longer exist. They have been removed by https://github.com/odoo/odoo/pull/244436. runbot_build_error-240728 Forward-Port-Of: odoo/enterprise#110255
This update corrects a bug where helpdesk users weren't seeing ratings for tickets assigned through teams they weren't directly members of. The fix ensures all assigned tickets' ratings are accurately reflected in the average rating views, providing a more complete and reliable customer feedback picture. This improves the accuracy of performance metrics.
Original PR description
Steps to reproduce: - Configure a helpdesk team to be viewable by the test user - Remove test user from member_ids of helpdesk team - With that team selected, create a helpdesk ticket assigned to test user - Submit a rating for the ticket as the customer - As the test user in the helpdesk app overview, click on today average rating or last 7 days average rating Current behavior: - In both views, the test user won't see ratings for tickets attached to helpdesk teams where they are not listed in member_ids Expected behavior: - In both views, the test user should see all ratings of assigned tickets regardless if they are included in a helpdesk team's member_ids Note: member_ids in helpdesk.team appear to be only used for auto assigning new helpdesk tickets, so checking member_ids doesn't account for all potential users working in a team opw-5949917 Forward-Port-Of: odoo/enterprise#109470 Forward-Port-Of: odoo/enterprise#109136
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing when multiple bills were selected has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#110350 Forward-Port-Of: odoo/enterprise#106894
This update resolves intermittent test failures in the sign feature by using dedicated test users instead of the default 'admin' and 'demo' accounts. This ensures test results are consistent and reliable, preventing disruptions to development and testing.
Original PR description
Relying on the default `admin` and `demo` users caused random runbot failures, as their access rights can be altered by other modules. This commit replaces them with freshly created test users to strictly simulate the presence or absence of the `sign.group_sign_user` group, ensuring the test remains deterministic. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241216 Forward-Port-Of: odoo/enterprise#110454
This update fixes a missing 'Reset' button for specific Spanish informational reports. A recent configuration change made the standard reset button invisible. This fix adds a dedicated reset button that appears when the report is completed, ensuring users can properly clear and regenerate these reports.
Original PR description
- The `Reset` button was missing from the dropdown menu for Spanish informational reports (Mod 130, 347, 349, 390). - This occurred because these reports were recently configured with `is_tax_return_type = False` in this [commit](https://github.com/odoo/enterprise/commit/d2b1d29542c0350c267fecffd70d3e288364d8ab). However, the standard reset button (`action_reset_tax_return_common`) is configured to be invisible when `is_tax_return` is false. - This fix adds a reset button specifically for these Spanish reports that appears when the report is completed. task-5214023 Forward-Port-Of: odoo/enterprise#110271 Forward-Port-Of: odoo/enterprise#104739
This update fixes a server error that occurred when merging tables in the Point of Sale system, specifically when a table was empty and an order was present. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This improves the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#110052 Forward-Port-Of: odoo/enterprise#104577
This update ensures that taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't directly provided by the vendor. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, the system uses standard product tax rules for these lines, ensuring accurate tax calculations across all regions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#110166 Forward-Port-Of: odoo/enterprise#106686
This update resolves errors in the P&L and Balance Sheet reports specifically for French association companies. The team addressed inconsistencies in the data while acknowledging limitations in report aggregation, ensuring accurate financial reporting for this user group.
Original PR description
The aim of this commit is fixing the Pnl & Balance Sheet report in France for association company. This commit ensures that we don't have any duplicate errors in the PnL & Balance Sheet. We kept some errors in the Balance Sheet (especially about the brut - amort - net) as we can't use aggregation with groupby but the data are not really duplicated. no task id Forward-Port-Of: odoo/enterprise#110163
This update corrects a minor display issue in the account reports where the green comparison color wasn't consistently showing. The change resolves a technical adjustment related to how data is processed after the Dictalypse merge, ensuring accurate and reliable reporting visuals.
Original PR description
With Dictalypse merged, there is a small mistake converting mode <=> comparison_mode since column_percent_comparison_data is now technically a column. The fix is to use comparison_mode instead of mode in the js view. Forward-Port-Of: odoo/enterprise#110476
This update resolves a JavaScript error that occurred when reloading the shopfloor app, specifically during MO process runs. The fix disables the automatic focus of the search bar, preventing a common error related to the element not being available during the reload. This ensures a smoother user experience.
Original PR description
Steps to reproduce:
- Open the shopfloor app
- Reload or duplicate the page where the MO process is running
Issue:
A JavaScript error occur during reload:
UncaughtClientError > TypeError
Uncaught Javascript Error > Cannot read properties of null (reading 'blur')
Occured on 101125414-19-0-all.runbot180.odoo.com on 2026-02-16 04:59:28 GMT
TypeError: Cannot read properties of null (reading 'blur')
at https://101125414-19-0-all.runbot180.odoo.com/web/assets
/9d8abcf/web.assets_web.min.js:36280:459
Cause:
This happens when the search bar component attempts to call `blur()` on `inputRef.el` while the element is not yet available or has already been destroyed during the component lifecycle.
Fix:
Disable the search bar autofocus in the shopfloor
`env.config.disableSearchBarAutofocus = true`.
opw-5902675
upg-3894728
Forward-Port-Of: odoo/enterprise#109803
Forward-Port-Of: odoo/enterprise#107491This update corrects a minor issue in the l10n_be_hr_payroll module that could have affected the accuracy of payroll calculations. The change ensures the code correctly uses loop variables instead of 'self', resolving a potential source of error. This ensures payroll is calculated correctly for Belgian employees.
Original PR description
Use loop variable instead of `self`. Forward-Port-Of: odoo/enterprise#109970
A warning message was appearing during tax report adjustments in the French localization. This was caused by an unnecessary reference to 'box_B1' within the report's calculations. This update removes this reference, ensuring the report functions correctly and eliminates the warning message for users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update resolves a UI issue that occurred when changing wage intervals in the employee payroll settings. The problem stemmed from extra text being added to the employee form view, causing errors. This fix removes the problematic text, ensuring correct wage interval calculations and a stable user experience.
Original PR description
Bug production steps: First, I created a new db with saas-19.1 db from runbot, from payroll->employee->Payroll tab in form view, when you change wage interval to another thing than 'month' error occurs Bug cause: There is another text like /2 months, /2 weeks are inserted from hr_employee_views in the hr_contract_salary_payroll to the XML of the employee form view. Bug solution: Removing the corresponding XML insertions. task - 5469378 Forward-Port-Of: odoo/enterprise#110462 Forward-Port-Of: odoo/enterprise#104116
This update ensures Odoo complies with NACHA rules regarding payment descriptions. Starting March 2026, all payroll payments must include 'PAYROLL' in the Company Entry Description field. This change is necessary to avoid potential payment processing issues and maintain compliance with financial regulations.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
Features or functions removed from Odoo
This update removes a restriction in the EC Sales List report that previously only allowed reporting for businesses. This change now correctly handles companies that are configured as individuals, ensuring more accurate reporting across all company types. It's a minor improvement to the reporting functionality.
Original PR description
Removing as the prod has a lot of companies that are configured as individuals. no-task Forward-Port-Of: odoo/enterprise#110098 Forward-Port-Of: odoo/enterprise#99807
Code cleanup and technical improvements
This update simplifies how WhatsApp stores data related to store information. This change improves the efficiency and reliability of the WhatsApp integration within the Enterprise version of Odoo. It's a refactoring effort to streamline the process.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/253668
11 changes
Resolved issues and error corrections
This update resolves a problem where work orders weren't correctly tracking component consumption. The previous changes introduced unintended consequences, so we've reverted them. Additionally, a test has been updated to ensure this issue is properly addressed moving forward.
Original PR description
Commit [1] has been merged with another commit OC side. However, the latter has impacted some other use cases. This is the reason why we need to revert both. The current commit also improves a test in `test_consume_component.py` to cover the case that has been broken [1] 75febe5a72f091a9940b27c7a59a31f3fe3c407a opw-5939156
This update resolves a technical issue related to XML files used for processing payments in Sweden (SEPA). The change ensures the correct XML format is used, specifically switching from `<BIC>` to `<BICFI>` nodes, which is required by Swedish banking standards. This ensures seamless payment processing for our Swedish customers.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
This update resolves an issue where scanning packaging barcodes didn't correctly link to associated lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes accurately identify and link to the correct lots during scanning, improving inventory accuracy and usability.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#108214 Forward-Port-Of: odoo/enterprise#98701
This update corrects a warning message appearing when adjusting the B1 field in French tax reports. The issue stemmed from an unnecessary reference to 'box_B1' within the report's calculations. This change ensures the report functions correctly without displaying misleading warnings, improving the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update ensures Odoo complies with new NACHA rules regarding payment descriptions. Starting March 2026, all payroll payments must include "PAYROLL" in the Company Entry Description field. This change is necessary to avoid potential payment processing issues and maintain compliance with financial regulations.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
This update prevents an infinite loop in the claim status polling process for credit notes (DTE 61). The system was incorrectly attempting to retrieve claim information for credit notes via a SII endpoint that doesn't support them, leading to unnecessary and continuous polling. By restricting the polling to only invoices, the issue is resolved and performance is improved.
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 an issue where barcode-created manufacturing orders incorrectly used product UoMs instead of the specified BoM UoMs. Now, the system accurately reflects the BoM's quantities when creating stock moves within barcode-based MRP processes, ensuring accurate inventory tracking. This resolves a previous error that could lead to incorrect production quantities.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110393 Forward-Port-Of: odoo/enterprise#90408
This update removes a redundant check for local network connectivity when opening cashboxes via IoT. Since stable IoT boxes are now reachable through a websocket, this check was unnecessary and causing potential delays. This change streamlines the cashbox opening process.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#110188 Forward-Port-Of: odoo/enterprise#107397
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 conflicts in how transactions are managed for the German POS system (l10n_de_pos_cert) when using the API. Specifically, it ensures that only transactions tied to a single terminal are cancelled, preventing issues with shared POS sessions. The update also handles errors more gracefully, recovering from conflicts and ensuring data consistency.
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#109996This update resolves an issue preventing the POS system from correctly accessing fiscal data information. By loading a key field, the system now functions as intended, ensuring accurate reporting and compliance. This change enhances the overall reliability of the Point of Sale 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