Before this commit, when an authentication process was ongoing it was not very clear to the user This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted. task-6372665 Forward-Port-Of: odoo/odoo#277074 Forward-Port-Of: odoo/odoo#275230

Before this commit, when an authentication process was ongoing it was not very clear to the user
This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted.

task-6372665

Forward-Port-Of: odoo/odoo#277074
Forward-Port-Of: odoo/odoo#275230

Release notes: https://github.com/odoo/owl/releases/tag/v3.0.0-alpha.44 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

Release notes:
https://github.com/odoo/owl/releases/tag/v3.0.0-alpha.44

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

Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 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#276755 Forward-Port-Of: odoo/odoo#267482

Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call.

opw-6237180

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#276755
Forward-Port-Of: odoo/odoo#267482

**Description of the issue/feature this PR addresses:** ---------------------------------------------- On mobile devices, the meeting view had two UI issues affecting the call experience. The call permission dialog could display an unwanted focus outline around its content because the dialog body was focused on touch devices. Additionally, meeting action buttons could be partially hidden, especially in portrait mode, as the meeting view could extend beyond the visible viewport height.

**Description of the issue/feature this PR addresses:**
----------------------------------------------
On mobile devices, the meeting view had two UI issues affecting the call
experience.
The call permission dialog could display an unwanted focus outline around
its content because the dialog body was focused on touch devices.
Additionally, meeting action buttons could be partially hidden,
especially in portrait mode, as the meeting view could extend beyond the
visible viewport height.

**Current behavior before PR:**
----------------------------------------------
- Opening the call permission dialog on mobile could show an unwanted
  focus outline around the dialog content
- Meeting action buttons could be partially hidden on mobile devices
- In portrait mode, the footer could overflow below the visible viewport


**Desired behavior after PR is merged:**
----------------------------------------------
- Call permission dialog opens on mobile without showing the unwanted
focus outline on main body.
- Meeting action buttons remain fully visible on mobile devices


Task-6232825

----------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#266620

Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed. runbot error~944206 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merge

Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed.

runbot error~944206

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#277306
Forward-Port-Of: odoo/odoo#276799

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

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

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6b3c312b61 [REL] 19.4.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/44717e7739 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808) https://github.com/odoo/o-spreadsheet/commit/0ad7a9fe3c [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/6b3c312b61 [REL] 19.4.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/44717e7739 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808)
https://github.com/odoo/o-spreadsheet/commit/0ad7a9fe3c [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/1758ce502e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/d835cd31d4 [FIX] table computed style: fix render table [Task: 6396322](https://www.odoo.com/odoo/2328/tasks/6396322)
https://github.com/odoo/o-spreadsheet/commit/936aebdd54 [FIX] index: export `positionMap` [Task: 6159213](https://www.odoo.com/odoo/2328/tasks/6159213)
https://github.com/odoo/o-spreadsheet/commit/a2c2775656 [FIX] Pivots: cache `getPivotIdFromPosition` for performance [Task: 6159213](https://www.odoo.com/odoo/2328/tasks/6159213)
https://github.com/odoo/o-spreadsheet/commit/45361d9f8c [FIX] collaborative: add sheetId as argument to `getClientsToDisplay` [Task: 6408720](https://www.odoo.com/odoo/2328/tasks/6408720)

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>

In the "test_add_new_line_in_detailled_op" tour, the quantity of the last row of the Detailed Operations list is edited and then blurred with "press Tab". Tab on the last editable cell of the last row of an x2many list is a generic list view feature that triggers "add a line" (so users can quickly fill in several rows in a row). For this specific field (lot/serial tracked quants), "add a line" opens the "Add line: <product>" selection wizard instead of an empty row. This wizard stacks on t

In the "test_add_new_line_in_detailled_op" tour, the quantity of the last row of the Detailed Operations list is edited and then blurred with "press Tab".

Tab on the last editable cell of the last row of an x2many list is a generic list view feature that triggers "add a line" (so users can quickly fill in several rows in a row). For this specific field (lot/serial tracked quants), "add a line" opens the "Add line: <product>" selection wizard instead of an empty row.

This wizard stacks on top of the "Detailed Operations" dialog, which makes the next tour step fail: it finds the footer total but refuses to click it since it is now covered by a modal.

Blur the field with "click body" instead, as already done for other steps of this tour, so it does not trigger "add a line".

tour_tag: .test_add_new_line_in_detailled_op

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

# 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-appea

# 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

Forward-Port-Of: odoo/odoo#275077

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification.

See upstream changes:
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization)
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization)

This commit fixes this by refactoring the assertions to treat the output HTML structure as a "black box", verifying data integrity and expected content conversions rather than brittle structural layout.

runbot-938228

Forward-Port-Of: odoo/odoo#277747
Forward-Port-Of: odoo/odoo#275959

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#277719 Forward-Port-Of: odoo/odoo#273905

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#277719
Forward-Port-Of: odoo/odoo#273905

Steps to reproduce 1. Go to Website Settings. 2. Configure the "Contact Us" form to create an Opportunity. 3. Select a "Default Sales Team" (ensure this team has a Team Leader set). 4. Leave the "Default Salesperson" field empty (None). 5. Submit the "Contact Us" form on the website. Current behavior The resulting Opportunity is automatically assigned to the Team Leader. Expected behavior The Opportunity should remain unassigned, respecting the empty "Default Salesperson" configura

Steps to reproduce
1. Go to Website Settings.
2. Configure the "Contact Us" form to create an Opportunity.
3. Select a "Default Sales Team" (ensure this team has a Team Leader set).
4. Leave the "Default Salesperson" field empty (None).
5. Submit the "Contact Us" form on the website.

Current behavior
The resulting Opportunity is automatically assigned to the Team Leader.

Expected behavior
The Opportunity should remain unassigned, respecting the empty
"Default Salesperson" configuration.

Issue
In https://github.com/odoo-dev/odoo/commit/d136e79d1ea0a4793ba9d447603e6f0e29b40770, a fallback was introduced to
explicitly assign the Team Leader (`team_id.user_id`) whenever a team was
present but a salesperson was not, provided rule-based assignment was disabled:
https://github.com/odoo/odoo/blob/d136e79d1ea0a4793ba9d447603e6f0e29b40770/addons/website_crm/models/crm_lead.py#L55-L56

