Daily updates from Odoo
Wednesday, April 16, 2025
19 changes
1 change
Resolved issues and error corrections
Website form submissions that contain hidden NUL characters are now handled gracefully instead of causing an error. This helps prevent failed submissions and improves reliability for visitors using website forms.
Original PR description
This error often occurs when the data submitted through forms contains NUL characters. Error: ``ValueError: A string literal cannot contain NUL (0x00) characters.`` This commit will catch ValueError when the data with NUL characters is submitted through forms. sentry-5049576227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
This update adjusts Odoo spreadsheet features to stay compatible with recent spreadsheet engine changes. It improves chart, pivot table, comments, and field synchronization behavior, including restoring scrolling in read-only pivot panels.
Original PR description
This commit contains adaptations following the o-spreadsheet update. See https://github.com/odoo/odoo/pull/206102
Fixed an issue in Documents where duplicating a selected document could make the browser tab stop responding. The selection now stays focused correctly after duplication, improving reliability for users working with documents.
Original PR description
Reproduce: 1. Open Documents 2. Select a document 3. Duplicate it 4. Close your now non-responsive tab... Updating a state inside onWillUpdateProps triggered a new rendering cycle, where the `list` prop was different each time, and thus looped. Also, we do not change folder (after duplication for example), we must keep focus on the selection and not switch to the containing folder. Task-4717552
Public website visitors now see the intended custom placeholder images for appointment-related products when no product image is set. This avoids fallback to a generic image and keeps appointment and sale pages visually consistent.
Original PR description
Placeholders were introduced in odoo/odoo@c52453f for meta products such as discounts, gift cards, event tickets, and appointments. Previously, access rights prevented public users from viewing these placeholders. Even when no image was linked to a record, access was denied due to read restrictions, defaulting to the generic placeholder instead of the custom one provided by `_get_product_placeholder_filename`. This commit overrides `_can_return_content` in relevant modules to allow proper access for public users, ensuring the intended placeholder is displayed. See also: - https://github.com/odoo/odoo/pull/205693
15 changes
Resolved issues and error corrections
Point of Sale now calculates customer change correctly when prices include tax and cash rounding is set to round up. This prevents cashiers from giving the wrong change in affected payment scenarios.
Original PR description
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it…
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be. **Steps to reproduce:** - Open point Of Sale/Configuration/Taxes - Create a new tax, with an amount of 7% - In the Advanced option tab set "Included In Price" to "Tax Included" - Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax" - Create a product B with a Sales Price of 42$ and select the tax you created as the "Sales tax" - Open Accounting/Configuration/Management/Cash Roundings and create a new rounding - As Rounding Precision select 1.00 (the bug can happen also with other values here) - Set Rounding Strategy as "Add a rounding line" - Set Rounding Method to "Up" - Open the point of Sale app and open a store - Select one product A and two product B in the order - Click on payment and Cash - Enter a cash value of 200$ **Current behavior:** The Change has a value of 20 **Expected behavior:** The change should have a value of 21 **Cause of the issue:** In account_tax.js tax_totals_summary.base_amount_currency takes the values of values.total_excluded_currency https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L871 values.total_excluded_currency is computed as the sum of two floats With the values of our steps it creates a floating-point rounding error (the value is 88.79+78.50=167.29000000000002 and the rounding error is 0.00000000000002) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1166 tax_totals_summary.base_amount_currency is then used in another float addition to compute total_amount_currency.Because it's the second float addition the rounding error increases. (the value calculated is 167.29000000000002+11.71=179.00000000000003 and now the rounding error is 0.00000000000003) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1011 total_amount_currency is then used in pos_order.js to compute the remaining https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L157 https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L161 The remaining is used inside of the get_change method https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L887 this 0.00000000000003 rounding error has propagated to there and the value is 20.99999999999997 instead of 21 Because the rounding error comes from two consecutive float addition it's too big to be compensated by epsilon (here epsilon has a value of 1.8651746813702624e-14 which brings the value to 20.99999999999999) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/web/static/src/core/utils/numbers.js#L71 Consequently when it's rounded down (the inversion from up to down is because the change value is negative) it's rounded to 20 instead of 21 **Fix:** Because this rounding mistake only appears with the value of "remaining" I added a rounding inside getRoundedRemaining before applying any customized rounding method. opw-4615638 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
Users can now duplicate several payment terms at once from the Invoicing list view without triggering an error. This keeps bulk setup and maintenance of payment terms working smoothly.
Original PR description
Currently, an error occurs when a user tries to duplicate more than one payment term at once from the list view. **Steps to produce:** - Install the `account` module. - Navigate to `Invoicing > Payment Terms` (list view). - Select at least two records and duplicate them. - Observe the error. `ValueError - Expected singleton: account.payment.term(3, 4, 5, 6, 7, 8, 9, 10)` An error occurs because the **copy** method accesses `self.name`, assuming a single record, when multiple records are duplicated, causing the `ValueError`. [1] - https://github.com/odoo/odoo/blob/6b970a0bfbcdac92d05389aac994c0db36730a34/addons/account/models/account_payment_term.py#L270 This commit ensures that each duplicated payment term has its name individually updated after being copied. Sentry - 6531350963
The payment provider test setup was adjusted so Worldline and AsiaPay no longer depend on accounting-only test data. This prevents failures when testing community-only installations where the accounting app is not installed.
Original PR description
It doesn't seem to be of any use, and neither module depends on account. It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve. If you only have community tho, it blows up in your face. Which I guess is what happens in the single app tests. https://runbot.odoo.com/odoo/error/163117
Unarchiving a company now correctly refreshes the related company access information for users. This prevents errors when users try to open accounting records, such as charts of accounts, after a company has been restored.
Original PR description
Issue: When a company is unarchived, the cache for some fields are not updated. Steps to reproduce: - create company b - archive company b - access CoA - unarchive company b - try to access specific chart of account, error will be raised Purpose of this PR: when we unarchive a company we call the `_get_company_ids` method on the user to update the cache. opw-4427576
This fix adjusts payment-related tests so they only run checks when the optional supporting apps they rely on are installed. It helps avoid false test failures and keeps development and release validation smoother without changing customer-facing payment behavior.
Original PR description
`payment` does not depend on `account`, it thus can't unconditionally use `account` groups. Skip tests if `account` is not installed (matches `account_custom` behaviour). `account_custom` does not depend on `product`, so can't use `product.product` unconditionally. `setUpClass` doesn't seem useful so just remove it entirely.
Peppol demo mode has been adjusted to behave more like the production service. This helps teams test electronic invoicing scenarios with more realistic results before using Peppol in live operations.
Original PR description
… behavior Fix the demo mode of Peppol to be closer to the behavior in production. task-no (review with TSB/PMAX 31/03/25)
This fixes an error that blocked users from creating a debit note from an existing credit note in Latin American invoicing flows. Businesses can now correct an incorrect credit note directly, reducing manual work and avoiding interruptions in localized accounting processes.
Original PR description
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo…
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. ### Steps to reproduce the error. 1. Install the Argentine localization 2. Create an invoice and post it 3. From the invoice using the wizard create a credit note and post it. 4. From the credit note open the wizard to create a debit note. 5. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. ### Current behavior before PR: When creating a debit note from a credit note get an error. ### Desired behavior after PR is merged: We can create a debit memo from a credit note. Adhoc tiket 69428 - 69854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now keeps unavailable pricelists, categories, and products hidden when paid orders are loaded. This prevents staff from seeing or selecting items that should be restricted, keeping the register interface aligned with configured limits.
Original PR description
Before this commit, when limited categories were enabled and a limited pricelist was selected, loading the paid orders caused unavailable categories, pricelists, and products to appear in the PoS interface. This commit filters out these non-available items even if they are loaded, ensuring that only valid data is shown. opw-4629843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users now get a clearer warning when they try to create a bank account that already exists but was archived. This avoids a confusing uniqueness error and updates activity history wording from deleted to archived, matching what actually happens.
Original PR description
Commit ebb09234e6444576e7e934f53de1d23a0d9760d2 made it so that bank account are archived instead of deleted meaning that they are never deleted in the DB. If a user tries to create a new bank account for the same partner with the same account number, the following validation error is raised: "The operation cannot be completed: The combination Account Number/Partner must be unique." This commit introduces a new UserError when a user attempts to create an account that was previously archived. It also updates the message in the chatter from "deleted" to "archived." opw-4669340 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clearing the description from a section line on an invoice no longer causes an error. This prevents interruptions while editing invoices and keeps the invoicing workflow stable.
Original PR description
This error occurs when a user `adds a section` in an `invoice line`, enters a description, and then remove the description. Step to reproduce : - Install module `Invoicing`. - Create a `new Invoice`. - In the Invoice Line, `add a section`. - Enter a description and save. - Remove the description and click anywhere on the screen. KeyError: `name` This error occurs when the system tries to update an invoice line section but the `name` field is missing from the update values, causing a KeyError. This commit fixes the issue by using optional chaining and nullish coalescing to ensure productName returns an empty string instead of undefined. Sentry - 6327760196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes test setup problems in the Sales Manufacturing area by avoiding attempts to fill fields that are hidden in certain scenarios. It helps keep automated checks reliable as test coverage expands across all modules, reducing noise from false failures.
Original PR description
Revealed by the changes to single app tests (which now test every module). While at it, remove a few unnecessary setting of product-id on non-variant scenarios, they don't blow up but they look a lot like odoo/odoo#206050 and why bother? https://runbot.odoo.com/odoo/error/163244
This update fixes two issues: customer details from UrbanPiper orders now refresh correctly when the same phone number is reused, and Mexican EDI documents can correctly read fiscal folio data from longer uploaded XML files. This helps keep customer records accurate and prevents missing fiscal identifiers on payment documents.
Fixes an issue where uploading longer Mexican Payment 2.0 XML files could leave the Fiscal Folio blank. The system now reads the full XML content instead of a file-size placeholder, ensuring the document identifier is extracted correctly.
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487
Orders coming from the same phone number now refresh the customer's name and address when those details change. This helps restaurants and delivery operations keep customer records accurate and avoid sending orders to outdated addresses.
Original PR description
Before this commit: ======================== - The customer name was not updated when an order was received from the same phone number but with a different name. - If the ZIP code remained the same, changes in the address were not reflected in Odoo. After this commit: ======================== - The customer name is now updated if it differs, even when the phone number is the same. - Address updates are now applied in Odoo, even if the ZIP code has not changed. --- task - 4714559
This fixes an error that could appear when exporting the XML file for the Italian tax return. The export now uses the correct process depending on whether it is run from the tax report or from the closing entry, helping users complete the required filing without interruption.
Original PR description
Since https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc , a traceback shows up when exporting the xml of the italian tax return. It was fixing a traceback on the closing entry export which was not usable in the report itself an created another issue there. This fix makes the method chosen depend on wether we are in the report or the closing entry. no-task