Motivation ---------- Each database served keeps a full registry in a process-wide LRU. The LRU is bounded by a count, so on a server hosting thousands of databases the number of retained registries follows traffic rather than memory pressure. Their combined footprint can push a worker past its virtual-memory soft limit, at which point it is killed and restarted. On a server with ~2500 databases, the soft limit is reached at ~180 resident databases while the LRU could still hold ~210, so HT

Motivation
----------
Each database served keeps a full registry in a process-wide LRU. The LRU is bounded by a count, so on a server hosting thousands of databases the number of retained registries follows traffic rather than memory pressure. Their combined footprint can push a worker past its virtual-memory soft limit, at which point it is killed and restarted.

On a server with ~2500 databases, the soft limit is reached at ~180 resident databases while the LRU could still hold ~210, so HTTP workers were being recycled under normal load.

Tracking usage
--------------
Every request for a registry goes through the single lookup in the registry constructor, which now stamps it with a monotonic timestamp; the stamp is also set when a registry is first built.

Collecting idle registries
--------------------------
A collection pass drops every registry whose last use is older than the configured idle timeout. It runs at the end of registry loading, so it fires periodically as databases come and go.

Registries that are still loading are skipped, so a concurrent build is never collected. Dropping a registry only detaches it from the LRU: a request still holding a reference keeps working, and the next lookup rebuilds it.

The timeout is read from ODOO_REGISTRY_MAX_IDLE_TIMEOUT, in seconds; a value of zero, the default, disables the mechanism so behaviour is unchanged unless it is opted into.

Results
-------
With a five-minute timeout on the same ~2500-database server, the HTTP workers settle at around 40 resident registries instead of saturating memory on the long run. The gevent worker, which sees every web client reconnect at startup and briefly fills the LRU with ~150 databases, releases most of them on the first pass, reclaiming the memory.

On a real-life SaaS server with 64GB of RAM, that frees up to ~10GB which were previously taken by unused registries in the LRU. It comes at the expense of extra registry recomputes, but on the other hand workers do not reach their virtual memory limit anymore.

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

Unlink operations are logged by default, which is useful for auditing most records. However, unlink operations on last interest records and cron triggers happen frequently and provide little auditing value. This PR mutes the unlink logger for these records to avoid filling the logs with repetitive entries, especially when a large number of messages are posted in parallel. task-6400122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Unlink operations are logged by default, which is useful for auditing most records. However, unlink operations on last interest records and cron triggers happen frequently and provide little auditing value.

This PR mutes the unlink logger for these records to avoid filling the logs with repetitive entries, especially when a large number of messages are posted in parallel.

task-6400122



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

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

in odoo/odoo#260278, the repair linked lines (stock moves and account move lines) were refactored in order to handle newer changes in a cleaner way but the `_clean_repair_linked_lines` method call was missing its braces. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

in odoo/odoo#260278, the repair linked lines
(stock moves and account move lines) were refactored in order to handle newer changes in a cleaner way but the `_clean_repair_linked_lines` method call was missing its braces.




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

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

v19 WIoT Boxes will be listening on localhost when updating to v19.1+, we need to ensure they use `http_interface = 0.0.0.0` after the update. Forward-Port-Of: odoo/odoo#276655 Forward-Port-Of: odoo/odoo#272063

v19 WIoT Boxes will be listening on localhost when updating to v19.1+, we need to ensure they use `http_interface = 0.0.0.0` after the update.

Forward-Port-Of: odoo/odoo#276655
Forward-Port-Of: odoo/odoo#272063

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

Steps: - Enable `pos_hr` and configure employees - Open the POS - Log in as an employee - Open the burger menu in the navbar Issue: - The "Create Product" menu is not visible immediately after the employee logs in. - It only appears after refreshing the POS. Cause: - The visibility of the menu is determined when `Navbar` component is mounted. - Since the `Navbar` is mounted only once when the POS UI loads, the value is not updated after employee login. Fix: - Replace the asynch

Steps:
- Enable `pos_hr` and configure employees
- Open the POS
- Log in as an employee
- Open the burger menu in the navbar

Issue:
- The "Create Product" menu is not visible immediately after the employee logs in.
- It only appears after refreshing the POS.

Cause:
- The visibility of the menu is determined when `Navbar` component is mounted.
- Since the `Navbar` is mounted only once when the POS UI loads, the value is not updated after employee login.