This incorrectly overrides the intentional configuration in the website
settings. Additionally, in https://github.com/odoo-dev/odoo/commit/ba6a5ddc8dec971f8b810dfad3d9934e7b581c91, the
website_form_input_filter was made to fall back to request.website.crm_default_team_id
and crm_default_user_id when the form did not submit those fields:
https://github.com/odoo/odoo/blob/ba6a5ddc8dec971f8b810dfad3d9934e7b581c91/addons/website_crm/models/crm_lead.py#L14-L17

The Contact Us form already passes the configured team and salesperson as
hidden inputs. When they are not configured, nothing is submitted for those
fields. The fallback to request.website caused leads to be assigned a team
even when neither field was intentionally configured, because crm_default_team_id
defaults to the first sales team on website creation.

opw-6050663

Forward-Port-Of: odoo/odoo#257134

Before this commit, when changing the Tip product in the POS settings, the change was reverted and the default Tip product was used instead. opw-6366774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275647

Before this commit, when changing the Tip product in the POS settings, the change was reverted and the default Tip product was used instead.

opw-6366774

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#275647

The field pack_lot_ids is not present in the pos.order.line model anymore, so we need to remove it from the test. runbot-941527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276548

The field pack_lot_ids is not present in the pos.order.line model anymore, so we need to remove it from the test.

runbot-941527

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276548

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation. Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error. opw-6182687 Forward-P

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation.

Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error.

opw-6182687

Forward-Port-Of: odoo/odoo#277724

This PR adapts the code to call printEventBadge method in pos_event_iot to print the corresponding badge See https://github.com/odoo/enterprise/pull/123478 Forward-Port-Of: odoo/odoo#275021

This PR adapts the code to call printEventBadge method in pos_event_iot to print the corresponding badge

See https://github.com/odoo/enterprise/pull/123478

Forward-Port-Of: odoo/odoo#275021

Before this commit, when clicking on refresh and the kyc_status on IAP was 'fail', we put the status on the db to 'fail' and ended the process. This implies creating a new record IAP side even if it is useless and also implies that there could be cases where there would be a mismatch between iap and Odoo. e.g. The client starts a verification process, he ends up refusing to sign the documents. On IAP, the kyc status would be equal to 'fail'. Then the user have a possibility to submit a manual

Before this commit, when clicking on refresh and the kyc_status on IAP was 'fail', we put the status on the db to 'fail' and ended the process. This implies creating a new record IAP side even if it is useless and also implies that there could be cases where there would be a mismatch between iap and Odoo.

e.g. The client starts a verification process, he ends up refusing to sign the documents. On IAP, the kyc status would be equal to 'fail'. Then the user have a possibility to submit a manual verification and when submitting it status would go to 'processing'.
The problem is that in the meantime (after refusing but before submitting manual verification), if the user clicks on the refresh button it would ends the process on Odoo and then not going to 'success' on the DB even if it is the case on IAP after Support reviewed the request.

task-6307255

Forward-Port-Of: odoo/odoo#277045
Forward-Port-Of: odoo/odoo#276191

Before this commit, when an authentication process was ongoing it was not very clear to the user This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted. task-6372665 Forward-Port-Of: odoo/odoo#277074 Forward-Port-Of: odoo/odoo#275230

Before this commit, when an authentication process was ongoing it was not very clear to the user
This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted.

task-6372665

Forward-Port-Of: odoo/odoo#277074
Forward-Port-Of: odoo/odoo#275230

In some cases, you want to redirect a record with ModelConverter, whatever the slug value. E.g. /shop/old-name-1 => /shop/alt-product-10 /shop/new-name-1 => /shop/alt-product-10 /fr/shop/nom-1 => /shop/alternatif-product-10 /de/shop/produktname-1 => /de/shop/produktname-10 In this case, adding only one redirect /shop/1 => /shop/10 covers the need to support all the translated slugs and the old name that we remember. On odoo.com we have this need e.g. when we archive a

In some cases, you want to redirect a record with ModelConverter, whatever the slug value.

E.g. /shop/old-name-1 => /shop/alt-product-10
     /shop/new-name-1 => /shop/alt-product-10
     /fr/shop/nom-1 => /shop/alternatif-product-10
     /de/shop/produktname-1 => /de/shop/produktname-10

In this case, adding only one redirect /shop/1 => /shop/10 covers the need to support all the translated slugs and the old name that we remember.

On odoo.com we have this need e.g. when we archive a Job Position, we create a redirect, but in some cases the job position is translated or has been renamed and we don't remember all the old urls. With this change, we will be able to redirect all old urls, translated urls, ... with only one redirect.

/jobs/10 -> /explore-more-opportunities-with-us

task-6391567

Forward-Port-Of: odoo/odoo#276515

Since [website builder refactor], a date field or a datetime that appears in the page is not editable from website builder. This commit re-introduces the ability to do so. [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-6230582 Forward-Port-Of: odoo/odoo#277408 Forward-Port-Of: odoo/odoo#270325

Since [website builder refactor], a date field or a datetime that appears in the page is not editable from website builder.

This commit re-introduces the ability to do so.

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-6230582

Forward-Port-Of: odoo/odoo#277408
Forward-Port-Of: odoo/odoo#270325

This avoids a useless blocking rpc call when opening the systray. Task-6131386 Forward-Port-Of: odoo/odoo#269797

This avoids a useless blocking rpc call when opening the systray.

Task-6131386

Forward-Port-Of: odoo/odoo#269797

When installing the module document_account_peppol, the user has the choice to import his Peppol invoices into the Documents app directly, but also to block the import in Accounting, by removing the Peppol import journal. In that last case, the Peppol application response flow is broken, the document model does not contain the necessary information to handle responses as the imported invoices do. (In stable) We took the decision to remove the ApplicationResponse service from users that bl

When installing the module document_account_peppol, the user has the choice to import his Peppol invoices into the Documents app directly, but also to block the import in Accounting, by removing the Peppol import journal.

In that last case, the Peppol application response flow is broken, the document model does not contain the necessary information to handle responses as the imported invoices do.

(In stable)
We took the decision to remove the ApplicationResponse service from users that block the invoice import flow by removing the import journal.

For PDP, the responses are required, but as the block is completely replaced in the view, and reuses the basic account_peppol condition for the required attribute, the account peppol purchase journal will always be required if the company is registered on Peppol/PDP. Nothing to do in 18.0.

task-6191644

Forward-Port-Of: odoo/odoo#270091

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2059bd0f1d [REL] 19.3.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cc83aaa9a2 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808) https://github.com/odoo/o-spreadsheet/commit/81c80ee9c7 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/2059bd0f1d [REL] 19.3.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/cc83aaa9a2 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808)
https://github.com/odoo/o-spreadsheet/commit/81c80ee9c7 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/60a18e436c [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/53822161e2 [FIX] table computed style: fix render table [Task: 6396322](https://www.odoo.com/odoo/2328/tasks/6396322)
https://github.com/odoo/o-spreadsheet/commit/79cc137d8a [FIX] collaborative: add sheetId as argument to `getClientsToDisplay` [Task: 6408720](https://www.odoo.com/odoo/2328/tasks/6408720)

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>

Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed. runbot error~944206 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merge

Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed.

