Tuesday, December 23, 2025
17 changes · 18.0
Enhancements to existing features
This update adjusts the size of the QR code displayed in Odoo Point of Sale to ensure it's easily visible to customers. The change aligns the QR code size with other Odoo pop-up windows, enhancing the overall user experience. This improves customer engagement and simplifies the process of scanning payment information.
Original PR description
**Description of the issue/feature this PR addresses:** QR code generated for customer display in Odoo POS is considered too small, therefore need size adjustment for enhanced visibility and user experience. Sizing is adjusted to be more uniformed with the backend popup. task-[5262218](https://www.odoo.com/odoo/project.task/5262218) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a random error in how Odoo validates accounting formulas. Previously, the validation process could incorrectly flag correct formulas as invalid due to an issue with how tokens were processed. Sorting the tokens by length ensures formulas are consistently and accurately evaluated, preventing this unexpected behavior.
Original PR description
…me tokens greedily Fixes issue #241004 Description of the issue/feature this PR addresses: This is a hard to reproduce bug becase it depends in what order the set is iterated. Since the set is an…
…me tokens greedily Fixes issue #241004 Description of the issue/feature this PR addresses: This is a hard to reproduce bug becase it depends in what order the set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this: The _check_formula in this module iterates over tokens to check if the formula only includes allowed tokens or numbers. This check passes when the set is iterated in a way that the token '>=' appears before the '>' token. But if it is the other way around, the check fails. This is because the way the tokens are consumed in the for; if the '>' is before the '>=', the '>' token will be consumed, the position will be advance one position forward and the next character found will be just the '=' character. This is not an allowed token and the check fails. The way to solve this is to sort the set by length of the token, from longest to shortest. This assures a greedy consumption of token, which is what is needed to avoid this bug. Current behavior before PR: The _check_formula randomly marks a correct formula as malformed Desired behavior after PR is merged: Using >= or <= should never cause a formula to be marked as malformed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request confirms that the developer has signed a Corporate License Agreement (CLA) for contributions to Odoo. This ensures compliance with Odoo's open-source licensing and legal requirements. The change is a standard CLA signature confirmation.
Original PR description
@pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical error that prevented studio exports from completing successfully. The issue stemmed from accessing single values across multiple partner records, leading to a system error. The fix ensures data is processed correctly during export operations.
Original PR description
An error occurs when the system tries to access single values `(of available_peppol_eas)` from multiple records at [1] during a studio export. Link [1]: https://github.com/odoo/odoo/blob/1ff538bfefb9b5342335b37e5de163d97f270258/addons/account_peppol/models/res_partner.py#L64 `ValueError: Expected singleton: res.partner(15, 27, 34, 28, 10, 36, 19)` To resolve this issue, use an iteration(for loop) to iterate records one by one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a misleading error message displayed when deleting sale orders with associated appointments. Previously, users received an incorrect instruction to reduce order quantities. Now, the system correctly informs users they must cancel the order before deletion, aligning with expected business processes. This ensures a smoother user experience and prevents confusion.
Original PR description
Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.…
Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed. Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion. Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed: "You can not delete a sent quotation or a confirmed sales order. You must first cancel it." Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed: "Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead." Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and enable "Up-front payment" 3. On the website, book an appointment for dental care and proceed to payment 4. Delete the sale order with the booking 5. Observe the incorrect error message being displayed opw-5092349 Forward-Port-Of: odoo/enterprise#100371
This update corrects a technical issue that was causing a traceback when verifying Peppol connections for Danish companies. The fix ensures that the system correctly handles the newer NAPTR verification method used by Peppol, preventing errors and maintaining accurate data processing. This improves the stability and reliability of the Danish Peppol integration.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes a traceback when called from `_get_peppol_verification_state` in `account_peppol` since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. Note that the code is executed when `self._deduce_country_code() == 'DK'. Which is supposed to happen for all Danish partners (and will probably also happen for all other partners since `_get_peppol_verification_state` is `api.model`) This commit updates the code to be the same as in `account_peppol`. The function is not removed for stable compliance. Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123
This update fixes a technical error that was causing a traceback when using the Peppol integration for Danish companies. The fix ensures compatibility with the latest Peppol standards by updating a function to call the parent module's logic. This ensures smooth operation for customers using the 'DK Company' option.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes a traceback when called from `_get_peppol_verification_state` in `account_peppol` since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. Note that the module does not depend on `account_peppol` strictly speaking but it is auto-installed due to the dependenciies. This commit updates the code to just call the `super()` function (so `account_peppol`) in case peppol is installed. The function is not removed for stable compliance. Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123
This update fixes an issue where the ClickEverywhere function would incorrectly test all applications after a page reload. Now, the specific application being tested is stored and retained, ensuring ClickEverywhere functions as intended and avoids unnecessary testing. This improves the stability and efficiency of automated testing.
Original PR description
The clickEverywhere function can be executed with one app. To accomplish this, the xmlID should be passed as a parameter to the function. Before this commit, the xmlID of the requested application was not stored in the status of the current execution saved in localStorage. If a reload occurs while the clickEverywhere function is executing, it will lose this information and continue testing all applications instead of only the requested one. runbot.build.error: 234747
This update resolves a recurring test failure in the MRP module. The fix creates the leave manually, providing a more reliable and deterministic test environment. This ensures consistent test results and reduces the need for manual intervention.
Original PR description
Before this commit: Introduced in https://github.com/odoo/odoo/commit/d06dcfbca96273b540c87252b9188603879ac1b4, the test was failing on runbot in some cases. The issue is deterministic, but requires a specific set of modules installed to fail. After this commit: Use a more robust approach in the test, by creating the leave manually instead of computing the number of operations needed. runbot-234638
This update resolves a technical issue related to Peppol document support within the DK Company integration. The outdated CNAME logic has been removed, aligning with current Peppol standards (NAPTR) and preventing a traceback error. This ensures proper Peppol functionality for Danish customers.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes an issue since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. This commit removes the function - It does not do anything different than the version in `account_peppol` (and it would cause issues if it did) - The function is only called in `account_peppol` - The module does not depend on `account_peppol` Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123
This update enhances how the IoT Box's IP address is determined. Previously, it relied on a public DNS server, which failed when the IoT Box was connected to a router without internet access. Now, the system uses the gateway's connection to reliably obtain the IP address, even in offline scenarios.
Original PR description
To get the local IP address of the IoT Box, we used to create a connection to a public DNS server and parsed the output to get the source of the request (our IP). In case the IoT Box is connected to a router, but the router isn't connected to the internet, our solution fails. We now create the connection to the gateway instead, so it can work offline.
This update resolves an issue where the Point of Sale tour would fail when selecting products with configuration options. The fix ensures the tour only selects products without configuration, improving the tour's reliability and user experience. This prevents tour interruptions and ensures a smoother workflow for users.
Original PR description
In certain cases, the product selected in the tour would be a product that require a configuration (having attribute lines), which would lead opening a popup that is not handled in the tour, leading to a failure. When selecting the product we now make sure that we select a product that does not require any configuration. runbot-234734
This update improves the Point of Sale interface by allowing users to copy error messages from the popup window. Previously, users couldn't easily copy these messages for reporting or troubleshooting. This change simplifies the process of resolving POS issues and provides more accessible support information.
Original PR description
Before this commit, it was not possible to select and copy text from the error popup shown in the POS interface. This limitation hindered users from easily copying error messages for reporting or troubleshooting purposes. task-id: 5411067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that occurred when changing the currency of a bank journal. The issue stemmed from having multiple payment method lines with different payment accounts, leading to a system error. This fix ensures accurate currency conversions and prevents data inconsistencies during journal updates.
Original PR description
036530a8983e485ac1ad0b9444a6aba01caabc07 introduced a bug, because it can happen to have 2 (or more) payment method lines from the same payment method. If these PML have differents payment accounts, we get a singleton error. Steps: - On Bank journal, add a new outbound payment method line, which use the same payment method as the first default one (it should be 'Manual') - Set two different payment account for each line - Then change the currency of the journal -> Traceback (singleton error) opw-5384042
This update corrects a minor issue within the Web Studio report editor, ensuring accurate data processing during report creation. The fix resolves a confusion in how the system identifies the report's editing state, preventing potential errors and improving the overall reliability of the report editor. This ensures reports are created and displayed correctly.
Original PR description
Issue: getQwebVariables returns isEditingFooterHeader, but isInHeaderFooter was read from it Cause of the issue: e2eed2b71647de29905bcc1a40c3c540d2a87e47 Forward-Port-Of: odoo/enterprise#102543
This update expands the support for the ‘itsme’ authentication system to align with the official coverage provided by itsme-id.com. This ensures Odoo Enterprise can process sign-ups from a wider range of countries, improving user access and compliance with current regulations.
Original PR description
Extend itsme availability beyond BE and NL to match the official itsme coverage: https://www.itsme-id.com/en-BE/business/coverage task-5424818 Forward-Port-Of: odoo/enterprise#102423
This update ensures that product packaging quantities are rounded correctly for kit products, aligning the behavior with non-kit products. Previously, kit products didn't round packaging, leading to discrepancies in delivery slips. This change improves accuracy and consistency in order fulfillment.
Original PR description
Problem: There is no rounding done for the packaging quantity computation for kit products. This is inconsistent with non-kit products as we call _compute_qty and round. Purpose: This will properly…
Problem: There is no rounding done for the packaging quantity computation for kit products. This is inconsistent with non-kit products as we call _compute_qty and round. Purpose: This will properly round the kit quantity and make the behavior consistent with the non-kit products. Steps to Reproduce on Runbot: 1. Enable product packages and display lots on delivery slips. 2. Create a kit product. 3. On the kit product create a product package that holds 9 units. 4. Create a component product and make it tracked by lots. 5. On the component product create one lot with 9.0 units and a second lot with 12.6 units. 6. Create a kit type BoM for the kit product and add the component product with a quantity of 0.1 units. 7. Create a sale order for 216 units of the kit product, which will use 24 packages. 8. Validate the receipt and print the delivery slip. 9. Observe that the delivery slip shows 13 packages used for the 12.6 units instead of 14. opw-5258735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239950