Thursday, July 23, 2026
23 changes · 19.0
Resolved issues and error corrections
This fixes an issue where changing the alignment of table headers in Studio reports did not visibly apply. Users editing reports, such as invoices, can now reliably adjust header alignment from the editor toolbar.
Original PR description
Problem: Changing the text alignment of a table header in Studio reports has no effect. Cause: When the alignment is already defined by a CSS class using `!important` (for example, `text-center`), the inline style applied from the toolbar is ignored. Solution: Backport commit 373be20905bcb11f8323a986053e3dc7996ce567. Steps to reproduce: - Open the invoice report. - Change the alignment of a table header. - Observe that the new alignment is not applied. opw-6389158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix avoids an intermittent error that could appear while editing website/eCommerce pages when test assets are enabled. It changes an internal website test helper to use the page's standard local storage access, reducing unexpected tracebacks during development and testing without affecting normal customer-facing behavior.
Original PR description
# Step to reproduce - Install eCommerce - Activate dev mode with tests assets (important!) - Go to the website & add a Countdow in the footer - Add a new product from the website system tray - Put…
# Step to reproduce - Install eCommerce - Activate dev mode with tests assets (important!) - Go to the website & add a Countdow in the footer - Add a new product from the website system tray - Put any name & Save - Go into Edit mode - In the Style tab, (un)toggle "Tax Indication" (may need to do it multiple times) > Note that the issue is quite inconsistent to reproduce # Issue A traceback is shown # Cause The only thing I'm sure of is that the error is caused by this code : https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/website/static/tests/tour_utils/lifecycle_dep_interaction.js#L18-L20 And that it is linked to `browser.localStorage`. I suspect it is due to some weird localStorage and WysiwygAdapter interaction : https://github.com/odoo/odoo/blob/d6a08b67a948f569a1ca893b6337ce50b4ef9f07/addons/website/static/tests/tours/widget_lifecycle.js#L53-L60 But I can't be sure because debugging tools do not seem to be working. See the inverstigation comment in the associated PR for more information. # Proposed Solution Since this code is only used for this test : https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L14-L15 And the test directly parses from the `window.localStorage` : https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L50 We can use `window.localStorage` instead of `browser.localStorage` as it fixes the issue opw-6246850
This fix keeps category and subcategory labels in the online shop sidebar on one line when there is enough space. It improves the storefront editing experience and prevents confusing or untidy category displays at normal or lower zoom levels.
Original PR description
When the shop sidebar categories are enabled with collapsed categories, subcategory names could wrap unexpectedly at 100% zoom or lower, even when there was enough available space. Steps to reproduce: - Open the Shop page and click Edit - Go to the Style tab - Set Content Width to Full - Enable the Categories sidebar - Enable Collapse Category This issue caused sidebar subcategory labels to wrap only at lower zoom levels, while higher zoom levels displayed them correctly. Add CSS rules to prevent category names in the sidebar from wrapping. opw-6296804
This fixes how the Cloudflare Turnstile verification widget is configured on website forms. The widget now uses the intended display setting, helping form protection behave consistently for visitors and site owners.
Original PR description
# How to reproduce - Enable Cloudflare Turnstile in Settings > Integrations - Add a CF Site Key & a CF Secret Key. e.g. : - `1x00000000000000000000AA` - `1x0000000000000000000000000000000AA` (See :…
# How to reproduce - Enable Cloudflare Turnstile in Settings > Integrations - Add a CF Site Key & a CF Secret Key. e.g. : - `1x00000000000000000000AA` - `1x0000000000000000000000000000000AA` (See : https://developers.cloudflare.com/turnstile/troubleshooting/testing/) - Go to a Website page with a form - Add `?cf=show` to the URL - Open the browser console - Search the dom for an element with s_turnstile_container - Look for the `data-appearance` attribute # The issue `data-appearance` is set to `interaction-only` but should be `always` according to : https://github.com/odoo/odoo/blob/1e73172b51cd673c3414187af4f98304921ed7b3/addons/website_cf_turnstile/static/src/interactions/turnstile.js#L8-L12 # Cause `appearance` is misspelled in the template : https://github.com/odoo/odoo/blob/1e73172b51cd673c3414187af4f98304921ed7b3/addons/website_cf_turnstile/static/src/interactions/turnstile.xml#L7 Documentation on the Appearance modes for Turnstile : https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/widget-configurations/#appearance-modes opw-6359977
This fix ensures that resetting accounting documents to draft through remote calls returns a valid response instead of failing. It prevents avoidable errors in accounting and related localization workflows, improving reliability for users and integrations.
Original PR description
Calling the method in RPC causes an error: ``` TypeError: cannot marshal None unless allow_none is enabled ``` 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#277047 Forward-Port-Of: odoo/odoo#276541
The French PDP localization now keeps the needed posting context when processing invoices automatically. This helps automatic bill posting work reliably and prevents failures in invoice OCR flows for affected localizations.
Original PR description
The context variable skip_is_manually_modified needs to be passed in order for the autoposting feature to work. The is_manually_modified variable of the move needs to evaluate to true Fixes error in test TestInvoiceExtract.test_autopost_bills_ocr for mc and fr localizations Related pr: https://github.com/odoo/odoo/pull/271865 runbot-6369932 Forward-Port-Of: odoo/odoo#276953
This fixes an incorrect warning shown when editing a partner-related view. The hidden field behavior was already working, but the view definition now uses the expected syntax so users and administrators are not shown a misleading warning.
Original PR description
There is a warning saying that there is no "true" field when editing the view. But in reality this is currently working as expected and the field is hidden. opw-6398588 Forward-Port-Of: odoo/odoo#277739
When users add an Odoo website to the home screen on iPhone or iPad, the shortcut now uses the site's favicon instead of a generic first-letter placeholder. This improves the branded appearance of website shortcuts and makes them easier to recognize.
Original PR description
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. This commit is a backport of [1], which was merged in master(saas-19.2). task-5427275 [1]: https://github.com/odoo/odoo/commit/2506fdfc49f1515aea7e715e9f6d66418a093401 Forward-Port-Of: odoo/odoo#277723
This fix prevents users from changing the payment journal or memo on company-paid expense payments after they are linked to an expense report. It helps keep expense reports and their related payments consistent, avoiding silent accounting mismatches.
Original PR description
Before this commit, the journal and the memo of a payment linked to a company-paid expense report could be modified although such payments must be kept consistent with their expense report: a missing…
Before this commit, the journal and the memo of a payment linked to a company-paid expense report could be modified although such payments must be kept consistent with their expense report: a missing comma in the set of protected fields merged 'journal_id' and 'ref' into a single meaningless entry. The memo was also left editable because the set still referred to 'ref', which was renamed to 'memo'. Steps to reproduce: - submit, approve and post an expense paid by company - open the payment created for the expense report - edit the memo or the journal and save, then try to edit the date Editing the date is refused with "You cannot do this modification since the payment is linked to an expense report", while the memo and journal changes are silently accepted. Solution: Restore the missing comma and protect the renamed memo field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277737 Forward-Port-Of: odoo/odoo#277423
This fixes an issue where selection rules set on related-record fields were used in the user interface but not shared with the server when records were read. The change helps Odoo apply the same add-record restrictions consistently while keeping already linked records visible so users can review or remove them.
Original PR description
**Description of the issue/feature this PR addresses:** A `domain` attribute set on a `one2many` or `many2many` field in a view's XML arch is parsed and stored in `fieldInfo` (and correctly used by…
**Description of the issue/feature this PR addresses:** A `domain` attribute set on a `one2many` or `many2many` field in a view's XML arch is parsed and stored in `fieldInfo` (and correctly used by the "Add" dialog), but it is never carried through the specification sent to `web_read`. As a result, the server never receives the field's view-level domain when reading the record, so it has no way to take it into account. **Current behavior before PR:** When a relational (`one2many`/`many2many`) field declares a `domain` in the arch, that domain is applied only client-side for the "Add an item" dialog. It is dropped from `activeFields` and is not included in the `web_read` field spec, so the evaluated domain is not available on the server side. **Desired behavior after PR is merged:** The view-level `domain` of a `one2many`/`many2many` field is threaded through to the `web_read` spec: `makeActiveField` stores the `domain`, `extractFieldsFromArchInfo` forwards `fieldNode.domain`, and `getFieldsSpec` evaluates the domain expression against the current `evalContext` and includes it in the relational field's spec. Note: the domain is intentionally not used to filter the already-linked records returned by `web_read`. Per standard Odoo semantics a field `domain` restricts which records can be added, not which stored records are displayed. Hiding already-linked, out-of-domain records would make them invisible yet still active on the backend (for example, survey conditional triggers must remain visible so an invalid trigger can be removed). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when cash rounding is enabled in Point of Sale but no rounding method has been selected. It makes the checkout tax total calculation handle that missing setting safely, improving reliability for stores using cash rounding.
Original PR description
When `cash_rounding` is enabled on a POS config but `rounding_method` is not set,`get_tax_totals_summary` is called with undefined (instead of null). Fix: ensure the `rounding_method` is set when `cash_rounding` is enabled, otherwise pass null to `get_tax_totals_summary`. task-id: 6388234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clicking activity notifications for lots and serial numbers now correctly shows only the selected overdue, due today, or future activities. This helps inventory users focus on the relevant records instead of seeing the full list every time.
Original PR description
## Current behavior: Clicking on the Late activity for Lot/Serial in the notification systray doesn't apply the Late activities filter. ## Expected behavior: Clicking on the Late activity for…
## Current behavior: Clicking on the Late activity for Lot/Serial in the notification systray doesn't apply the Late activities filter. ## Expected behavior: Clicking on the Late activity for Lot/Serial in the notification systray should apply the Late activities filter. ## Steps to reproduce: 1. Install Inventory (stock) module, make sure to enable Lots & Serial Numbers in Inventory > Traceability 2. Create some new Lots / Serial numbers 3. Add some Activities with Due Date before today 4. Observe that the Clock icon on systray will count up, showing the number of activities that are late, for today and for future 5. Click on the Late activities (e.g. 2 Late) should only show the 2 late activities. Instead, no filter is applied, thus showing all the Lots / Serial numbers in the inventory ## Cause of the issue: Missing filters for Late, Today and Future activities in the stock_lot_views.xml ## Fix: Added 3 filters for Late, Today and Future activities opw-6332560
This fixes a visual issue in spreadsheet dashboards where the chart granularity menu could flicker when users hovered over it in Chrome. Dashboard interactions should now feel smoother and more reliable when changing chart time groupings.
Original PR description
There is a flickering when hovering the chart granularity popover. How to reproduce: - open a dashboard with a time-based chart (like the Sales dashboard) - hover it and click on the "Month" button - hover the popover with the granularity suggestions => flickering The issue seems to come from the way Chrome handles the <select> popover as the element is not recognized as a child element of the <select> parent. As such, the pseudo-class `:focus-within` does not work as intended and the chart menu flickers between a visible/hidden state. As a fix, we rely on another pseudo-class `:open` that applies to the <select> tag, its open state being correctly handled by the browser. Task-6288876 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
Polish KSEF invoice XML exports now omit the country name from address lines when the country code is already provided. This prevents buyer and seller addresses from showing the country twice in the KSEF portal, making submitted documents cleaner and more accurate.
Original PR description
### Issue: When sending an invoice to KSEF, the `AdresL1` field in the XML contains the country name for both buyer and seller The KSEF portal already derives the country name from `KodKraju` (country code), causing it to appear twice on portal documents ### Cause: `_display_address` uses the default PL `address_format` which includes `%(country_name)s` The format is not overridden for the FA3 XML export context, so the country name is always appended to `AdresL1` ### Steps to reproduce: - Install `l10n_pl_edi` - Configure KSEF (see video on the ticket) - Create and send an invoice to KSEF - Check `AdresL1` in the generated XML Before the fix, `AdresL1` includes the country name The KSEF portal also shows the country name twice for both buyer and seller opw-6369708
Embedded views at the top of a Knowledge article now keep their intended alignment even when editor selection placeholders are present. This avoids small layout glitches when users start an article with an embedded view, keeping the editing experience consistent.
Original PR description
This commit updates the embedded view top-alignment selector to account for selection placeholders introduced by https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d. This preserves the intended top-alignment behavior when an embedded view is the first editable element in the knowledge editor. Task-5951196
The Vietnam Sales Tax Report now displays VAT amounts consistently as positive values at the detailed invoice level. This avoids confusion when reviewing sales tax figures and aligns detailed lines with the totals shown in the report.
Original PR description
## Current behavior: In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative ## Expected behavior: The VAT value in the minimum layer should…
## Current behavior: In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative ## Expected behavior: The VAT value in the minimum layer should be consistent with the upper layers and kept positive ## Steps to reproduce: - Install l10n_vn (l10n_vn_reports will install as well) - Switch to VN Company - With demo data, go to Invoicing / Reporting / Tax Report - Change Tax Report (VN) to Sales/Purchase Tax Report (VN) - Unfold the lines all the way to the minimum layer: VAT on sales of goods and services 10% -> INV/2026/00003 - Observe that the VAT 10% line is at negative, which is inconsistent with the Total line below ## Cause of the issue: - In Odoo, tax journal items store tax_base_amount with the accounting sign (negative for sales). This is expected behavior - However, Vietnamese VAT listing expects commercial amounts, which means sales bases need to be displayed as positive numbers ## Fix: Normalized tax_base_amount sign in _query_tax_lines function before building the SQL query opw-6344577
The IVA Simple sales CSV now correctly reports buyers marked as “IVA No Alcanzado” under the exempt category. This prevents blank buyer type values in Argentine tax reports and improves compliance reporting accuracy.
Original PR description
### Description AFIP responsibility code `15` (IVA No Alcanzado) was missing from the `CASE WHEN` in `_vat_simple_build_sale_query`, so the "Tipo de sujeto comprador" (`responsibility_type_code`) column was left empty in the IVA Simple sale CSV for partners with that responsibility. This adds `15` to the exempt bucket (value `3`), next to its pair code `16` (IVA No Alcanzado - Otro), which was already handled there. ### Steps to reproduce 1. Set a partner's AFIP responsibility to "IVA No Alcanzado" (code 15). 2. Generate the IVA Simple sale CSV. 3. Before: the "Tipo de sujeto comprador" column is empty for that partner's rows. 4. After: it is reported as `3` (exempt bucket).
The Knowledge editor no longer offers website theme colors in its text color picker. This prevents article colors from changing unexpectedly when the website theme is updated, keeping published Knowledge content visually consistent.
Original PR description
**Steps to reproduce:** - Go to Knowledge app - Go to any article - Try to change the color of the text - Theme colors of the website are shown in the colorPicker - When applied they are mapped to `text-o-color-x` attributes - Changing the website theme affects the article colors - Published articles will have different colors if the theme was modified **Issue:** Some modules (`Knowledge`) should not be affected by the website styling. But there is no direct way to prevent this on the colorPicker. ``` // Overwrite user-defined website styles in Knowledge published articles, mainly // to avoid color customization from affecting articles content. ``` **Fix:** Remove the dynamic values from the knowledge color picker (for now). related: https://github.com/odoo/enterprise/commit/e042faab3d1d992cb471dcf9141d0a2756d06ced opw-5148839
This fix prevents an error when moving Uruguayan electronic invoicing records back to draft through remote system calls. It improves reliability for users and integrations that need to reset documents without encountering a technical failure.
Original PR description
Calling the method in RPC causes an error: ``` TypeError: cannot marshal None unless allow_none is enabled ``` Forward-Port-Of: odoo/enterprise#124740 Forward-Port-Of: odoo/enterprise#124653
This fix prevents system errors when a Knowledge article linked to an Annual Report is sent to the trash and automated cleanup runs. The related annual report data is now cleaned up together, keeping background maintenance from failing and reducing disruption for accounting users.
Original PR description
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``accountant_knowledge`` module - Go to Accounting > Review > Annual Report > Create a new annual report - Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint "audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL: Key (id)=(67) is still referenced from table "audit_report". ``` https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070 The garbage collector deletes trashed knowledge articles that match its domain. Since this domain also includes articles linked to Annual Reports, the cron attempts to delete records that are still referenced by annual report, resulting in a foreign key violation error. Solution: Ensure linked audit reports are also deleted during knowledge article garbage collection. sentry-7488793071
This fixes an issue in accounting reports where the system failed to recognize when no report section had been opened yet. The correction helps reports initialize and restore sections more reliably for users.
Original PR description
**Root Cause:**
At [1], the condition `this.lastOpenedSectionByReport === {}` always
return `false` because JavaScript compares objects by reference
rather than by value. As a result, the code never detects when
`lastOpenedSectionByReport` is empty.
**Fix:**
This commit ensures the code correctly detects an empty
`lastOpenedSectionByReport` object.
[1]:
https://github.com/odoo/enterprise/blob/ae4b461edb1d6b49c25d4e264380e7ae4b67f10c/account_reports/static/src/components/account_report/controller.js#L50
**No task ID**
Forward-Port-Of: odoo/enterprise#124223This fix updates expected Mexican chart of accounts labels used in trial balance report checks so they match the official account groups. It helps keep localization validation reliable and prevents report-related checks from failing because of incorrect expected names.
Original PR description
Enterprise companion of odoo/odoo#277615 — the forward-port to 19.0 of the `l10n_mx` fix that restores the SAT account group names copied from siblings. The `l10n_mx_reports` trial balance test asserts the full Chart of Accounts XML sent to the SAT with the group names hardcoded in the expected output. Two of them were wrong (copied from sibling groups) and are corrected by the community PR: - SAT group **602** (Gastos de venta): `Cost of sales` → `Selling expenses` (`Cost of sales` is 501.01). - SAT group **614** (Amortización contable): `Accounting depreciation` → `Accounting amortisation` (that name belongs to 613). Without this, `ci/l10n` fails on `TestL10nMXTrialBalanceReport.test_generate_coa_xml` and `...test_generate_coa_xml_with_prefix_7_accounts_having_debit_and_credit_tags`. Same branch name as the odoo PR so the mergebot pairs them.
This fixes the French VAT report so the BA zone is sent using the expected free-text format instead of a standard value field. This helps ensure VAT submissions match the required format and reduces the risk of reporting validation issues.
Original PR description
The value inside the BA zone needs to be a "TexteLibre1" and not a value no task id