runbot error~944206

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#277306
Forward-Port-Of: odoo/odoo#276799

# 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-appea

# 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

Forward-Port-Of: odoo/odoo#275077

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification.

See upstream changes:
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization)
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization)

This commit fixes this by refactoring the assertions to treat the output HTML structure as a "black box", verifying data integrity and expected content conversions rather than brittle structural layout.

runbot-938228

Forward-Port-Of: odoo/odoo#277747
Forward-Port-Of: odoo/odoo#275959

Before this commit, when changing the Tip product in the POS settings, the change was reverted and the default Tip product was used instead. opw-6366774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275647

Before this commit, when changing the Tip product in the POS settings, the change was reverted and the default Tip product was used instead.

opw-6366774

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#275647

### Issue before this commit: Sending a TicketBAI invoice to a customer with a Spanish address and a VAT number starting with 'N' (Non-resident entity) resulted in a rejection with error B4_2000027. The XML incorrectly generated the national <DesgloseFactura> tag instead of the required <DesgloseTipoOperacion> tag. ### Steps to reproduce the issue: 1. Download Accounting, l10n_es and l10n_es_edi_tbai 2. Change name to ES Company into “NOMBRE APELLIDOUNO APELLIDODOS” (this is to make sure t

### Issue before this commit:
Sending a TicketBAI invoice to a customer with a Spanish address and a VAT number starting with 'N' (Non-resident entity) resulted in a rejection with error B4_2000027. The XML incorrectly generated the national <DesgloseFactura> tag instead of the required <DesgloseTipoOperacion> tag.

### Steps to reproduce the issue:
1. Download Accounting, l10n_es and l10n_es_edi_tbai
2. Change name to ES Company into “NOMBRE APELLIDOUNO APELLIDODOS” (this is to make sure the certificate for Ticketbai works)
3. Go to Settings → Spain Localization → set Tax Agency for = Bizkaia
4. Change VAT number for customer Mulhacén Digital S.L. into N0011452J (must be a foreign entity ID)
5. Go to Settings > Technical > System Parameters and set the parameter 'l10n_es_edi_tbai.epigrafe' to 165360
6. Create a new invoice for that client and try to send it to TicketBAI
7. Error:  B4_1000002: Todos los registros incluidos en la petición son incorrectos. B4_2000027: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando la factura es completa y, además, existe destinatario extranjero (tipo IDOtro o que sea NIF que empiece por N) o la Clave de IVA es 02.

### Cause of the issue:
The _l10n_es_is_foreign() method evaluated these customers as domestic because their country was set to Spain and their VAT did not start with "ESN". It failed to recognize a standalone "N" prefix as a valid foreign identifier.
https://github.com/odoo/odoo/blob/75ae45861e2f417aa2b90bdb2b2869718e091c09/addons/l10n_es/models/res_partner.py#L7-L10


### Reason to introduce the fix:
Adding the 'N' prefix to the _l10n_es_is_foreign() check ensures the system correctly treats these entities as foreign for tax purposes. This generates the correct XML structure automatically, without forcing users to unnaturally prepend "ES" to a legally valid NIF.

opw-6326359

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276966
Forward-Port-Of: odoo/odoo#275231

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation. Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error. opw-6182687 Forward-P

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation.

Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error.

opw-6182687

Forward-Port-Of: odoo/odoo#277724

Problem: _select_chart_template ranks generic_coa first when no country is given, but compared t[1]['name'] (the display name) against the template code 'generic_coa'. The comparison never matched, so the sort key was constant and the mapping order was left untouched — whichever localized chart came first in the ORM cache won. Solution: Compare t[0] (the template code) instead so the fallback actually takes effect. --- I confirm I have signed the CLA and read the PR guidelines at www.od

Problem:
_select_chart_template ranks generic_coa first when no country is given, but compared t[1]['name'] (the display name) against the template code 'generic_coa'. The comparison never matched, so the sort key was constant and the mapping order was left untouched — whichever localized chart came first in the ORM cache won.

Solution:
Compare t[0] (the template code) instead so the fallback actually takes effect.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

# How to reproduce - In Settings, enable Variants & Product Reference Price - Create a published Product with a Sales Price - Add 2 variants to the Product - In the product's variant list, select the first one & set Base Unit Count to 0, - Set the second variant's Base Unit Count to a value > 0 - Go to the Product's page - Select the second variant # The issue The Reference Price is not displayed for the second variant, even though it should since it has a Base Unit Count > 0. Refresh

# How to reproduce
- In Settings, enable Variants & Product Reference Price
- Create a published Product with a Sales Price
- Add 2 variants to the Product
- In the product's variant list, select the first one & set Base Unit Count to 0,
- Set the second variant's Base Unit Count to a value > 0
- Go to the Product's page
- Select the second variant

# The issue
The Reference Price is not displayed for the second variant, even though it should since it has a Base Unit Count > 0. Refreshing the page while being on the second variant will prevent the bug from happening.

# Cause
When loading the product's info, we call `_onChangeCombination`. This method is responsible for, among other things, updating the reference price and hiding it if Base Unit Count  = 0 :
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/website_sale/static/src/js/variant_mixin.js#L277-L289

To do that, it will search for an html element with the `.o_base_unit_price` css class. If it does not find it, the reference price will not be updated. The issue is that this element is behind a condition in the template :
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/website_sale/views/templates.xml#L2083