Fix:
- Replace the asynchronous permission check with a getter that evaluates product creation rights.
- Cache the group access information in `posService` and let the hr override use the getter.

Task-6361787

Related PR: https://github.com/odoo/enterprise/pull/123073

Forward-Port-Of: odoo/odoo#277753
Forward-Port-Of: odoo/odoo#274420

Current behavior before PR: - Updating a chart granularity was overriding searchParams from `definition.searchParams` instead of `definition.dataSource.searchParams.` - Since `definition.searchParams` is undefined, all existing search parameters, such as domain, were lost. Desired behavior after PR is merged: - Read searchParams from definition.dataSource.searchParams before updating the granularity. - This preserves the existing search parameters while updating only the group

Current behavior before PR:
- Updating a chart granularity was overriding searchParams from
  `definition.searchParams` instead of `definition.dataSource.searchParams.`
- Since `definition.searchParams` is undefined, all existing search parameters,
  such as domain, were lost.

Desired behavior after PR is merged:
- Read searchParams from definition.dataSource.searchParams before
  updating the granularity.
- This preserves the existing search parameters while updating only the
  groupBy value.

Task: [6377572](https://www.odoo.com/odoo/project/2328/tasks/6377572)

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

Forward-Port-Of: odoo/odoo#276244

**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

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

Issue: On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left. Steps to reproduce: - Create a customer - Add a Delivery address to the customer - Ensure "Customer Address" is not set in the settings - Choose a layout with the address on the left (bubble, wave, ...) - Create an invoice to the customer - print the PDF Current behavior:

Issue:
On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left.

Steps to reproduce:
- Create a customer
- Add a Delivery address to the customer
- Ensure "Customer Address" is not set in the settings
- Choose a layout with the address on the left (bubble, wave, ...)
- Create an invoice to the customer
- print the PDF

Current behavior:
- Customer address is on the right

Expected behavior:
- Customer address is on the left

Cause:
Address is displayed on the right if there is an information bloc . The information bloc was set to an empty div. Therefore, as it is set, address was displayed on the right.

opw-6334130

Forward-Port-Of: odoo/odoo#275771
Forward-Port-Of: odoo/odoo#273418

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

The builder HOOT tests were flaky when run as a suite while passing in isolation: - @website/builder/images: "Should format an image to be 800px", "should set the quality of an image to 50", and the gif/svg "Correct options appear..." tests, - @html_builder/image: "Size should not be displayed on CORS protected images". All failed the same way: a `contains(":iframe ... img")` click found the img but "0 visible elements" after 200ms, i.e. the image never got pixels in time. The images of t

The builder HOOT tests were flaky when run as a suite while passing in isolation:
- @website/builder/images: "Should format an image to be 800px", "should set the quality of an image to 50", and the gif/svg "Correct options appear..." tests,
- @html_builder/image: "Size should not be displayed on CORS protected images".

All failed the same way: a `contains(":iframe ... img")` click found the img but "0 visible elements" after 200ms, i.e. the image never got pixels in time. The images of those tests are loaded by the browser from the *real* test server (element loads cannot be mocked by HOOT), and the requests were stuck for seconds behind other requests started by earlier tests and never awaited:

- test fixtures used made-up snippet thumbnails (data-oe-thumbnail="a.svg", or none at all, rendering "background-image: url(undefined)"). Relative to the test runner page, these resolve to /web/a.svg, /web/undefined... and each triggers a full website 404 page rendering on the server (~90 queries, taking seconds under load). One full @html_builder run produced 71 such requests, some taking up to 17s, starving the browser's connection pool.
- the mock of /html_editor/modify_image in "Save image with correct parameter" returned the obsolete {image_src, access_token, public} shape; saveModifiedImage reads newAttachmentUrls["original"], so the saved img src became the literal string "undefined" -> GET /web/undefined.
- the mocked attachment creations in the pasted/dropped image tests returned made-up URLs (/test_image_url.png, /url_image-1.png) that the editor sets as img src on save -> more expensive 404s.

Fix:
- don't render a background-image at all when a snippet has no thumbnail (also avoids the bogus url(undefined) request outside of tests),
- use a data URI as thumbnail in the default test fixtures,
- return the correct modify_image response shape, and existing static images (served in milliseconds) for the mocked attachment URLs,
- give the CORS-protected test image explicit width/height so that its visibility (checked before clicking it) does not depend on the server's response time at all.

Note that these failures predate the owl v3.0.0-alpha.44 update (they reproduce identically on the commit before it): repeatedly running the full suites while investigating the update's fallout simply surfaced them.

@html_builder went from 71 to 7 stray 404s (the few remaining come from fixtures whose thumbnail names are asserted on, they are harmless in isolation), and both @html_builder (395 tests) and @website/builder (557 tests) suites now pass reliably.

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

**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, calls to the route `/shop?search=<search_term>` would lead the search for `product_public_categories` to use a query in the shape of `product_id in (<list_of_ids>)`. In the case where the cardinality of the product table becomes large (> 10k products), if `search_term` is very broad-spectrum, the length of `list_of_ids` reaches the size of the product table. In that case the query generated to search for categories becomes significantly slow to parse (> 14 seconds in our te

Before this commit, calls to the route `/shop?search=<search_term>` would lead the search for `product_public_categories` to use a query in the shape of `product_id in (<list_of_ids>)`.
In the case where the cardinality of the product table becomes large (> 10k products), if `search_term` is very broad-spectrum, the length of `list_of_ids` reaches the size of the product table.
In that case the query generated to search for categories becomes significantly slow to parse (> 14 seconds in our tests).

This commit proposes as an alternative to resort to a sub-query to fetch the product ids that are relevant in the context of `product_public_categories`. Because of how the list of products is acquired initially, we can't rely on the `_search()` method to generate the sub-query.

The following table shows average gains for "increasing search term specificity". Here, "specificity" is determined by the amount of characters in the search term and the related number of hits expected from the search.

### Cardinality ~250k records
| Metric | ~228,872 hits | ~2,870 hits | ~377 hits | ~11 hits |
| :--- | :--- | :--- | :--- | :--- |
| Before Fix | 14.027s | 5.726s | 3.183s | 3.139s |
| After Fix | 1.216s | 3.794s* | 1.330s | 1.301s |

### Cardinality 10k records
| Metric | 8,897 hits | 1,122 hits | 15 hits | 0 hits |
| :--- | :--- | :--- | :--- | :--- |
| Before Fix | 1.386s | 3.232s* | 0.580s | 0.395s |
| After Fix | 0.756s | 3.410s* | 0.772s | 0.572s |


*Note: The increase in response time in the second column is caused by a different execution path taken (fuzzy search) which becomes the most significant path in terms of execution time once the other queries are optimized.

opw-6299343

Forward-Port-Of: odoo/odoo#275306
Forward-Port-Of: odoo/odoo#271306

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

Issue: On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left. Steps to reproduce: - Create a customer - Add a Delivery address to the customer - Ensure "Customer Address" is not set in the settings - Choose a layout with the address on the left (bubble, wave, ...) - Create an invoice to the customer - print the PDF Current behavior:

Issue:
On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left.

Steps to reproduce:
- Create a customer
- Add a Delivery address to the customer
- Ensure "Customer Address" is not set in the settings
- Choose a layout with the address on the left (bubble, wave, ...)
- Create an invoice to the customer
- print the PDF

Current behavior:
- Customer address is on the right

Expected behavior:
- Customer address is on the left

Cause:
Address is displayed on the right if there is an information bloc . The information bloc was set to an empty div. Therefore, as it is set, address was displayed on the right.

opw-6334130

Forward-Port-Of: odoo/odoo#275771
Forward-Port-Of: odoo/odoo#273418

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

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

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

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

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

This commit adds `company_register` VAT Registry (VAT ID) to the invoice header for [legal reasons](https://lex.uz/ru/docs/4948595#5225819). Also, the condition for `TIN` has been updated to be 14 digits if the contact is a person and 9 digits if it is a company. Upgrade PR: https://github.com/odoo/upgrade/pull/10679 task-6205255

This commit adds `company_register` VAT Registry (VAT ID) to the invoice header for [legal reasons](https://lex.uz/ru/docs/4948595#5225819). Also, the condition for `TIN` has been updated to be 14 digits if the contact is a person and 9 digits if it is a company.

Upgrade PR: https://github.com/odoo/upgrade/pull/10679
task-6205255

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

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

e39bf6c6ab31e57d472a552cb9b902496e6323ae introduced a blacklist to email sending, to filter out "alias emails" (catchall...) & the root partner email (odoobot) from being sent certain emails, such as mailings. By default, odoobot email is odoobot@example.com. However, there are cases where users will have a legitimate partner that matches the odoobot email; an example of this is saas config, which automatically changes the odoobot email to the admin email set on database spin-up. This

e39bf6c6ab31e57d472a552cb9b902496e6323ae introduced a blacklist to email sending,
to filter out "alias emails" (catchall...) & the root partner email
(odoobot) from being sent certain emails, such as mailings.

By default, odoobot email is odoobot@example.com. However, there are
cases where users will have a legitimate partner that matches the
odoobot email; an example of this is saas config, which automatically
changes the odoobot email to the admin email set on database spin-up.

This prevents the database admin from receiving their own mailings.

To fix this, the root partner email is now only added to the blacklist
if no active partner has the same email.

Steps to reproduce:
- Add a mailing contact with the same email as the root partner
- Send a mailing to that mailing contact

task-4893615

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing. Steps to reproduce: - create a product in Units with available stock - create a delivery for 2 Dozen of it and mark it as todo - in the detailed operations, change the unit of the move line to Units (24) - lower the

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing.

Steps to reproduce:
- create a product in Units with available stock
- create a delivery for 2 Dozen of it and mark it as todo
- in the detailed operations, change the unit of the move line to Units (24)
- lower the move quantity from 2 to 1 Dozen

The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer.

Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease.

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

Forward-Port-Of: odoo/odoo#276774

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

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

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/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

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

The mail.message/delete bus handler accessed selfMember?.seen_message_id.id with optional chaining only on selfMember, not on seen_message_id. When a member has never seen any message in a channel (seen_message_id is False), accessing .id threw 'TypeError: can't access property id, selfMember.seen_message_id is undefined', breaking message deletion for that user (e.g. deleting a message in a channel the user never opened. Add optional chaining on seen_message_id so the unread counter is simpl

The mail.message/delete bus handler accessed selfMember?.seen_message_id.id with optional chaining only on selfMember, not on seen_message_id. When a member has never seen any message in a channel (seen_message_id is False), accessing .id threw 'TypeError: can't access property id, selfMember.seen_message_id is undefined', breaking message deletion for that user (e.g. deleting a message in a channel the user never opened.

Add optional chaining on seen_message_id so the unread counter is simply not decremented when no message has been seen yet.


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

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

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

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

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

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: . Add safe execution to the element before use focus() task-6409715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:

. Add safe execution to the element before use focus()

task-6409715

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

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

When a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a registry recompute server-side, so a tight reconnection window makes all of those recomputes land together and pile up on the freshly started process. The jitter added to each reconnection delay was only one second, far too narrow to break up that wave. Widen it to thirty seconds so the retries of the m

When a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a registry recompute server-side, so a tight reconnection window makes all of those recomputes land together and pile up on the freshly started process.

The jitter added to each reconnection delay was only one second, far too narrow to break up that wave. Widen it to thirty seconds so the retries of the many clients fan out over a much wider window and the registry recomputes spread over time instead of colliding.

Raise the ceiling on the retry delay to two minutes to match that wider spread, and drop the exponential growth factor: with a thirty-second jitter accumulating on every attempt, the delay already climbs on its own, so scaling it further only pushed clients toward the ceiling sooner without spreading them any better.

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

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/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

_stock_account_anglo_saxon_reconcile_valuation() scans a whole invoice on every call and only reconciles at the end, but _validate_accounting_entries() calls it once per product. The invoice is therefore re-scanned as many times as there are products. This can lead to performance issues when the invoices contain thousands of lines. Steps to reproduce: - use anglo-saxon accounting with automated inventory valuation - confirm a sale order holding a few thousand distinct products -

_stock_account_anglo_saxon_reconcile_valuation() scans a whole invoice on every call and only reconciles at the end, but
_validate_accounting_entries() calls it once per product. The invoice is therefore re-scanned as many times as there are products.

This can lead to performance issues when the invoices contain thousands of lines.

Steps to reproduce:
  - use anglo-saxon accounting with automated inventory valuation
  - confirm a sale order holding a few thousand distinct products
  - invoice it, then validate its delivery => performance issue

Group the products by their related invoices and reconcile each group in one call.

Delivering 20 products against a 5000 line invoice goes from 63s to 9.7s. On the reported customer database a delivery of 197 products, against an invoice grouping 27 orders and carrying 17822 journal items, goes from 369s to 16s.

Benchmark:
| Invoice Lines | Before | After |
|--------------:|-------:|------:|
| 100 | 1.9s | 0.7s |
| 1 000 | 13.0s | 2.0s |
| 5 000 | 63.3s | 9.7s |

opw-6388781