Daily updates from Odoo
Friday, January 16, 2026
308 changes
19 changes
Enhancements to existing features
This update simplifies the process of setting up Peppol integration within Odoo. The old wizard has been replaced with a more user-friendly interface, including a radio selection for registration type and a dedicated field for the Peppol contact email. This change streamlines the configuration and improves the overall user experience.
Original PR description
In this commit: - Deprecate the Peppol configuration wizard. - Move the Peppol contact email field to Settings. - Replace the wizard button with a radio selection for the Peppol registration type. - Simplify the overall Peppol settings user experience. Task-5438539 Co-authored: [Soham Zadafiya (soza)](soza@odoo.com) Forward-Port-Of: odoo/odoo#243985
This update clarifies the labels and settings related to Peppol reception within Odoo Enterprise. It adjusts requirements based on a company's Peppol participation role and prevents unnecessary fields from being required for companies only sending data. This ensures smoother integration with Peppol networks.
Original PR description
In this commit: Clarify Peppol reception mode labels to better reflect actual behavior. Update Settings field requirements based on the Peppol participation role. Prevent document-related fields from being required when the company is configured as sending-only. Task-5438539 Co-authored: [Soham Zadafiya (soza)](soza@odoo.com) Forward-Port-Of: odoo/enterprise#104430
Resolved issues and error corrections
This update resolves an issue preventing non-administrator users from archiving channels. By using `sudo`, users can now archive channels without needing specific permissions, improving channel management flexibility. This change enhances user experience and simplifies channel organization.
Original PR description
**Purpose of this PR:-** Allow users to archive channels using `sudo` so the action is not blocked by missing discuss role access error. task-5478832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue within the Point of Sale (POS) testing process. Specifically, it ensures that a key step – verifying the existence of at least one paid order – is completed before the automated tour ends. This prevents potential errors and ensures the tour runs smoothly, providing a more reliable testing experience.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 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#243815
This update resolves an issue where imported sales orders containing kit products (with tracked components) were incorrectly splitting the order into multiple lots during the POS process. This commit ensures that kits are no longer tracked by lots when sold, preventing errors and improving the reliability of POS sales transactions. This change was made to address a bug impacting order accuracy.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update resolves issues with the Knowledge editor, specifically preventing problems when copying and pasting headings and improving the responsiveness of the heading link button. The changes ensure consistent URL redirection and a smoother user experience when editing knowledge articles.
Original PR description
### [FIX] knowledge: prevent heading link id duplication on copy/paste Prior to this commit, copy/pasting a heading would preserve its `data-heading-link-id` resulting in mismatches for URL redirections. After this commit, such ids are always reset to guarantee unicity. ### [FIX] knowledge: throttle mousemove for heading link button Prior to this commit, every `mousemove` event could cause a layout trashing to reposition the heading link button. After this commit, the repositioning is debounced at a more reasonable rate. task-5384684 Forward-Port-Of: odoo/enterprise#104460 Forward-Port-Of: odoo/enterprise#101445
This update ensures that payment terminal responses sent via websocket include a necessary 'session_id' field. This resolves an issue that could have caused communication problems between the payment terminal and the Odoo system, improving the reliability of payment processing.
Original PR description
We provide the request data to the payment terminal response to ensure `session_id` exists in the response sent through websocket.
This update fixes an issue where numbers extracted from OCR boxes were incorrectly formatted due to language-specific decimal separator handling. The change simplifies the parsing process by consistently using a standard Javascript `Number` parser, ensuring accurate number representation regardless of the user's language settings. This improves data integrity for financial and reporting processes.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979) Forward-Port-Of: odoo/enterprise#104467
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it's correctly linked to the Euro (EUR) to reflect Bulgaria's adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for users operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update fixes a usability issue in the Sign editor where the document dropdown didn't close correctly after selection. The fix adds a click listener to the PDF iframe to manage dropdown interactions, ensuring a smoother user experience. It also includes styling updates for consistency and clarity.
Original PR description
- Fix hover and pointer behavior on update document action - Apply consistent danger styling to delete action - Ensure dropdown closes correctly after interaction (PDF iframe has its own document so outside-click logic did not apply; add a click listener on the iframe document to close open dropdowns. ) task: 5384677 Forward-Port-Of: odoo/enterprise#102447
This update enhances the customer display popup in Point of Sale, making it easier to access customer information on both desktop and mobile devices. Previously, the popup opened in a separate window, which was difficult to use on a second device. Now, users will see a button to open the display on the same device or scan the QR code, streamlining the customer interaction process.
Original PR description
Changed to open the QR code popup on the desktop as well. Before it was opening directly in a new window and it was hard to open it on a separate device. The QR popup will: - on desktop: will show a button to open the customer display on the same device, or to scan the qr - on mobile: will show only the qr code to scan task-5129241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243521 Forward-Port-Of: odoo/odoo#229478
This update fixes an issue where right-clicking on links within messages was obscured by extra message actions. Now, users will see the standard browser context menu options like 'Open Link' and 'Copy Link' when right-clicking on a link, providing a smoother and more intuitive experience.
Original PR description
Before this commit, when right-clicking on a link in a message body, this was showing the list of message actions in dropdown. This is a problem because right-click on link has features like "Open link" / "Copy link" and so on. They were over-shadowed by the right-click on message for showing of message actions. This commit prevent the showing of message actions in dropdown from right-click in links in message body, so that the browser context menu is open instead in that scenario, showing features like "Open link" and "Copy link".
This update fixes a technical issue that caused tracebacks when a member typed in group chats with multiple users. The fix restricts the display of typing indicators to direct messages (DMs) only, aligning with the expected behavior of group chats. This ensures a smoother user experience for all Odoo users.
Original PR description
Before this commit, when another member of a group chat with more than 2 members was typing it would result in a traceback. Steps to reproduce: 1. Have `hr_homeworking` and/or `hr_holidays` installed 2. Create group chat with 2 other users 3. Open said group chat 4. Have another member start typing -> traceback This happens because since [1] the condition to show the `ImStatus` component became `showImStatus`, which is true in group chats when another member is typing. However since group chats with more than 2 members have no correspondent, this leads to the `ImStatus` component having no `persona` attribute, which in turn causes a crashes in templates without a guard on `persona` access. This commit fixes the issue by making `showImStatus` only true in DMs, since it's not expected for group chats to have a correspondent and hence an IM status should not be shown. [1]: https://github.com/odoo/odoo/pull/234715
This update fixes a previous change that prevented automatic follower copying from parent sale orders to subscription renewals and upsells. This ensures that sales teams automatically receive notifications for related subscription activity, improving collaboration and communication. The change maintains the previous restriction for other Odoo record types.
Original PR description
[FIX] sale-subscription: Restore automatic follower copying from parent SO In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181 Forward-Port-Of: odoo/enterprise#101088
This update fixes an issue where sale warnings weren't showing when set on a company contact instead of an individual partner. The change ensures that all sale warnings, regardless of whether they're linked to a partner or their company, are now correctly displayed. This improves the accuracy of sales alerts and helps sales teams address potential issues proactively.
Original PR description
### Issue: Due to this issue, the sale warning message is only shown when the warning message is set on partner itself, not partner's company. #### Steps to reproduce (with demo data): 1- Enable `Sale warnings` from setting. 2- On `Contacts` app, open `Azure Interior`, and add a sale warning from `Notes` tab. 3- Create a SO with `Brandon Freeman` from `Azure Interior` as the customer. 4- No sale warning is shown. ### Cause: The IMP #192211 replaces warning popup with a message. However, it doesn't check for the warning from `partner_id.parent_id`, which was the case before that PR. This is the case with purchase as well. opw-5404983 Forward-Port-Of: odoo/odoo#242050
This update fixes a bug that prevented read-only accounting users from seeing the 'Customer Statement' button when viewing a customer record. The issue stemmed from a restriction in the system's access controls, which was unintentionally limiting access for read-only users. This change ensures all users with accounting rights can access this important feature.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103715 Forward-Port-Of: odoo/enterprise#102683
This update fixes an issue where invalid warehouse addresses caused continuous geolocation requests to OpenStreetMap. Now, when a location's coordinates cannot be determined, the system sets default coordinates, preventing further attempts and improving location accuracy for warehouse listings. This enhances the user experience and data reliability.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address. Forward-Port-Of: odoo/odoo#243523
This update resolves a potential error in how accounting calculations handle specific scenarios, particularly when all factors are zero. The change ensures the system correctly distributes remaining amounts, preventing tracebacks and maintaining accurate financial reporting. This improves the stability and reliability of the accounting module.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
This update enhances the reliability of website generation by ensuring that customized images are correctly updated and by optimizing database operations. The changes address a previous issue where images weren't being replaced properly and reduce the number of database queries, leading to faster and more stable website updates.
Original PR description
Added commit_progress during website generation, this is now required due to the reduction of the timeout delay of crons as well as to ensure robustness. Fixed bug where the customized images where not replaced correctly. It happens because we were copying the original instead of fetching the modified one. Switch to record operations in batch to reduce number of queries.
10 changes
Resolved issues and error corrections
This update resolves an issue where the website builder incorrectly defaulted to the 'Add' tab when removing content from the 'Customize' tab. Previously, the builder wouldn't return to the last active tab, leading to a frustrating user experience. This fix ensures the builder correctly navigates back to the last selected tab after removing options, improving usability.
Original PR description
During [website builder refactor], there was a mistake in handling fallback of the builder tab. If the user is in the "customize" (aka "Edit") tab and changes the document in a way that there is no more options in the tab, the builder was supposed to move back to the last other tab opened, but just always fell back to "blocks" (aka "Add") Steps to reproduce: - Open website builder - Drop a section - Click on "Theme" tab - Click on the section - Click on "Remove this block" - Bug: the builder falls back to the "Add" tab instead of "Theme" tab [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5493971
This update fixes a critical issue where changing the backdrop color of a popup in Odoo 18.4 and 19.0 caused the popup to disappear unexpectedly. The team addressed this by switching to a class-based approach for managing popup visibility, ensuring a stable and reliable user experience.
Original PR description
Steps to reproduce in 18.4: - Add a popup on the page - Click on the popup - Change the backdrop color - Hide the popup by clicking on its entry in "Invisible Elements" - Undo - Redo - Bug: The popup disappears Steps to reproduce in 19.0: - Add a popup on the page - Click on the popup - Hover a color in the colorpicker of the backdrop option of the popup - Stop hovering the color - Bug: The popup disappears
This update fixes an issue where the link popover remained open after a snippet was removed from the website. The change ensures the popover closes automatically when a snippet is deleted, improving the user experience and preventing visual clutter. This resolves a minor usability problem.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its `pointerdown` handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document `pointerdown` listener, but this also triggered when interacting with the link type `dropdown` and color picker, closing the popover triggers `applyCallback` and causing nested links to be created.
After this commit:
- Close the link popover from `on_will_remove_handlers` before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a technical error that prevented users from processing payments through Razorpay in the POS module, specifically when using Indian localization. The fix removes a problematic code element that was causing an error, ensuring smooth payment processing for our Indian customers.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update resolves a problem where imported sale orders containing kit products were incorrectly splitting sales into individual lots. The change prevents this behavior, ensuring accurate POS sales processing for kit products. This improves the reliability of our POS system.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update resolves an issue where the 'Other Input' section of the Payroll app incorrectly displayed trailing zeros for negative salary attachment counts. The fix adjusts a widget to properly handle negative values, ensuring accurate reporting of attachment numbers. This improves the clarity and reliability of payroll data.
Original PR description
Steps to Reproduce: - install Payroll app - create an employee and create a salary attachment. - check the negative value for salary attachment - generate a payslip Issue: - In "Other Input" section, salary attachment count displays value with trailing decimal zeros for negative amounts. Reason: - The field is using the widget float_without_trailing_zeros which should remove the extra decimal zeros but it doesn't work when the value is negative. Solution: - Fix the regular expression in the float_without_trailing_zeros widget to handle negative values and properly remove trailing decimal zeros. task-5477466
This update corrects a data inconsistency in Odoo, ensuring Bulgaria's currency is accurately listed as EUR. As Bulgaria transitions to using the Euro on January 1, 2026, this change aligns Odoo's data with the latest official currency information. This ensures accurate reporting and financial processes related to Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update resolves a technical issue causing tracebacks when generating the Follow-up Report in Partner Ledger. It ensures that general accounting entries are automatically set to 'no_followup', streamlining reporting. Importantly, payments from Point of Sale (POS) systems are still included in follow-up reports.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104500 Forward-Port-Of: odoo/enterprise#104433
This update fixes a bug where sale warnings weren't showing for customers linked to a company contact. The change ensures that warnings set on a company are correctly displayed when creating sales orders with customers associated with that company. This improves the accuracy of sales alerts and prevents missed opportunities.
Original PR description
### Issue: Due to this issue, the sale warning message is only shown when the warning message is set on partner itself, not partner's company. #### Steps to reproduce (with demo data): 1- Enable `Sale warnings` from setting. 2- On `Contacts` app, open `Azure Interior`, and add a sale warning from `Notes` tab. 3- Create a SO with `Brandon Freeman` from `Azure Interior` as the customer. 4- No sale warning is shown. ### Cause: The IMP #192211 replaces warning popup with a message. However, it doesn't check for the warning from `partner_id.parent_id`, which was the case before that PR. This is the case with purchase as well. opw-5404983 Forward-Port-Of: odoo/odoo#242050
This update resolves an issue where rapid receipt printing via USB printers occasionally caused errors. The fix ensures only one thread can access the printer at a time, preventing conflicts and guaranteeing reliable printing performance. This improves the overall stability of the receipt printing process.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
9 changes
Resolved issues and error corrections
This update removes an unnecessary warning related to credit notes from the GSTR report. Previously, the warning interfered with credit note processing, particularly when a credit note was confirmed after an invoice. Now, the warning is automatically cleared when the credit note is fully posted and checked.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#104518 Forward-Port-Of: odoo/enterprise#102106
This update corrects a technical issue that was causing error messages when using Razorpay payment processing within the Point of Sale (POS) system. The fix removes a problematic attempt to access sudo functionality, which wasn't applicable to the Razorpay payment request object. This ensures smoother and more reliable payment processing for Indian users.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update resolves a problem where imported sales orders containing kit products (tracked by lots) were causing errors in the Point of Sale (POS) system. The change prevents the system from incorrectly splitting sales by lots when a kit is involved, ensuring accurate POS transactions.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
A bug was causing overdue invoices to appear twice in PDF follow-up reports. This update corrects a technical issue within the invoicing process, ensuring invoices are printed only once in these reports. This improves the accuracy and clarity of follow-up reminders for customers.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870 Forward-Port-Of: odoo/enterprise#102516
This update resolves an issue preventing stable IoT Box responses from being correctly read. By adding a check for a 'result' key in the data, the system now reliably processes data from these terminals, ensuring consistent and accurate reporting. This improves the overall stability and functionality of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
This update corrects a data inconsistency in Odoo, reflecting Bulgaria's recent adoption of the Euro as its official currency. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, it's correctly associated with the Euro (EUR), ensuring accurate financial reporting and data processing for transactions in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update fixes an issue where negative line items (discounts) weren't correctly formatted in XML invoices for the Ecuadorian market (**l10n_ec**). The change aligns the process with Mexico (**l10n_mx**) by using a new method to distribute these discounts, ensuring accurate invoice generation and compliance. This resolves rounding discrepancies that could lead to incorrect tax calculations.
Original PR description
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can…
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased. ## Steps to reproduce With **l10n_ec**: 1. Change the decimal accuracy to 6 digits. 2. Set the rounding method to *global rounding*. 3. Create an invoice with the following lines: | Quantity | Price | Taxes | |-----------|----------|-----------| | 20 | 1.4235 | VAT 0% G | | 20 | 1.6425 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.4235 | VAT 0% G | | 6 | 3.747768 | VAT 15% G | | 6 | 3.747768 | VAT 15% G | In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`. This happens due to rounding differences in how the `descuento` is computed in the `common_details_info_template` from **l10n_ec_edi**: format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount']) where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere. This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**. Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed. opw-5128612
This update ensures that manually set currency rates on customer invoices (especially in German and Hungarian) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard exchange rates, leading to potential inaccuracies. This fix maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update resolves a potential error in the accounting module that could occur when calculating tax adjustments. The change ensures the system handles the scenario where all factors are zero, preventing a traceback and maintaining accurate financial calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
8 changes
Resolved issues and error corrections
This update fixes a discrepancy in the XML export of tax reports. Previously, the exported data didn't align with the report's data due to a mismatch in date calculations (invoice vs. reconciliation). This change ensures the XML export accurately reflects the data within the tax reports, improving data consistency and report accuracy.
Original PR description
## Issue: Invoices exported in the XML did not match the data in section D of the report for the same month The exported data should match the report ## Cause: XML export used the invoice dates (bills invoiced in the period), while the report data is based on the reconciliation entry dates This mismatch caused some invoices to be missing or incorrectly included in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779
This update fixes an issue where sorting of picking records was not functioning correctly due to a technical detail in how Odoo compares related data. The change ensures that picking records are sorted accurately, improving the reliability of inventory management processes. This resolves a potential inconsistency in how the system identifies and orders related records.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512
This update resolves a technical issue that was causing an error message during Razorpay payment processing within the Point of Sale (POS) system. The fix removes an unnecessary attempt to use 'sudo' on a specific object, ensuring smooth and reliable payment transactions for Indian users.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update optimizes the SQL query for the budget report, resulting in significantly faster performance, especially when dealing with large datasets. The change separates the query logic to allow for a more efficient join strategy, reducing processing time and improving report generation speed. This improves the overall user experience for financial reporting.
Original PR description
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862 Forward-Port-Of: odoo/enterprise#104299
This update resolves a problem where imported sales orders containing kit products were incorrectly splitting the order into multiple lots during the POS process. The change prevents this splitting behavior, ensuring accurate sales tracking for kit products, regardless of whether they are tracked by lots. This improves the reliability of the POS system.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update resolves an issue preventing stable IoT Box devices from sending data correctly. The system now correctly interprets data from these devices, ensuring reliable reporting and improved functionality. This change enhances the overall stability and performance of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104194 Forward-Port-Of: odoo/enterprise#104113
This update ensures that manually set currency rates on customer invoices (especially in German and Hungarian) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This fix maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update resolves an issue where canceling self-checkout orders scheduled for a future date didn't consistently remove them from the POS system. Now, cancellations are correctly applied in both the user interface and the POS, ensuring accurate order management. This improves the reliability of the self-checkout experience.
Original PR description
Before this fix, when we placed an order from the self-checkout with a preset slot for a future date, we weren't able to cancel it from the POS. The UI showed it as canceled, but after refreshing, the order was still there. Now, when we cancel an order scheduled for the future, it is correctly canceled both in the UI and in the POS. task : 5246089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
7 changes
New functionality added to Odoo
This update streamlines the creation of activities by aligning the 'Create Activity' server action with the existing Activity Schedule wizard. Users can now easily utilize activity plans, enhancing the scheduling and tracking of tasks within the system. This change improves usability and efficiency for managing workflows.
Original PR description
The aim of this commit is to make “Create activity” server actions type presented in a similar way than the activity schedule wizard. In addition to moving fields around in the form view, the ability to use an activity plan has been added. opw-4734968
Enhancements to existing features
This update adapts the HR sign module to align with changes in how activities are scheduled from server actions. Specifically, it incorporates a new parameter to dynamically assign responsibility for activities, ensuring HR sign workflows now correctly reflect activity plans created from server actions. This improves scheduling accuracy and efficiency.
Original PR description
Now that activity plans can be used to schedule activities from server actions, we need to adapt the hr_sign module accordingly. A new parameter to `_determine_responsible` is added in community to dynamically set the responsible assignment from the server actions. This commit adapts the enterprise modules to use this new parameter. Task id: opw-4734968
Resolved issues and error corrections
This update fixes an issue where unavailable products were still shown in the self-order system, often with a reduced opacity notice. Now, unavailable products are completely hidden from the product selection page, providing a cleaner and more intuitive user experience for self-order transactions. This simplifies the process for customers and staff.
Original PR description
Before this commit : 1. In the presets list view, the "available in self" setting was not available as a filter. 2. In the self, when products were not available, they were always displayed with an “out of stock” notice and reduced opacity. After this commit : 1. "Available in self" filter is now available in the presets list view 2. Now, when a product is not available, it is not shown in the products selection page. task-id: 5130687 note : fyi, preset popup part from the spec has been moved to this pr : https://github.com/odoo/odoo/pull/243180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a recurring issue that caused random errors during Odoo's tour process. By removing problematic assertions, the tour is now more reliable and stable, leading to a smoother user experience. This change focuses on internal improvements to the Odoo system.
Original PR description
With this commit, we remove synchrone assertions in steps that can cause random errors in tour. runbot-error-id~237552 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
Code cleanup and technical improvements
This update simplifies resource scheduling by removing the outdated 2-week calendar feature and streamlining how work hours are defined. The changes focus on clarity and accuracy, ensuring employees are tracked correctly based on their daily hours and work rates. This improves the reliability of time tracking data.
Original PR description
First part of the work: - Display required full time + work time rate in debug models - Always define the amount of hours per day - Remove the 2 week calendar feature - Remove the name and sequence task-5124688 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
This update simplifies resource scheduling by removing the outdated 2-week calendar feature and streamlining how working hours are defined. The changes focus on clarity and accuracy, ensuring resources are tracked with more precision for appointment and helpdesk scheduling.
Original PR description
First part of the work: - Display required full time + work time rate in debug models - Always define the amount of hours per day - Remove the 2 week calendar feature - Remove the name and sequence task-5124688
This pull request streamlines the way Odoo verifies payments across various payment providers. The changes involve a refactoring of the verification logic, enhancing reliability and efficiency. This update ensures more accurate and consistent payment confirmations for our users.
29 changes
Enhancements to existing features
This update enhances the command-line interface to allow users to update *all* installed Odoo modules with the latest versions. Previously, updating only the base module was possible, which could lead to unintended consequences. This change provides a safer and more comprehensive way to manage module updates.
Original PR description
Before this commit: Using the CLI, there is no practical way to update any modules with an updated version. Running: `$ odoo-bin module upgrade base --outdated` would not work as intended as it would…
Before this commit: Using the CLI, there is no practical way to update any modules with an updated version. Running: `$ odoo-bin module upgrade base --outdated` would not work as intended as it would check version change only on the `base` module. Even if it worked, this would update every module. This is not the point here as it could cause side effects if not used properly After this commit: Enhanced module update logic to support updating all installed modules when `all` is passed in the argument. Running: `$ odoo-bin module upgrade all --outdated` will update all modules for which the version has been updated Note: `all` keyword as been used to be coherent with `--update all` CLI command, see: https://www.odoo.com/documentation/19.0/developer/reference/cli.html#cmdoption-odoo-bin-u Documentation PR: odoo/documentation#15513 Extension from: https://github.com/odoo/odoo/pull/202571 Feature proposed on: https://github.com/odoo/odoo/pull/202571#discussion_r2128993414 Task [link](https://www.odoo.com/odoo/project.task/4585261) task-4585261
This update adjusts Odoo's payroll processing for Mexican employees earning at or below the minimum wage. It automatically exempts these employees from IMSS social security contributions, shifting the responsibility to the employer to cover those contributions. The update also ensures correct ISR (tax) calculations, especially when considering bonuses and commissions.
Original PR description
According to the Mexican Social Security Law, when an employee earns equal to or less than the monthly minimum wage (parameter: l10n_mx_daily_min_wage * 30.4), the employee is exempt from social security contributions (Rule: IMSS_EMPLOYEE_TOTAL). In such case: - It is the employer’s responsibility to cover the corresponding social security amount - It doesn't appear on the XML - The ISR it's also "0" - we need to consider bonuses and commissions. target: 19.0 task-5226971
This update adds a 'Reload Data' button to error dialogs in the Point of Sale system, providing users with a quick way to resolve common issues. Previously, users only had an 'Ok' button, making it difficult to recover from errors. This change reduces downtime and improves the overall user experience, particularly for Restaurant POS orders which will now attempt to sync before data reloading.
Original PR description
Purpose: ------------ - On Error dialogs, users only had "Ok" or could close the dialog, with no guidance on what to do next. - Many blocking issues are resolved simply by reloading POS data. Before this commit: ----------- - Error dialogs only had an "Ok" button. After this commit: ------------------ - Added a "Reload Data" button for quick recovery of common blocking issues. - Added a warning message in the reload data popup - For POS Restaurant, orders will attempt to sync before reloading data, reducing the risk of data loss. Task-5353590 Forward-Port-Of: odoo/odoo#238112
This update clarifies the labels and settings related to Peppol reception within Odoo Enterprise. It adjusts requirements based on a company's Peppol participation role and prevents unnecessary fields from being required for sending-only companies. This ensures more accurate and streamlined Peppol data handling.
Original PR description
In this commit: Clarify Peppol reception mode labels to better reflect actual behavior. Update Settings field requirements based on the Peppol participation role. Prevent document-related fields from being required when the company is configured as sending-only. Task-5438539 Co-authored: [Soham Zadafiya (soza)](soza@odoo.com)
This update simplifies the process of setting up Peppol integration within Odoo. The outdated wizard has been replaced with a more user-friendly interface, including a radio selection for registration type and a centralized location for the Peppol contact email. This change streamlines the setup and improves the overall user experience.
Original PR description
In this commit: - Deprecate the Peppol configuration wizard. - Move the Peppol contact email field to Settings. - Replace the wizard button with a radio selection for the Peppol registration type. - Simplify the overall Peppol settings user experience. Task-5438539 Co-authored: [Soham Zadafiya (soza)](soza@odoo.com)
Resolved issues and error corrections
This update fixes an issue where website location requests repeatedly failed for invalid warehouse addresses. Now, when geolocation fails for an address, it sets default coordinates, preventing endless attempts and improving the user experience. This ensures accurate location data is displayed on the website.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address.
This update fixes a display issue in the Point of Sale product information popup. Previously, it only showed the first tax applied to a product. Now, it correctly displays all taxes, separated by commas, providing a more accurate and complete view for sales transactions.
Original PR description
Before this commit: --- - The POS product info popup displayed only the first tax from `tax_details`, which meant multiple applied taxes were not visible. - The logic fetched a single tax name instead of all tax applied to the product. After this commit: --- - The POS store sends a full list of tax names instead of a single name. - The popup template displays all tax names, comma-separated. task-5406826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem in the payroll testing process where contract end dates weren't being calculated correctly. The fix ensures contracts automatically end after two years, aligning with standard payroll practices. This improves the reliability of payroll calculations and reporting.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` error-237945
This update resolves a technical issue that was preventing the generation of follow-up reports for certain customer records. It now automatically sets ‘no_followup’ for general customer entries, ensuring accurate reporting. This change improves the reliability of customer statement and follow-up report generation.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104500 Forward-Port-Of: odoo/enterprise#104433
This update resolves a critical issue where Odoo installations didn't consistently create foreign key relationships in the database. This resulted in 'Record missing' errors after data changes, potentially leading to data inconsistencies. Merging this fix guarantees that Odoo installs with properly configured database relationships, ensuring data integrity and preventing future errors.
Original PR description
---- Description of the issue/feature this PR addresses: See related OPW Ticket [opw-5495025](https://www.odoo.com/my/tasks/5495025) Current behavior before PR: Odoo seems to install correctly, and works normally. However the database consistency is not ensured. Foreign Keys are not created. User receives `Record missing` errors after some time, when there was a Contact deleted, for example. Issue is dangerous, because it can be latent and be undetected for weeks or months. Desired behavior after PR is merged: Odoo installs *with* the Foreign Keys, and works normally. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr --- Ticket opw-5495025
This update combines member and live chat information automatically when creating helpdesk tickets, particularly for website and WhatsApp channels. Previously, this data was displayed separately, now it's presented in a more unified and convenient way for support agents. This streamlines the support process and provides a more complete customer view.
Original PR description
*: website_helpdesk_livechat, whatsapp Task-5496830 https://github.com/odoo/odoo/pull/243864
This update ensures that live chat and member information panels automatically open when navigating between conversations. Previously, opening one panel would disable the other. Now, the live chat panel will always open by default, and member lists will automatically open for non-live chat conversations, improving user experience and efficiency.
Original PR description
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this…
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa. This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel. This commit fixes the issue as follow: - auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible - closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations Task-5496830 [1]: https://github.com/odoo/odoo/pull/238472 https://github.com/odoo/enterprise/pull/104435
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503
This update fixes an issue where receiving products with negative quantities (e.g., due to returns) incorrectly calculated the standard cost, leading to negative values. The change ensures the standard cost now uses the last receipt's unit cost when stock quantities are negative, preventing inaccurate cost reporting.
Original PR description
## Issue When doing a receipt with a different Unit Cost than the current one in negative quantity, the average cost would become aberrant. ## Steps to Reproduce - Create product P, Average Costing method, cost at 0 - Create & Validate a delivery for 10 unit of P - Create & Confirm a Purchase Order for 5 Units of 0 at *10 / Unit - Receive the 5 Units ==>> The product standard cost becomes $-10 ! This is because the system sees -5 Units on hand for a total of $50, and do the average. In Odoo 18, the Delivery would have been reevaluated to the receipt value, so the total value after the receipt would have been $0 for -5 Units. ## Solution When the product quantity is negative, we use the cost from the last receipt as the new average cost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that prevented users from editing event organizers or addresses within the website editor. The problem stemmed from an incorrectly formatted domain being passed to the system, causing a validation error. This fix ensures the website editor functions correctly when editing event details.
Original PR description
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed. **Steps to reproduce:** 1. Install `website_event`…
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.
**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.
**Error:**
`ValueError: Domain() invalid item in domain: ')'`
**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]:
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|',
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```
This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example:
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd',
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r',
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'",
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n',
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```
Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.
**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.
[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109
sentry-6916986959This update resolves a problem where scanning barcodes on picking orders with kit product variants would cause an error. The fix ensures that packaging information is correctly captured during barcode scans, allowing for accurate tracking of kit components.
Original PR description
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration.…
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration. 2. Create a product, that as a least 2 variants. 3. Add a packaging to one of the variants. 4. Create a BoM for created product (kit type). 5. Create a picking order for the variant with packaging. 6. Print the picking operation to scan the code through barcode. 7. Go to barcode and try to scan it, this will trigger the traceback. ### Cause of the issue: Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data: https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91 _get_stock_barcode_data will obtain the packaging methode for the products. https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16 since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information. ### Fix: We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids: https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441 our fix will allow for packaging in the variant to be considered when there is more than only one variant. opw-4852875 Forward-Port-Of: odoo/enterprise#103256 Forward-Port-Of: odoo/enterprise#87867
This update prevents notifications for other recipients from being incorrectly marked as 'bounced' when a single bounce notification is received. The fix addresses a technical issue where an outdated search domain incorrectly matched all notifications linked to a message, leading to inaccurate bounce reporting. This ensures more reliable notification tracking.
Original PR description
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an…
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an incoming mail server with a bounce alias. 2. Create multiple contacts with different email addresses. 3. Send a message that notifies multiple contacts. 4. Process a bounce email related to only one recipient. 5. Observe that notifications for other recipients of the same message are also marked as “bounced”. Root Cause: During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated. The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient. Fix: The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present. opw-5349170
This update resolves a problem that prevented the tax module from correctly loading during Odoo upgrades. The fix disables tracking computations during the module's loading process, preventing errors that caused the upgrade to fail. This ensures smoother and more reliable Odoo upgrades.
Original PR description
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py…
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.
```py
/home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```
Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.
```py
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
tracking = records.with_context(context)._message_track(fnames, initial_values)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
record._message_log(
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```
This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae
The resulting tracking computation crashes with a KeyError when processing repartition line diffs.
Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.
opw-5467986
upg-3753990
tbg-2380
Forward-Port-Of: odoo/enterprise#103931This update ensures that Odoo accurately flags modules imported with demo data. This improvement will enhance the reliability of industry testing by providing clearer information about which modules were initially populated with demo content. It resolves a previous oversight that impacted testing processes.
Original PR description
Currently even if a imported module was imported with demo data, the 'demo' field is not set to True. Setting this field proprely will allow to have a better handling of demo data in industry tests. Backport of https://github.com/odoo/odoo/pull/243032
This update resolves an issue where a deleted floor would reappear in the floor selector after a refund was processed on a related order. The fix filters out inactive floors, ensuring the floor selector accurately reflects available tables and improving the user experience. This prevents confusion and ensures data consistency.
Original PR description
Task: [#5421683](https://www.odoo.com/odoo/project/1737/tasks/5421683) --- **Steps to reproduce:** * Create a new floor with one table * Create and pay an order on that table * Delete the floor * Refund one line of the order ==> The deleted floor is shown again in the floor selector, without its table. This happens because the deleted floor is loaded when fetching the table of the order in the Ticket Screen. If an order is linked to a table that belonged to a deleted floor, that floor is loaded again and displayed in the floor selector. **Fix:** Filter out inactive floors from the floor selector.
This update resolves an issue where users received an error when attempting to unbuild tracked components in a manufacturing order. The fix ensures that component serial numbers are not reused, preventing validation errors and ensuring accurate inventory tracking. This improves the reliability of the manufacturing process.
Original PR description
Steps to reproduce the bug: - Create a storable product P1 - Tracking: Serial Number - BoM: Component: 1 unit of C1, tracked by Serial Number - Update the inventory of C1 - 1 unit with SN1 - 1 unit…
Steps to reproduce the bug:
- Create a storable product P1
- Tracking: Serial Number
- BoM: Component: 1 unit of C1, tracked by Serial Number
- Update the inventory of C1
- 1 unit with SN1
- 1 unit with SN2
- Create a Manufacturing Order to produce 2 units of P1
- Confirm and validate the MO using serials SN1-P1 and SN2-P1
- SN1 and SN2 of C1 are consumed
- Unbuild 1 unit of P1 with serial SN1-P1 Result: SN1 of C1 is correctly restored
- Unbuild 1 unit of P1 with serial SN2-P1
- Try to validate the unbuild
Problem:
A user error is raised:
"The serial number SN1 has already been assigned"
This happens because _action_unbuild attempts to reuse the same component serial number (SN1 of C1) without checking whether it has already been consumed by a previous unbuild operation on the same Manufacturing Order.
Solution:
This fix ensures that, when unbuilding tracked products, component serial numbers already used by previous unbuilds of the same MO are excluded from the candidate move lines.
This prevents reassigning the same serial number multiple times and avoids the validation error.
opw-5441256This update resolves an issue where Point of Sale orders with custom sequence prefixes were generating errors due to data type mismatches. The fix ensures that sequence numbers, including custom prefixes, are correctly stored and used, preventing order processing failures. This improves the stability and reliability of the POS system.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575
This update fixes a problem where customers couldn't change product selections in the Point of Sale configurator when multiple attribute combinations were restricted. The issue was previously resolved but reintroduced. The fix removes code that incorrectly disabled options, allowing customers to freely select their desired product combinations.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where cash order creation was missing essential information like company and user details. Previously, orders weren't properly linked, leading to potential data discrepancies. This change ensures cash orders are created with accurate context, improving order tracking and reporting within the Point of Sale system.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a scheduling issue in the autovacuum cron job that was causing delays in database maintenance. The change ensures the cron job correctly reports partial progress, triggering a faster reschedule. Additionally, the code has been simplified for better readability.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. 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#216116
This update fixes a display issue where tax names and invoice labels were shown in English for Vietnamese users. By adding the necessary Vietnamese translation columns to the chart template CSV, the system now correctly displays tax information in Vietnamese, improving the user experience for Vietnamese-speaking businesses.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#242437 Forward-Port-Of: odoo/odoo#236502
This update resolves a problem where imported sales orders containing kit products were incorrectly splitting the order into multiple lots during the POS process. The change prevents this splitting behavior, ensuring accurate sales tracking for kit products. This improves the reliability of our POS system.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update fixes a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it’s correctly linked to the Euro (EUR) to reflect Bulgaria’s adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for businesses operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects an issue where payslip names were not being generated accurately for the Swiss (l10n_ch_hr_payroll) version of Odoo. The fix ensures that payslip names are now correctly formatted and displayed, improving the accuracy of payroll reports and data.
Original PR description
Forward-Port-Of: odoo/enterprise#104289
15 changes
Enhancements to existing features
This update enhances the testing process for invoice payments, specifically when using bank statement lines. A new test helper has been introduced to streamline and standardize these tests, ensuring more reliable payment processing scenarios. This improves the overall accuracy and stability of invoice payments.
Resolved issues and error corrections
This update resolves an issue where tables inserted into the To-Do editor appeared after the existing text instead of before it. The fix streamlines the table insertion process, ensuring tables are placed correctly at the desired cursor position. This improves the user experience and prevents formatting inconsistencies.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a warning about eTIMS configuration was incorrectly displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to Kenyan companies, improving the user experience and preventing unnecessary alerts.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558
This update corrects a bug where adding a payment line after editing a payment line on the POS receipt would create a duplicate payment line. The fix ensures that changes are applied correctly, preventing the duplication and ensuring accurate receipt display. This improves the user experience when modifying payments during the order process.
Original PR description
Steps to reproduce ------------------ 1. Make an order with a single payment method, say Bank, with amount X 2. On the receipt screen, click "Edit Payment", the modal will open 3. On the payment tab,…
Steps to reproduce
------------------
1. Make an order with a single payment method, say Bank, with amount X
2. On the receipt screen, click "Edit Payment", the modal will open
3. On the payment tab, change the amount of the current payment line to X - Y
4. Add another payment line with a different with amount Y, so the total is X
5. Save the edits
Notice that on the receipt, instead of seeing 2 lines, the edited one and the newly added one, we see 3 lines: the old edited line as expected, but we see the new line twice, it's duplicated!!
The reason
----------
When saving the changes, we call `await this.data.read("pos.order", [record.evalContext.id]);` [1] which adds the new payment line to the order in the cache, the old one and also the new one. When doing so, we assign a `uuid` to that new line since it's the first time we encounter it in the data_service. [2], but we don't save this new uuid to the backend yet, that will be important! Till here all is good. We will refer to this as step 1.
Now in step 2, we call `await this.data.read("pos.payment",` [3] to apply the updates to the existing payment lines, but as argument we're passing the two lines not just the old one, so we are refetching both lines, and we see that the new line doesn't have a `uuid` (since the above uuid was not saved to backend!!), so we think it's another new payment line and we link it again to the order, so we end up with 3 lines on that order.
The fix
-------
We only need to apply the udpates for the old lines in step 2, since the new ones are already updated in the cache by step 1.
[1]: https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/point_of_sale/static/src/app/store/pos_store.js#L1934
[2]: https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/point_of_sale/static/src/app/models/related_models.js#L497
[3]: https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/point_of_sale/static/src/app/store/pos_store.js#L1935-L1938
opw-5317680This update ensures that payment rounding is applied accurately when settling customer dues, regardless of the payment method used (cash or bank). Previously, rounding was incorrectly applied to bank payments, leading to inaccurate amounts. This change aligns rounding with the selected payment method, ensuring correct calculations for due payments.
Original PR description
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the…
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27. 3. Close the session and reopen it, then select that customer, and click settle due 4. Select the Bank payment method, so a NON-Cash payment method. Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27. That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round. The fix ------- Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings. We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method. opw-5222985
This update resolves an issue where certain carriers weren't correctly recognized when selecting shipping partners. The change ensures that all carriers are compatible, leading to more accurate shipping calculations and order processing. This improves the reliability of the website's shipping functionality.
This update resolves an issue where multiple scheduled activities weren't consistently linked to the correct project plan. The change ensures that when a task has multiple schedulers, it correctly assigns the appropriate plan, improving the accuracy of project tracking and reporting. This fix enhances the reliability of our scheduling functionality.
Original PR description
Description of the issue/feature this PR addresses: Same pattern as in https://github.com/odoo/odoo/pull/189843 but for _compute_plan_id method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, streamlining the process and preventing a traceback. This ensures SAFT exports function correctly for all Austrian businesses.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear This fw port includes an other modification: the check 'missing_company_contact' was performed twice, one time in the account_saft module, and the second time in l10n_at_saft. So we removed it from the second module This check make sure the company partner has at least 1 child (1 contact) no-task Forward-Port-Of: odoo/enterprise#104144
This update resolves a problem where imported sales orders containing kit products (tracked by lots) were causing errors in the Point of Sale (POS) system. The change prevents the system from incorrectly splitting these orders into multiple lots, ensuring smoother POS transactions. This improves the reliability of sales processing.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update fixes an issue where the available quantity displayed on rental product pages was incorrect when 'continue selling' was enabled. The system was failing to account for the selected rental period, leading to an inaccurate stock count. This change ensures customers see the correct availability when renting products.
Original PR description
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product…
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product tracked in stock with a quantity of 5 - Enable "continue selling" and "show available quantity below 10" - Go to the ecommerce page of this product - Rent 3 units for a given period, confirm and pay - Return to the ecommerce product page -> Whatever the selected renting period, the displayed quantity is always 2 **Cause**: The website displays `free_qty`: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15 `free_qty` is computed in: https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36 which leads to: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10 and ultimately relies on: https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213 This computation does not take the selected renting period into account. There is a period-aware computation here: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1 but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled). opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)
This update resolves an error that occurred when users removed the start date of a leave record and assigned a resource linked to an employee. The fix ensures the system correctly calculates the calendar ID for leave records, regardless of whether the contract has a start date, improving data accuracy and preventing unexpected errors.
Original PR description
Currently, an error occurs when user sets the resource on a resource leave. **Steps to Reproduce:** - Install `hr_contract` with demo data. - Go to `Resource Time Off`. - Create a new record and…
Currently, an error occurs when user sets the resource on a resource leave. **Steps to Reproduce:** - Install `hr_contract` with demo data. - Go to `Resource Time Off`. - Create a new record and remove the `start date` value. - Select the `Anita Oliver` resource `(employee record with running contract)`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error. Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract. **Fix:** This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly. [1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17 [2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29 **No Task ID** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, with the adoption of the Euro on January 1, 2026, Bulgaria is correctly linked to the Euro (EUR) within Odoo's system. This ensures accurate financial reporting and data for businesses operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects a critical issue where Moroccan tax reports incorrectly reported all bills based on a standard period, rather than the cash basis system. The fix utilizes a new SQL query to accurately calculate taxes, ensuring data consistency and improving export efficiency. This resolves data discrepancies and provides more reliable tax reporting.
Original PR description
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that,…
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data. Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779 [IMP] l10n_ma_reports: call the report to compute the prorata value Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.
This update enhances the security of our web service connections by allowing us to securely verify server identities using certificate records. Previously, our system struggled to utilize certificate verification due to limitations in the underlying software. This change adds a robust mechanism to manage and utilize certificate stores, strengthening security protocols.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741
This update addresses several minor issues within the l10n_hr_edi module, primarily focused on improving the reliability and user experience of fiscal document processing and approval workflows. Specifically, it enhances error handling and clarifies settings related to multi-company operations, ensuring smoother and more accurate HR and accounting processes.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Enhancements to existing features
This change updates the source of lead mining data within Odoo from Clearbit to Dun & Bradstreet. This aligns with existing data usage for partner autocomplete and ensures we're leveraging a reliable provider for improved lead insights. This update is part of a larger IAP migration.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238
Resolved issues and error corrections
This update fixes a usability issue where the barcode on customer receipts was too narrow, making it difficult for staff to scan. The barcode width has been increased to ensure reliable scanning and streamline the order fulfillment process. This change enhances the overall customer experience.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="451" height="508" alt="image" src="https://github.com/user-attachments/assets/a0d1e95e-0a9d-4552-977a-0ad9686867b8" /> </td> <td> <img width="456" height="517" alt="image" src="https://github.com/user-attachments/assets/40d04ac4-9ffc-4f81-a063-31b3ea26b4e1" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the payer company was incorrectly identified in the 1099 report CSV file when multiple companies were involved. The fix ensures that each 1099 vendor is accurately assigned to the correct company, improving the accuracy of tax reporting. This resolves a previous error impacting multi-company reporting.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190