When the first time the template is loaded, if
`combination_info.get('base_unit_price')` is False, then the Reference Price will never be added to the view and will never be found by `_onChangeCombination`.

Since our first variant has Base Unit Count = 0, then `base_unit_price` will equal 0, so `combination_info.get('base_unit_price')` will be evaluated to false.

opw-6367289

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276317
Forward-Port-Of: odoo/odoo#274722

Before this commit, when clicking on refresh and the kyc_status on IAP was 'fail', we put the status on the db to 'fail' and ended the process. This implies creating a new record IAP side even if it is useless and also implies that there could be cases where there would be a mismatch between iap and Odoo. e.g. The client starts a verification process, he ends up refusing to sign the documents. On IAP, the kyc status would be equal to 'fail'. Then the user have a possibility to submit a manual

Before this commit, when clicking on refresh and the kyc_status on IAP was 'fail', we put the status on the db to 'fail' and ended the process. This implies creating a new record IAP side even if it is useless and also implies that there could be cases where there would be a mismatch between iap and Odoo.

e.g. The client starts a verification process, he ends up refusing to sign the documents. On IAP, the kyc status would be equal to 'fail'. Then the user have a possibility to submit a manual verification and when submitting it status would go to 'processing'.
The problem is that in the meantime (after refusing but before submitting manual verification), if the user clicks on the refresh button it would ends the process on Odoo and then not going to 'success' on the DB even if it is the case on IAP after Support reviewed the request.

task-6307255

Forward-Port-Of: odoo/odoo#277045
Forward-Port-Of: odoo/odoo#276191

When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image. This fixes the issue by showing a placeholder icon if no module is found for the activity group. opw-6282451 Previous behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/1e4fc1d5-3a35-4193-80fc-f6d161776e2e" /> New behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attac

When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image.

This fixes the issue by showing a placeholder icon if no module is found for the activity group.

opw-6282451

Previous behavior:
<img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/1e4fc1d5-3a35-4193-80fc-f6d161776e2e" />

New behavior:
<img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/6ed5ca8b-8481-470f-b7c6-dd59c616125e" />

