This fix ensures the confirmation message appears only after an appointment link has actually been copied. It prevents timing-related failures in automated checks, making appointment and CRM scheduling flows more reliable.

Prior to this commit, the success notification for copying an appointment link to the clipboard was triggered synchronously, while the actual `navigator.clipboard.writeText` execution was deferred inside a `setTimeout`.

This caused a race condition (depending on the browser's cpu load) during tours (e.g., `appointment_crm_meeting_tour`). The tour would proceed and restore the mocked clipboard object (`oldWriteText`) before the deferred `setTimeout` block had a chance to execute.

This commit fixes the issue by moving the notification logic inside the `setTimeout` callback. The tour is also updated to wait explicitly for the success notification before cleaning up the clipboard mock and proceeding to discard the slots.

runbot-241004

Forward-Port-Of: odoo/enterprise#124439

Certificates added through emSigner now appear correctly aligned in signed PDF documents after recent emSigner interface and API changes. This prevents visibly misplaced certificate stamps and helps keep signed documents looking accurate and professional.

Before:
- Certificate added by emSigner was misaligned in the signed PDF after recent UI changes.

After:
- Updated coordinates to ensure the emSigner certificate is properly aligned and displayed correctly in Odoo.

task-6105264

Forward-Port-Of: odoo/enterprise#113402

The point of sale barcode lookup flow now checks product creation permissions in a more direct and consistent way. This helps ensure users only see or use product creation options when their access rights allow it, reducing confusing behavior at checkout.

Replace the asynchronous `allowProductCreation` method with the `hasProductCreationAccess` getter to evaluate product creation permissions synchronously and ensure consistent behavior.

Task-6361787
Related PR: https://github.com/odoo/odoo/pull/274420

Forward-Port-Of: odoo/enterprise#125147
Forward-Port-Of: odoo/enterprise#123073

This fix prevents an error when users or integrations move Uruguayan electronic invoices back to draft status. It ensures the action completes cleanly, improving reliability for accounting workflows that use this localization.

Calling the method in RPC causes an error:
```
TypeError: cannot marshal None unless allow_none is enabled
```

Forward-Port-Of: odoo/enterprise#124740
Forward-Port-Of: odoo/enterprise#124653

Belgian VAT return submissions can include comments in the generated XML again. This restores a previously available capability that was removed by mistake, helping businesses submit the extra context required for their tax filings.

This feature had been mistakenly removed.

Forward-Port-Of: odoo/enterprise#124865

Embedded views in Knowledge now keep the intended top alignment when they appear as the first editable item in an article. This prevents a small layout glitch caused by editor selection placeholders, making Knowledge pages look consistent while editing.

This commit updates the embedded view top-alignment selector to account for selection placeholders introduced by https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d.

This preserves the intended top-alignment behavior when an embedded view is the first editable element in the knowledge editor.

Task-5951196

Forward-Port-Of: odoo/enterprise#125080

This update fixes an inconsistent automated test in Odoo Studio that could fail unpredictably. It helps keep quality checks stable, reducing false alarms during development without changing user-facing behavior.

runbot-error-940371

## Problem When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop. ## Solution We will pull the order name directly from the order line in the current iteration. ## Steps to reproduce (Runbot v19) 1. Create a product with AVCO perpetual valuation 2. Make sure all accounts are configured properly (I

## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit. Steps to reproduce: - create a delivery method with a maximum weight of 10 kg - create a product in Units weighing 1 kg with Dozens in its allowed units - create a delivery transfer of 2

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277708
Forward-Port-Of: odoo/odoo#277425

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

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