Daily updates from Odoo
Tuesday, April 21, 2026
42 changes · saas-19.1
Enhancements to existing features
This change reduces the time needed to validate large stock transfers by batching several database operations instead of repeating them one by one. It matters because pickings with many lines should complete much more reliably and avoid timeouts.
Original PR description
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for…
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids. This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings. Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the `purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s). Benchmarks: | No. move lines in delivery | Before | After | | -------------------------- | ------- | ----- | | 7579 | Timeout | < 200 s | opw-5826905 Forward-Port-Of: odoo/enterprise#110587 Forward-Port-Of: odoo/enterprise#110153
Inventory valuation for older dates now checks stock quantities using a narrower set of products at a time. This reduces unnecessary work on large databases and makes valuation calculations complete much faster, while keeping the same results.
Original PR description
When computing Inventory Valuation with a past `As of` date for AVCO products, `_run_average_batch()` reads `qty_available` for each manual `product.value` entry with `product.with_context(to_date=manual_value.date).qty_available`. On large databases, products can carry a broad prefetch set through the `product.value` browsing path. As a result, each distinct `to_date` may compute `qty_available` for more products than necessary. This change narrows the prefetch ids to the products sharing the same manual value date before reading `qty_available`. This keeps the same `to_date`, the same quantity computation, and the same per-product result, while reducing the amount of historical quantity computation done for each date. | Stock moves | Before PR | After PR | | --- | ---: | ---: | | 785k | fails after ~900s | 183s | opw-5944584 Forward-Port-Of: odoo/odoo#256684
Resolved issues and error corrections
This fix prevents imported invoices from getting the wrong tax amount when an EDI document contains multiple tax subtotal sections. It now uses the tax totals linked to the invoice’s own currency, which avoids incorrect adjustments in supported international invoice formats.
Original PR description
When the EDI document has multiple document-level TaxSubtotal nodes (which can happen under Japanese PINT rules), `_correct_invoice_tax_amount` erroneously amends the tax total, and the imported invoice gets the wrong value. In BIS3 EDI, two TaxTotal nodes are created if the document currency and the company currency are different. The TaxTotal node in the company currency is generally for tax reporting purposes. Up until now, `_correct_invoice_tax_amount` worked correctly because base BIS3 EDI requires TaxTotal nodes with the document currency to have a TaxSubtotal node. This commit fixes the bug by only correcting the taxes based on the TaxTotal node that has a currency ID equal to the document currency. Note 1: This fix is targeting 19.0 and above because `l10n_jp_ubl_pint` and other PINT modules are available starting from 19.0. Forward-Port-Of: odoo/odoo#258301
Removing an attachment from a scheduled chatter message no longer causes an error. This makes editing scheduled messages more reliable and prevents users from losing time on an unexpected traceback.
Original PR description
scheduled message editor Problem: When editing a scheduled chatter message, removing an attachment raises a traceback. Cause: `fullComposerBus` is available in the `Composer` environment but not in `ScheduledMessage`. The code assumed its presence and attempted to use it unconditionally. Solution: Check whether `fullComposerBus` exists in `env` before using it. Steps to reproduce: - Add a log note. - Open the full Composer. - Add an attachment. - Schedule the message. - Save. - Edit the scheduled message. - Remove the attachment from the attachments list. - Observe a traceback. opw-6098302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258839
This update prevents a crash that could happen when searching for an employee in Attendance kiosk mode. It makes the search logic ignore invalid internal conditions, so the kiosk stays usable instead of showing an error.
Original PR description
**Steps to Reproduce:**
1. Install `hr_attendance` module with demo data.
2. Go to Attendances > Kiosk Mode > Identify Manually.
3. Select any department.
4. Try searching for an employee.
**Error:**
`ValueError - not enough values to unpack (expected 3, got 1)`
**Cause:**
The `employees_infos()` controller assumes that every item in the domain is a valid triplet (field, operator, value). However, the domain may also contain logical operators ('&'), which are not triplets. And then trying to unpack such entries leads to a ValueError.
**Fix:**
Add a validation to ensure the condition is a proper triplet before unpacking. Non-conforming entries (logical operators) are skipped.
sentry-7401444075
opw-6113268
Forward-Port-Of: odoo/odoo#258825When customers receive invoices by email, any extra report attachments now keep the filename set in the report configuration. This avoids confusing default names and makes the emailed documents easier to identify.
Original PR description
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice…
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number). This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself. To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved. The fix will ensure extra dynamic reports follow their configured printed name. Steps to reproduce: 1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. 2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). 3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”. 4. Add the duplicated report under Dynamic Reports. 5. Create a customer invoice and confirm it. 3. Click Send (or Send & Print) to open the email preview. Related Ticket: opw-6058716 Forward-Port-Of: odoo/odoo#259975 Forward-Port-Of: odoo/odoo#259267
Preparation printers now show the selected variant’s attribute value when a combo item uses an instant variant. This ensures kitchen or prep tickets display the correct product details instead of only the base product name, reducing confusion and order mistakes.
Original PR description
Before this commit, the preparation printer did not display the attribute value for an instant variant added inside a combo choice. This occurred because the attribute value was not properly set on the variant order line. Steps to reproduce: * Create a PoS product with multiple variants. * Create a combo product with a choice containing the variants. * Configure a preparation printer. * Open a PoS session and order the combo. * The printer displays only the base product name. opw-5949132 Forward-Port-Of: odoo/odoo#256981
The barcode app no longer shows a stock-location confirmation warning when adding products that are not meant to be stored in inventory. This prevents confusing prompts for users and makes delivery operations smoother.
Original PR description
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P…
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P as product > Confirm #### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there? ### Expected behavior: Since the product is not storable it should not trigger the dialog ### Cause of the issue: The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant. opw-6110655 Forward-Port-Of: odoo/enterprise#114173
The domain selector and expression editor now display numbers using the user’s language and regional settings, such as decimal and thousands separators. This makes values easier to read and avoids confusion, while keeping the underlying expression unchanged.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. 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#259732 Forward-Port-Of: odoo/odoo#258287
This change fixes an issue where retry messages were being logged too prominently during builds. As a result, build logs are cleaner and easier to review without the unnecessary noise.
Original PR description
While moving the logic from common to suite, the logger was changed from common._logger to suite._logger, but the monkeypatching was not updated, resulting in the "Retrying" logs not being downgraded to info and spamming the logs of the builds. Forward-Port-Of: odoo/odoo#260041
This change prevents the IoT box from overwriting a printer’s subtype when it resends device information. As a result, any subtype set by a user in the database stays intact unless the device’s main type actually changes.
Original PR description
Steps to reproduce: 1. Connect a printer to the IoT box and pair with a DB 2. Manually change the subtype of the printer in the DB 3. Restart the IoT box so it resends its devices. **Expected behaviour**: Subtype remains as the user-set value. **Actual behaviour**: Subtype is reset to the original value. To fix this issue, we simply remove any check for subtype in the device updating condition. Now, a device will only reset if its type changes.
This change updates an internal performance test to match a recent menu visibility update in a related feature. It does not change how users work, but it keeps automated checks accurate so future build and test runs remain reliable.
Original PR description
Due to changes in the related enterprise PR fixing timesheet Configuration menu visibility in sale_timesheet_enterprise, the number of queries has increased. This commit increases the expected query count in test_load_menus_perf and test_load_web_menus_perf from 62 to 63. task-5428010
This update refreshes the spreadsheet component to the latest version and brings in several fixes that improve reliability and formatting accuracy. It also updates the underlying build and development tooling, which helps keep the spreadsheet feature compatible with newer software versions and easier to maintain.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d734b5fc76 [REL] 19.1.15 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d734b5fc76 [REL] 19.1.15 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7b46b15ef7 [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/1aa2e82583 [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/d14f831597 [FIX] package: add rolldown binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7847979c1f [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/00e9fad82d [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659) https://github.com/odoo/o-spreadsheet/commit/a2ce36fa84 [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/c55874a9e8 [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/835572ba20 [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/038b30f1b7 [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/33a9eea8a1 [FIX] spreadsheet_pivot: avoid crash on invalid dimension values [Task: 6111913](https://www.odoo.com/odoo/2328/tasks/6111913) https://github.com/odoo/o-spreadsheet/commit/cb35b4680b [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834) https://github.com/odoo/o-spreadsheet/commit/fb86c10488 [FIX] side_panel: prevent chart picker layout shift on hover [Task: 6095239](https://www.odoo.com/odoo/2328/tasks/6095239) https://github.com/odoo/o-spreadsheet/commit/4bfa5fde13 [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101) https://github.com/odoo/o-spreadsheet/commit/d3a54d258d [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/fc0e6941c9 [FIX] css: remove unused variables [Task: 6119435](https://www.odoo.com/odoo/2328/tasks/6119435) https://github.com/odoo/o-spreadsheet/commit/744bfffe99 [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129) https://github.com/odoo/o-spreadsheet/commit/269bec6457 [FIX] format: large number format with no digits [Task: 6010376](https://www.odoo.com/odoo/2328/tasks/6010376) https://github.com/odoo/o-spreadsheet/commit/c438eb31b0 [FIX] format: number format with no digit [Task: 6068824](https://www.odoo.com/odoo/2328/tasks/6068824) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fix corrects how the upgrade script recognizes when a value is already being used inside a template expression, especially when it is followed by a comma. As a result, the script avoids moving variables into the wrong place, reducing unnecessary changes during upgrades.
Original PR description
When a variable is used as method parameter and followed by a comma it failed to be identified as being used, so the script then incorrectly moved it as a t-call parameter while it's not necessary.
In the example below, the variable `geoip_country` was not correctly identified as being used in the `t-out` statement:
```
<t t-name="website.test">
<t t-call="website.layout">
<t t-set="geoip_country" t-value="request.geoip.country_code"/>
<t t-set="all_countries" t-value="{cc.code: cc.name for cc in request.env['res.country'].search_fetch([], ['code', 'name'])}"/>
<div>Country: <t t-out="all_countries.get(geoip_country, 'BE')"/></div>
</t>
</t>
```
This commit fix used variable detection when the variable is immediately followed by a comma.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change makes Odoo catch invalid filter values earlier, such as using text where a number is expected. It helps prevent hidden errors and makes domain checks more reliable before they are used in practice.
Original PR description
`Domain([('num_field', '=', 'dfd')]).validate(model)` should raise an exception because 'dfd' is not a valid number. Currently, the optimization does not check the data types for all operators, but these are checked during SQL generation. Let's generate the SQL to validate the domain.
task-6132976
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe editor now avoids showing or using formatting tools on content that cannot be edited. This prevents unexpected errors and infinite loops when users try to format protected content, while still allowing the toolbar in the specific cases where it is needed for QWeb and icon elements.
Original PR description
Current behavior before PR: - Removing formatting on a contenteditable false element infinite loop when removing format. - The toolbar could appear even when the target element had contenteditable false Desired behavior after PR is merged: - Now,the toolbar no longer opens when the selected element is contenteditable false - The toolbar is now only shown for elements with contenteditable true, except for QWeb and icon elements, where it remains accessible. task-5265416 Forward-Port-Of: odoo/odoo#259453 Forward-Port-Of: odoo/odoo#231613
Fixed an issue where images added to the company document layout could disappear in printed PDFs after being resized to a percentage. This ensures customer-facing documents print correctly with the intended branding and layout.
Original PR description
Problem: When adding an image in the `company_details` field via **Settings > Configure your document layout** and resizing it to a percentage width (e.g. 50%), the image is not visible when printed. Cause: Since fa55c2d1, `wkhtmltopdf` fails to correctly calculate percentage-based image widths because none of the ancestor elements have an explicit width defined. Solution: Force the wrapping table to `width: 100%`, giving `wkhtmltopdf` a concrete width to resolve percentage values against. Steps to reproduce: - Go to **Settings > Configure your document layout** - In the address field, add an image via `/media` - Resize the image to 50% - Print the document - Image is missing in the PDF output opw-6102568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Searching for a setting on mobile could previously trigger an error. This update fixes the issue so users can reliably find settings on smaller screens without interruptions.
Original PR description
Before this commit, when searching a setting in mobile a error as raised. opw-6140257
Access error messages now point to the actual record rule that blocks a user, instead of incorrectly suggesting a company-related issue. This makes permission problems easier to understand and reduces confusion when opening archived records.
Original PR description
When accessing an archived record directly, if access is prevented by a record rule other than a multi-company global rule, the error message incorrectly reports that all rules are failing, suggesting a company issue even though it is not the actual cause. The problem is that when access is denied, the diagnostic method `_get_failing` is used to determine which rules are failing. This method performs several count queries with different rule domains. However, `active_test` is True by default, excluding archived records from the count, causing the rule evaluation to miss some records and incorrectly mark rules as failing. With this commit, `_get_failing` evaluates rules with `active_test=False`, ensuring that only actually failing rules are reported. Forward-Port-Of: odoo/odoo#259592 Forward-Port-Of: odoo/odoo#259344
This change fixes an issue where custom fields could be counted more than once when Odoo reloads its model structure. As a result, the system avoids carrying over duplicate field data, helping keep model setup stable and reliable.
Original PR description
When a custom (manual) field is related to a base field, it is added to `registry.field_setup_dependents`. However, these custom fields were not being cleaned up correctly, causing them to duplicate and leak during each model setup. This fix explicitly cleans these manual fields from `field_setup_dependents` inside `_add_manual_models()` when manual models are removed from the registry and the registry is being reloaded. Similar to https://github.com/odoo/odoo/pull/253377. Forward-Port-Of: odoo/odoo#259819
When editing a page in one language while using a different interface language, the text editor could show writing direction incorrectly. This update makes the editor follow the language of the content being edited, so typing in right-to-left languages like Arabic now appears correctly while editing.
Original PR description
Steps to reproduce: ==================== 1. Install Arabic and set it as a website language 2. Log in as a user whose UI language is English 3. Edit a page / article in Arabic and type some text =>…
Steps to reproduce: ==================== 1. Install Arabic and set it as a website language 2. Log in as a user whose UI language is English 3. Edit a page / article in Arabic and type some text => Text rendered left-to-right in the editor Cause: ======= this was introduced after this change [1] When editing a website/article in a language whose direction differs from the logged-in user's UI language, text entered in the builder appeared in the wrong direction (e.g. writing in Arabic showed the caret/text aligned to the left instead of the right). Saving reverted the content to the correct direction, but the authoring experience was broken. The builder was initializing the editor's `direction` config from `localization.direction`, i.e. the *user's* UI locale, instead of the direction of the document being edited. As a result, an LTR admin editing an RTL site (or the reverse) got an editable whose `dir` attribute did not match the site. Solution: ========= Use the editable itself as the source of truth: if it carries the `.o_rtl` class (already used to set `isEditableRTL`), set `direction = "rtl"`, otherwise `"ltr"`. => Text now renders right-to-left, matching the site [1]:https://github.com/odoo/odoo/pull/256045/changes/0490b2229dba7e0cb4a58e5cf4d68772e5640697 opw-6109987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259541
This fix prevents an error that could appear when adding multiple tags in the Blog Post Cover editor. It makes tag search handle newly created items correctly, so users can continue editing without seeing a traceback.
Original PR description
# How to reproduce - Go to a blog page and edit the Blog Post Cover - Add a tag - Try to add another one # The problem A traceback is shown # Why When adding a new record for a many 2 many relation, the framework ensure the user cannot create a record with a name that already exists via a name search. This commit (https://github.com/odoo/odoo/commit/3631757a4766bc59378bb975e01e115c92ef1dd4) changed the way the name search is done to add this domain to the request : ```py domain.push(["id", "not in", selectedIds]); ``` But selectedIds can contain strings in the case of uncreated records, which causes the SQL query to throw an error trying to match the model id with strings opw-5978305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258451 Forward-Port-Of: odoo/odoo#251469
This change corrects how unit prices are written in Peppol invoice XML so the totals now match exactly. It prevents valid invoices from being rejected during validation because of a rounding mismatch.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because `priceAmount*InvoicedQuantity != LineExtensionAmount`. **STEP TO REPRODUCE** 1. Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. 2. Generate an XML with peppol, and try validating the invoice. You should have the following error: `[PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount` opw-6009771 Forward-Port-Of: odoo/odoo#259759 Forward-Port-Of: odoo/odoo#255358
This update fixes an unreliable automated test in the HTML editor, making test results more consistent. It helps prevent random failures in the development and release process without changing the user-facing editor behavior.
Original PR description
My last desperate fix attempt did not fix the issue so here is yet another desperate fix attempt. I have seen issues related to the use of `setContent` just to set the selection in the past so I hope it might be that. It's the only noticeable change between this test and the others, be it icon tests or color selector ones. runbot-242333 Forward-Port-Of: odoo/odoo#259731 Forward-Port-Of: odoo/odoo#259544
Fixed an issue in the Forum help page where clicking a snippet category could fail to insert content. This restores a smooth editing experience by allowing the editor to use the only available insertion area when needed.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138 Forward-Port-Of: odoo/odoo#258487 Forward-Port-Of: odoo/odoo#256078
This change updates Peru e-invoicing test files so they match the corrected unit price rounding used in PEPPOL. It does not change business behavior for customers, but it keeps automated tests accurate and prevents false test failures during development and delivery.
Original PR description
https://github.com/odoo/odoo/commit/e79136d04c844f9a0a8c6d0532c65e0cc3a68b8f fixes unit price rounding in peppol. This PR fixes a broken test in l10n_pe_edi opw-6009771 Forward-Port-Of: odoo/enterprise#114159
This change removes an unhelpful tooltip that appeared when users hovered over boolean fields in calendar popups. It improves the user experience by preventing confusing HTML content from showing up where no extra information is needed.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259529 Forward-Port-Of: odoo/odoo#259011
This fix ensures that existing checks can still recognize when a data query has restrictions, even when results are returned in a sorted order. It prevents unexpected behavior in parts of the system that rely on that check and helps maintain consistent results.
Original PR description
Some code uses `if query.where_clause` to detect if there are any restrictions on the table. When setting ordered result ids, we simply used a JOIN, so there is no detected where clause. To keep existing code working, we add a dummy 1=1 to the where clause. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the automated performance test expectations for website modules when demo data is present. It helps keep test results accurate and prevents false failures during validation, without changing end-user functionality.
Original PR description
Query counts were updated for demo data. runbot-242325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the Update Payment button disappears when it should after payments are reconciled on Mexican invoices. It corrects a case where batch payments could make the system think an update was still needed, even though the payment information was already complete.
Original PR description
- Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#112520
This update removes unnecessary fields from the data sent to the self-order front end. It helps keep the information payload lighter and reduces wasted processing without changing the user experience.
Original PR description
Fix _generate_return_values to remove some fields that are not needed on the frontend Forward-Port-Of: odoo/odoo#260016 Forward-Port-Of: odoo/odoo#259915
The website editor now correctly shows the translation status on file names added through the file tool, even when other background colors would previously hide it. This makes it easier for users to see which content still needs translation while editing a site.
Original PR description
Commit cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 added a resource to repeat the background color of the translation state inside elements, for the cases where an element has a background color that hides the translation state. This commit uses the resource for file's names (added by typing `/file`) Steps to reproduce: - Open website builder - Type `/file` and add a file - Add a language - Open in translate mode - Bug: the translation state is not show on the file name task-6038029 Forward-Port-Of: odoo/odoo#259955 Forward-Port-Of: odoo/odoo#259902
This fix ensures that events with unlimited ticket availability can be sold correctly from the Point of Sale, even when multiple time slots are enabled. Previously, these tickets could be incorrectly treated as unavailable, causing customers to see an error that all slots were full.
Original PR description
**Steps to reproduce:** - Make an event, put it to announced state - Allow multi slots and create a product - Go to the pos and try to order it - "All slots are booked out for this event" appears **Why the fix:** When we set 0 as a maximum quantity for an event slot, the quantity is unlimited, in the code, the availability is set to a string "unlimited". This was not taken into account in the case of multi slots, as we only checked if the availability was a number greater than 0. As "unlimited" is not a number, we thought we didn't have any slots available and returned the error that said all slots were full. We now add the unlimited tickets to the availability list. opw-6006696 Forward-Port-Of: odoo/odoo#254220
This update adjusts an internal check used to decide when a browser compatibility patch should be considered outdated. It helps keep accessibility-related behavior aligned with the newer lxml 6.1 release, reducing the risk of unnecessary or stale patching.
Original PR description
Whitelisting of ARIA attributes is now part of the milestone for LXML 6.1. This commit updates monkey patch's obsolescence detection accordingly.
The Intervat configuration is now shown for companies using Belgian taxes through a Belgian fiscal position, not only for companies registered in Belgium. This lets users review, change, or disable Intervat redirection when it was previously hidden.
Original PR description
### Issue: When demo data is disabled, creating a Belgian fiscal position installs the Belgian taxes and enables BE accounting Starting from 19.0, Intervat redirection is enabled automatically, but the Intervat settings are not available because the company itself is not Belgian As a result, the Intervat configuration cannot be changed or disabled ### Cause: The Intervat settings were only shown when the company country was Belgium However, companies using Belgian taxes through `account_enabled_tax_country_ids` must also be considered ### Steps to reproduce: - Disable demo data and install `accountant` - Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040) - Click the alert to install the Belgian taxes - Open Settings Before the fix: The Intervat settings are not available opw-6068480 Forward-Port-Of: odoo/enterprise#112609
When a product belongs to categories from multiple websites, Odoo now chooses a category that is available on the website the customer is currently browsing. This prevents category breadcrumb links from leading to a 404 page and improves the shopping experience across multiple websites.
Original PR description
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two…
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2. 2. Create a product and assign both categories to it. 3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly 4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error** Cause: ====== In `_prepare_product_values`, when no category is passed in the URL, the fallback was: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802 This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2. The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404. Solution: ========= Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one. opw-6070191 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258336
The call menu in Discuss now includes the Picture-in-Picture option, making it faster to keep a call visible while moving to another conversation or chatter. This also corrects the menu styling so the Fullscreen and Picture-in-Picture actions display with normal visibility.
Original PR description
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of…
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call. Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster. This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature. Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown. Before / After <img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" /> Forward-Port-Of: odoo/odoo#259866
This update fixes an error that could appear when users create accrual entries from the Billed Not Received screen after changing the date. It ensures the date is handled correctly so the action completes normally without interrupting accounting work.
Original PR description
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the…
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the quantity to 1, and `confirm` it. - Navigate to Accounting > Review > `Billed Not Received`. - Change the `date` from the top left. - Select a record and click `Create Accrual Entries`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.date' and 'str'` **Root cause:** At [1], the `accrual_entry_date` is set in the context as a `string`. Later, at [2], this value is retrieved from the context and used directly in a comparison with `ivl.date`, which is a `datetime.date`. **Fix:** This commit converts `accrual_entry_date` to a `datetime.date` object at [2], allowing users to create accrual entries without errors. [1]: https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76 [2]: https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188 opw-6110907 Forward-Port-Of: odoo/odoo#259047
This update preserves the visual formatting of spreadsheet cells that contain Odoo links when a dashboard is frozen and shared. The links are made non-clickable for public viewers, while keeping the same link-like appearance needed for layout consistency.
Original PR description
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that…
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content. By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout. To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click). Task-6063301 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#260250 Forward-Port-Of: odoo/odoo#256357
This change fixes a test that could fail during setup because it checked access groups before confirming the related module was installed. It helps keep automated tests stable and prevents unnecessary errors in the electronic invoicing area.
Original PR description
The `get_default_groups` call happens during super.setUpClass(), therefore we have not checked (yet) if the module in which the security group is in is installed, and we end up with an Exception. task-none Forward-Port-Of: odoo/odoo#260230
This change fixes a problem where manual capture and void actions could fail in Adyen payments, and ensures the related payment records are updated correctly. As a result, businesses can complete payment operations more reliably without transactions getting stuck or rejected.
Original PR description
Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen…
Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen payment provider. 2- Enable `Capture amount manually`. 3- Create a SO and confirm. 4- Generate a payment link and pay. 5- In SO, capture the full amount. Cause: --- After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created. However the child tx is missing the `provider_reference` required to send the payment provider. Issue 2: --- The child tx created for capture/void is always remains in draft state. Cause: --- This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed. opw-6120846 opw-6120071 Forward-Port-Of: odoo/odoo#259223
This change fixes an issue where invoicing a kit could miss the cost-of-goods-sold entry if one of its components had been removed from the delivery. It also improves the calculation so the cost entry reflects only the components actually delivered, which makes accounting more accurate.
Original PR description
Steps to reproduce: - Create a kit with 3 or more components - Create a sales order with the kit and confirm it - Remove at least one of the kit's components from the delivery and validate it - Create the invoice from the sales order and confirm the invoice - Check the journal entries included in the invoice form Current behavior: - There is no COGS entry Expected behavior: - There should be a COGS entry Context: In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount. opw-6082565 Forward-Port-Of: odoo/odoo#258982