(Original PR: https://github.com/odoo/odoo/pull/268957 Re-based on 17.0 as its the earliest version affected, so it can be forward-ported to future versions)

Forward-Port-Of: odoo/odoo#269654

Before this commit, when an authentication process was ongoing it was not very clear to the user This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted. task-6372665 Forward-Port-Of: odoo/odoo#277074 Forward-Port-Of: odoo/odoo#275230

Before this commit, when an authentication process was ongoing it was not very clear to the user
This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted.

task-6372665

Forward-Port-Of: odoo/odoo#277074
Forward-Port-Of: odoo/odoo#275230

In some cases, you want to redirect a record with ModelConverter, whatever the slug value. E.g. /shop/old-name-1 => /shop/alt-product-10 /shop/new-name-1 => /shop/alt-product-10 /fr/shop/nom-1 => /shop/alternatif-product-10 /de/shop/produktname-1 => /de/shop/produktname-10 In this case, adding only one redirect /shop/1 => /shop/10 covers the need to support all the translated slugs and the old name that we remember. On odoo.com we have this need e.g. when we archive a

In some cases, you want to redirect a record with ModelConverter, whatever the slug value.

E.g. /shop/old-name-1 => /shop/alt-product-10
     /shop/new-name-1 => /shop/alt-product-10
     /fr/shop/nom-1 => /shop/alternatif-product-10
     /de/shop/produktname-1 => /de/shop/produktname-10

In this case, adding only one redirect /shop/1 => /shop/10 covers the need to support all the translated slugs and the old name that we remember.

On odoo.com we have this need e.g. when we archive a Job Position, we create a redirect, but in some cases the job position is translated or has been renamed and we don't remember all the old urls. With this change, we will be able to redirect all old urls, translated urls, ... with only one redirect.

/jobs/10 -> /explore-more-opportunities-with-us

task-6391567

Forward-Port-Of: odoo/odoo#276515

Current behavior before PR, [1](https://github.com/odoo/odoo/pull/261837) introduced a rule with higher specificity, overriding the animation-delays of the specific dots in the typing indicator. This caused all dots to jump together at the same time. Desired behavior after PR is merged, the different animation-delays are moved inside the specific rule to correctly apply the delay. Before/After, <img width="125" height="160" alt="bug" src="https://github.com/user-attachments/asset

Current behavior before PR,
[1](https://github.com/odoo/odoo/pull/261837) introduced a rule with higher specificity, overriding the animation-delays
of the specific dots in the typing indicator. This caused all dots to jump
together at the same time.

Desired behavior after PR is merged,
the different animation-delays are moved inside the specific rule to correctly
apply the delay.


Before/After,

<img width="125" height="160" alt="bug" src="https://github.com/user-attachments/assets/8011fe05-6e78-45d6-aee7-a82b7c9bfdd1" />

<img width="125" height="160" alt="expected" src="https://github.com/user-attachments/assets/f367311f-b9a4-4d18-9be1-ae1e7d059a9a" />








---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this fix, if a custom group was added in an Odoo PIVOT in a spreadsheet, without sorting, the custom group name was added to the RPC kwards.order, causing a server error. After this fix, the custom group name is removed from the RPC kwards.order. Task: 6401442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277478

Before this fix, if a custom group was added in an Odoo PIVOT in a spreadsheet, without sorting, the custom group name was added to the RPC kwards.order, causing a server error.

After this fix, the custom group name is removed from the RPC kwards.order.

Task: 6401442



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#277478

Note: In odoo all date/datetime fields are stored and computed by default as UTC Before this commit, dates were called using local timezone getters. This caused the time returned from web to be shifted by the timezone as the dates returned would be treated as UTC. After this commit, dates are now called using UTC timzone getters. Now all web times are retrived as UTC and in sync with the rest of the odoo fields and computations. task-6271421 Forward-Port-Of: odoo/odoo#276683 Forward-Po

Note: In odoo all date/datetime fields are stored and computed by default as UTC

Before this commit, dates were called using local timezone getters. This caused the time returned from web to be shifted by the timezone as the dates returned would be treated as UTC.
After this commit, dates are now called using UTC timzone getters. Now all web times are retrived as UTC and in sync with the rest of the odoo fields and computations.


task-6271421

Forward-Port-Of: odoo/odoo#276683
Forward-Port-Of: odoo/odoo#265250

Problem: Some users with limited access rights cannot access invoices they created, after another user duplicates their sales order and invoices it. Steps to reproduce: 1. Create a user with minimal access rights (only access rights to their own sales orders and invoices). 2. Sign in as that user and create a sales order and confirm it. 3. Create an invoice for that sales order and validate it. 4. Sign in as an administrator and create a duplicate sales order for that sales order, but as

Problem:
Some users with limited access rights cannot access invoices they created, after another user duplicates their sales order and invoices it.

Steps to reproduce:
1. Create a user with minimal access rights (only access rights to their own sales orders and invoices).
2. Sign in as that user and create a sales order and confirm it.
3. Create an invoice for that sales order and validate it.
4. Sign in as an administrator and create a duplicate sales order for that sales order, but assign it to a different user (not the one created in step 1).
5. Confirm the duplicate sales order, create an invoice for it and validate it.
6. Sign in as the user created in step 1 and try to access the invoice created in step 3.
7. Note the access error

Cause:
When reading an account.move record, the system searches for duplicate moves and adds them to the duplicated_ref_ids field. However, it does not check if the user has read access to those duplicate moves, which leads to access errors when trying to access the main account.move record (which the user has read access to) because the system tries to read the duplicate moves (which the user does not have read access to).

opw-6374566

Forward-Port-Of: odoo/odoo#276547

The footer slideout state was computed only once during interaction setup. If the main content height changed afterward, e.g. in edit mode: dropping or removing snippets, or resizing the window, the effect could remain enabled/disabled even though the content had become taller/shorter than the viewport. Steps to reproduce: - Go into edit mode - Add two snippets on the page - On the footer, set the "Slideout Effect" option to "Slide Hover" - Remove one snippet - Half of the footer is

The footer slideout state was computed only once during interaction
setup.
If the main content height changed afterward, e.g. in edit mode:
dropping or removing snippets, or resizing the window, the effect could
remain enabled/disabled even though the content had become
taller/shorter than the viewport.

Steps to reproduce:
- Go into edit mode
- Add two snippets on the page
- On the footer, set the "Slideout Effect" option to "Slide Hover"
- Remove one snippet
- Half of the footer is hidden by the hover effect, which should not
  happen

task-6117257

Forward-Port-Of: odoo/odoo#277614
Forward-Port-Of: odoo/odoo#275291

**Description of the issue/feature this PR addresses:** ---------------------------------------------- On mobile devices, the meeting view had two UI issues affecting the call experience. The call permission dialog could display an unwanted focus outline around its content because the dialog body was focused on touch devices. Additionally, meeting action buttons could be partially hidden, especially in portrait mode, as the meeting view could extend beyond the visible viewport height.

**Description of the issue/feature this PR addresses:**
----------------------------------------------
On mobile devices, the meeting view had two UI issues affecting the call
experience.
The call permission dialog could display an unwanted focus outline around
its content because the dialog body was focused on touch devices.
Additionally, meeting action buttons could be partially hidden,
especially in portrait mode, as the meeting view could extend beyond the
visible viewport height.

**Current behavior before PR:**
----------------------------------------------
- Opening the call permission dialog on mobile could show an unwanted
  focus outline around the dialog content
- Meeting action buttons could be partially hidden on mobile devices
- In portrait mode, the footer could overflow below the visible viewport


**Desired behavior after PR is merged:**
----------------------------------------------
- Call permission dialog opens on mobile without showing the unwanted
focus outline on main body.
- Meeting action buttons remain fully visible on mobile devices


Task-6232825

----------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#266620

**Steps to reproduce:** * Install l10n_fr. * Create an invoice using a tax with the E3 tax grid. * Post the invoice so it is included in the tax report. * Open the French tax report. **Observed Behaviour:** The E3 line is blank even though the amount is present in the report data. The amount is recorded as a negative value, while the report formula expects a positive value, causing it to be deducted from the report total. **Cause:** The E3 tax report expression used the for

**Steps to reproduce:**

* Install l10n_fr.
* Create an invoice using a tax with the E3 tax grid.
* Post the invoice so it is included in the tax report.
* Open the French tax report.

**Observed Behaviour:**

  The E3 line is blank even though the amount is present in the report data. The amount is recorded as a negative value, while the report formula expects a positive value, causing it to be deducted from the report total.

**Cause:**

  The E3 tax report expression used the formula E3, which does not account for tax grid amounts stored as negative values.

**Fix:**

  Update the E3 report expression formula from E3 to -E3 so that negative E3 amounts are correctly displayed in the tax report.

opw - 6321790

Forward-Port-Of: odoo/odoo#274052

#### Description of the issue this PR addresses: - Tables containing only a `<caption>` (or a `<thead>` without a `<tbody>`) could reach the editor with no `<tbody>`. - Since table width and margin are moved to the `<tbody>` during setup in 19.0–19.2, such tables caused the editor to fail. - Table operations such as resizing and adding rows or columns also expect a `<tbody>` to exist. #### Desired behavior after PR is merged: - Tables without a `<tbody>` are normalized during editor setup

#### Description of the issue this PR addresses:
- Tables containing only a `<caption>` (or a `<thead>` without a `<tbody>`) could reach the editor with no `<tbody>`.
- Since table width and margin are moved to the `<tbody>` during setup in 19.0–19.2, such tables caused the editor to fail.
- Table operations such as resizing and adding rows or columns also expect a `<tbody>` to exist.

#### Desired behavior after PR is merged:
- Tables without a `<tbody>` are normalized during editor setup.
- `<thead>` is converted or merged into `<tbody>`.
- A missing `<tbody>` is created when necessary, preventing the editor from crashing.

task-6391354

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276588

Before this commit, the res.users model was not being loaded in the POS when reloading data. If user A was logged in and then on the same device user B logged in, it would not load the new user B data, and it causes user B to not be able to go to the backend. opw-6388954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276546

Before this commit, the res.users model was not being loaded in the POS when reloading data. If user A was logged in and then on the same device user B logged in, it would not load the new user B data, and it causes user B to not be able to go to the backend.

opw-6388954

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#276546

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

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

Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed. runbot error~944206 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merge

Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed.

runbot error~944206

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#277306
Forward-Port-Of: odoo/odoo#276799

In restaurant mode, a direct sale order (no table, no floating order name) has no display name yet when it is sent to the preparation printer. `getName()` returns "Direct sale" in that case, which appeared as the order name on the preparation ticket. Add a `preparationName` getter on `PosOrder` that, for direct sale orders, falls back to `floatingOrderName || pos_reference` so the ticket always shows a meaningful reference. For non-direct-sale orders the getter delegates to `getName()` unchan

In restaurant mode, a direct sale order (no table, no floating order name) has no display name yet when it is sent to the preparation printer. `getName()` returns "Direct sale" in that case, which appeared as the order name on the preparation ticket.

Add a `preparationName` getter on `PosOrder` that, for direct sale orders, falls back to `floatingOrderName || pos_reference` so the ticket always shows a meaningful reference. For non-direct-sale orders the getter delegates to `getName()` unchanged.

Task-6327397

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#276298
Forward-Port-Of: odoo/odoo#271743

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2fb92b4523 [REL] 19.2.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f9a1ba8541 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808) https://github.com/odoo/o-spreadsheet/commit/f09540dff1 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/2fb92b4523 [REL] 19.2.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f9a1ba8541 [FIX] autofill: hide autofill handler when selection is hidden [Task: 6317808](https://www.odoo.com/odoo/2328/tasks/6317808)
https://github.com/odoo/o-spreadsheet/commit/f09540dff1 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/b393ef986e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/3a324a7e75 [FIX] table computed style: fix render table [Task: 6396322](https://www.odoo.com/odoo/2328/tasks/6396322)

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>

The test read the field content for the last urgent save right after resolving modifyImagePromise, without waiting for the DOM to actually reflect the new image src. This raced the async update of the editable content, so beforeUnload sometimes ran before the image src were updated, sending stale content and failing intermittently. Wait for the updated image to appear in the DOM before triggering the last beforeUnload, instead of relying on a fixed animationFrame wait. runbot-243773 ---

The test read the field content for the last urgent save right after resolving modifyImagePromise, without waiting for the DOM to actually reflect the new image src. This raced the async update of the editable content, so beforeUnload sometimes ran before the image src were updated, sending stale content and failing intermittently.

Wait for the updated image to appear in the DOM before triggering the last beforeUnload, instead of relying on a fixed animationFrame wait.

runbot-243773

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

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 con

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

Forward-Port-Of: odoo/odoo#276470

Steps to reproduce: - activate location - create a tracked product A - create a PO with qty=10 with product A - receive them (8 in WH/Stock, 2 in WH/Stock/Shelf 1) - In Reporting/stock filter with "wh/stock" Issue: On hand value will be 0 Cause: "wh/stock did not match _rec_names = 'name' -> WH location is different than "stock" location (who's parent is "WH"). We need to match it with _rec_names_search (1) to match the right location. We fall back on _rec_names in case _rec_name

Steps to reproduce:
- activate location
- create a tracked product A
- create a PO with qty=10 with product A - receive them (8 in WH/Stock, 2 in WH/Stock/Shelf 1)
- In Reporting/stock filter with "wh/stock"

Issue:
On hand value will be 0

Cause:
"wh/stock did not match _rec_names = 'name' -> WH location is different than "stock" location (who's parent is "WH").
We need to match it with _rec_names_search (1) to match the right location.

We fall back on _rec_names in case _rec_names_search would not be defined (not really necessary in here but meh why not be conservative)

(1) https://github.com/odoo/odoo/blob/2bb7493b72b400ed76cc6460c94867fb86de9f3a/addons/stock/models/stock_location.py#L19

opw-6312702

Forward-Port-Of: odoo/odoo#271552

# 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-appea

# 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

Forward-Port-Of: odoo/odoo#275077

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification.

See upstream changes:
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization)
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization)

This commit fixes this by refactoring the assertions to treat the output HTML structure as a "black box", verifying data integrity and expected content conversions rather than brittle structural layout.

runbot-938228

Forward-Port-Of: odoo/odoo#277747
Forward-Port-Of: odoo/odoo#275959

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation. Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error. opw-6182687 Forward-P

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation.

Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error.

opw-6182687

Forward-Port-Of: odoo/odoo#277724

Before this commit, when clicking on refresh and the kyc_status on IAP was 'fail', we put the status on the db to 'fail' and ended the process. This implies creating a new record IAP side even if it is useless and also implies that there could be cases where there would be a mismatch between iap and Odoo. e.g. The client starts a verification process, he ends up refusing to sign the documents. On IAP, the kyc status would be equal to 'fail'. Then the user have a possibility to submit a manual

Before this commit, when clicking on refresh and the kyc_status on IAP was 'fail', we put the status on the db to 'fail' and ended the process. This implies creating a new record IAP side even if it is useless and also implies that there could be cases where there would be a mismatch between iap and Odoo.

e.g. The client starts a verification process, he ends up refusing to sign the documents. On IAP, the kyc status would be equal to 'fail'. Then the user have a possibility to submit a manual verification and when submitting it status would go to 'processing'.
The problem is that in the meantime (after refusing but before submitting manual verification), if the user clicks on the refresh button it would ends the process on Odoo and then not going to 'success' on the DB even if it is the case on IAP after Support reviewed the request.

task-6307255

Forward-Port-Of: odoo/odoo#277045
Forward-Port-Of: odoo/odoo#276191

When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image. This fixes the issue by showing a placeholder icon if no module is found for the activity group. opw-6282451 Previous behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/1e4fc1d5-3a35-4193-80fc-f6d161776e2e" /> New behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attac

When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image.

This fixes the issue by showing a placeholder icon if no module is found for the activity group.

opw-6282451

Previous behavior:
<img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/1e4fc1d5-3a35-4193-80fc-f6d161776e2e" />

New behavior:
<img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/6ed5ca8b-8481-470f-b7c6-dd59c616125e" />

(Original PR: https://github.com/odoo/odoo/pull/268957 Re-based on 17.0 as its the earliest version affected, so it can be forward-ported to future versions)

Forward-Port-Of: odoo/odoo#269654

Adds Corvanis corporate CLA entry so legal/cla can validate contributions from Corvanis contributors. This change only adds: - doc/cla/corporate/corvanis.md - No functional code changes. Forward-Port-Of: odoo/odoo#276949

Adds Corvanis corporate CLA entry so legal/cla can validate contributions from Corvanis contributors.
This change only adds:
- doc/cla/corporate/corvanis.md
- No functional code changes.

Forward-Port-Of: odoo/odoo#276949

Before this fix, if a custom group was added in an Odoo PIVOT in a spreadsheet, without sorting, the custom group name was added to the RPC kwards.order, causing a server error. After this fix, the custom group name is removed from the RPC kwards.order. Task: 6401442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277478

Before this fix, if a custom group was added in an Odoo PIVOT in a spreadsheet, without sorting, the custom group name was added to the RPC kwards.order, causing a server error.

After this fix, the custom group name is removed from the RPC kwards.order.

Task: 6401442



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#277478

After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778

After this advisory:
https://services.gst.gov.in/services/advisoryandreleases/read/661

It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types.

task-6236778

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e80e0276b4 [REL] 18.3.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/42c54d08fe [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) https://github.com/odoo/o-spreadsheet/commit/a53aebf21e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/e80e0276b4 [REL] 18.3.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/42c54d08fe [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/a53aebf21e [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)

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>

Seven entries of the Mexican chart of accounts template carry a name belonging to a **different** group, copied from a neighbouring entry. Each record's XML ID still states the intended name, which is what this restores. | Code | Field | Before | After | |---|---|---|---| | `6` | `name@es` | Gastos generales | Gastos | | `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional | | `602` | `name`, `name@es` | Cost of sales

Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.

| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |

### Why it is not cosmetic

The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:

```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```

whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.

### Evidence

- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
  `Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
  depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
  to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
  XML ID (`account_group_gastos`).

### Notes

Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.

Forward-Port-Of: odoo/odoo#277426

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification. See upstream changes: - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization) - https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization) This commit fixes

The character-by-character HTML assertion in mass mailing tests fails on modern platforms using libxml2 >= 2.14/2.15 due to upstream updates that align HTML serialization, attribute quote management, and escaping rules more closely with the HTML5 specification.

See upstream changes:
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0 (Attribute escaping optimization)
- https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.15.0 (HTML5 spec compliant serialization)

This commit fixes this by refactoring the assertions to treat the output HTML structure as a "black box", verifying data integrity and expected content conversions rather than brittle structural layout.

runbot-938228

Forward-Port-Of: odoo/odoo#277747
Forward-Port-Of: odoo/odoo#275959

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation. Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error. opw-6182687 Forward-P

Firefox has a strict limit of ~640,000 characters for history state serialization and throws NS_ERROR_ILLEGAL_VALUE past it. Chrome and Safari throw DataCloneError past their own undocumented limits (~500MB and ~64MB respectively). When a debounced push() exceeded these limits, the error was unhandled and broke navigation.

Catch these two specific errors and log them instead of crashing, while still resetting the push state and re-throwing any other unexpected error.

opw-6182687

Forward-Port-Of: odoo/odoo#277724

When preparing procurement values from a stock move, the project is retrieved from the sale order through: self.group_id.sale_id.project_id Users with Sales access set to "Own Documents Only" may not have read access to the originating sale order, causing an AccessError when editing manufacturing orders by adding components that use the MTO flow. The fix is to include sudo() for the project lookup, as editing a MO and should not depend on the user's SO visibility. Steps to Reproduce: 1

When preparing procurement values from a stock move, the project is retrieved from the sale order through: self.group_id.sale_id.project_id

Users with Sales access set to "Own Documents Only" may not have read access to the originating sale order, causing an AccessError when editing manufacturing orders by adding components that use the MTO flow.

The fix is to include sudo() for the project lookup, as editing a MO and should not depend on the user's SO visibility.

Steps to Reproduce:
1. Turn on multi-step routes and unarchive the MTO route
2. Create a SO using a product that has a BOM and uses Manufacture/MTO route
3. Logged in as Marc Demo, open the MO and try to add a component. The component must also have the Manufacture/MTO route enabled.
4. You will get an access rights error upon save/confirm.

Related Tickets:
opw-6366029

Forward-Port-Of: odoo/odoo#277345

Stable forward-port source patch. Issue - The turnstile template uses a misspelled variable name in data-appearance: appeareance. - JS provides appearance. - Because of this mismatch, data-appearance always falls back to interaction-only and ?cf=show cannot force always mode. Fix - Replace appeareance with appearance in the turnstile template. Why stable-safe - One-line template fix. - No API/model/signature changes. - No behavior change outside the intended appearance selection. This is int

Stable forward-port source patch.

Issue
- The turnstile template uses a misspelled variable name in data-appearance: appeareance.
- JS provides appearance.
- Because of this mismatch, data-appearance always falls back to interaction-only and ?cf=show cannot force always mode.

Fix
- Replace appeareance with appearance in the turnstile template.

Why stable-safe
- One-line template fix.
- No API/model/signature changes.
- No behavior change outside the intended appearance selection.

This is intended as the 17.0 source fix so forward-porting can propagate to upper versions.

Related: odoo/odoo#273306 and odoo/odoo#273652

Forward-Port-Of: odoo/odoo#273706

Issue ----- Branch companies can have quants of a product limited to their parent company, but they don't show in the per location report. Steps to reproduce ----- - Create a branch company - Create a WH for the branch - Create a tracked product - Company set to parent only - Switch to the branch company - Add a quant of the product in branch stock - Open Inventory > Reporting > Locations > The product is not shown although there is a quant in the branch Cause ----- The m

Issue
-----
Branch companies can have quants of a product limited to their parent company, but they don't show in the per location report.

Steps to reproduce
-----
- Create a branch company
	- Create a WH for the branch
- Create a tracked product
	- Company set to parent only
- Switch to the branch company
	- Add a quant of the product in branch stock
- Open Inventory > Reporting > Locations

> The product is not shown although there is a quant in the branch

Cause
-----
The menu button triggers `action_view_quants`

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/views/stock_quant_views.xml#L493-L495

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L399-L402

The problem here comes from the fact that in `_get_quants_action`, we limit the products to those of only the active companies, instead of allowing to view those of parent companies aswell.

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L1330

Such a change works because the domain is specifically for the product's (`product_id.company_id`) and not the location's.

-----
Ticket:
opw-6131525

**Steps to reproduce:** 1. Install Sales app and open any sale order 2. In the "Terms and conditions" text area at the bottom, apply the "/Switch direction" command for an empty block **Issue:** The feature doesn't work when you apply it on an empty line **Why this happens:** Before the fix, the switch-direction logic depended on selected text nodes, and effectively ignored empty content nodes. **Fix:** The problem has been fixed in 19.4 as an [IMP] in this commit 9c97fc464ffba5088

**Steps to reproduce:**
1. Install Sales app and open any sale order
2. In the "Terms and conditions" text area at the bottom, apply the "/Switch direction" command for an empty block

**Issue:**
The feature doesn't work when you apply it on an empty line

**Why this happens:**
Before the fix, the switch-direction logic depended on selected text nodes, and effectively ignored empty content nodes.

**Fix:**
The problem has been fixed in 19.4 as an [IMP] in this commit 9c97fc464ffba5088642d7699b3e033c1fcc2564, so this is essentially a backport for that fix.

opw-6344750

Issue: --- Adding a rating with a message on website is causing TB as the portal user doesn't have the access to send rating message. opw-6316142 Forward-Port-Of: odoo/odoo#271833

Issue:
---
Adding a rating with a message on website is causing TB as the portal
user doesn't have the access to send rating message.

opw-6316142

Forward-Port-Of: odoo/odoo#271833

After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778

After this advisory:
https://services.gst.gov.in/services/advisoryandreleases/read/661

It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types.

task-6236778

Law 30-26, enacted on June 18, 2026, amends the Dominican Tax Code and introduces new rates that only apply to operations dated after its entry into force: - The ISR withholding on fees, commissions and other remunerations for services provided by individuals raises from 10% to 15%, as a payment on account (art. 309 b, as amended by art. 17 of the law). - The ISR withholding on rents paid to individuals raises from 10% to 15%, as a single and final payment (art. 309 a). - A reduced 15% sing

Law 30-26, enacted on June 18, 2026, amends the Dominican Tax Code and introduces new rates that only apply to operations dated after its entry into force:

- The ISR withholding on fees, commissions and other remunerations for services provided by individuals raises from 10% to 15%, as a payment on account (art. 309 b, as amended by art. 17 of the law).
- The ISR withholding on rents paid to individuals raises from 10% to 15%, as a single and final payment (art. 309 a).
- A reduced 15% single and final ISR withholding replaces the general 27% remittance withholding for payments abroad of software licenses and subscriptions, royalties, online advertising and cloud data storage services (arts. 305-1 and 305-2, effective June 18, 2026).
- The tax on checks and electronic transfers raises from 1.5 to 2.0 per thousand (0.20%), effective July 3, 2026 (art. 382 of Law 288-04, as amended).

The previous rates remain applicable to operations prior to the entry into force of the law, so the existing taxes are kept unchanged and the new rates are added as separate taxes.

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

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ff598a772e [REL] 17.0.104 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/30768e0885 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589) https://github.com/odoo/o-spreadsheet/commit/b46950d130 [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/ff598a772e [REL] 17.0.104 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/30768e0885 [FIX] HeaderVisibility: fix `getNextVisibleCellPosition` getter [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)
https://github.com/odoo/o-spreadsheet/commit/b46950d130 [FIX] edition: do not change edition if not editing [Task: 6340589](https://www.odoo.com/odoo/2328/tasks/6340589)

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>

Currently, sending a simplified invoice (`TD07`) to the Italian Tax Agency fails when an invoice line contains multiple taxes. **Steps to reproduce:** - Install the `l10n_it_edi_withholding` module and switch to an IT Company. - Create a new customer and set only the country to Italy and the Tax ID. - Create a new invoice for that customer. - Add a line with `22%` and `4% INPS` taxes. - Go to the `Electronic Invoicing` tab, set the `Document Type` to `TD07 - Simplified invoice`, and c

Currently, sending a simplified invoice (`TD07`) to the Italian Tax
Agency fails when an invoice line contains multiple taxes.

**Steps to reproduce:**
- Install the `l10n_it_edi_withholding` module and switch to an IT Company.
- Create a new customer and set only the country to Italy and the Tax ID.
- Create a new invoice for that customer.
- Add a line with `22%` and `4% INPS` taxes.
- Go to the `Electronic Invoicing` tab, set the `Document Type` to
 `TD07 - Simplified invoice`, and confirm the invoice.
- Try to `Send To Tax Agency`.

**Error:**
`Node: <Natura t-if="line.tax_ids.l10n_it_exempt_reason" t-out="line.tax_ids.l10n_it_exempt_reason"/>`
`ValueError: Expected singleton: account.tax(102, 3)`

**Root Cause:**
At [1], the code accesses `line.tax_ids.l10n_it_exempt_reason`, but when an
invoice contains multiple taxes, causing an error.

**Fix:**
This commit prevents the error and ensures the user can send a simplified 
invoice by applying a fix similar to [2].

[1]:
https://github.com/odoo/odoo/blob/230483ffd7d8674cd6bf98a4ffb6591f755422e0/addons/l10n_it_edi/data/invoice_it_simplified_template.xml#L14

[2]:
https://github.com/odoo/odoo/blob/230483ffd7d8674cd6bf98a4ffb6591f755422e0/addons/l10n_it_edi/data/invoice_it_template.xml#L28-L181

Ticket [link](https://www.odoo.com/odoo/project.task/6354138)
Ticket [link](https://www.odoo.com/odoo/project.task/6379377)
opw-6354138
opw-6379377

## Problem: Whitespace formatting in email template xmls (newline and tab) would find their way into the html editor, and would be made visible after interacting with feff injection. ## Solution: We will sanitize mail templates as they are loaded, removing any unnecessary formatting whitespace. ## Steps to replicate (runbot v17): 1. Open an email template (Purchase: Purchase Order) 2. Place your cursor at the very end of a t-out element that precedes another bit of text (like 'P00015')

## Problem:
Whitespace formatting in email template xmls (newline and tab) would find their way into the html editor, and would be made visible after interacting with feff injection.

## Solution:
We will sanitize mail templates as they are loaded, removing any unnecessary formatting whitespace.

## Steps to replicate (runbot v17):
1. Open an email template (Purchase: Purchase Order)
2. Place your cursor at the very end of a t-out element that precedes another bit of text (like 'P00015'), then type a character. 5 ` ` characters will be inserted after your character.

opw-6124284