Before this commit, expect.waitForSteps and expect.waitForErrors gave 2 seconds, less than the 3 seconds of the DOM waits sitting next to them, on the same page and the same RPCs. Over 340 call sites in addons tests reach waitForSteps and not one of them passes an explicit timeout, so 2 seconds is what every step wait gets.

The problem is that the RPC chain a step wait sits on takes longer than that on a loaded machine. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the steps are in, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

Companion of https://github.com/odoo/odoo/pull/279983 to fix https://runbot.odoo.com/odoo/error/944188 kind of issues.

Forward-Port-Of: odoo/odoo#279984

**PROBLEM**
When using fixed tax not affecting the base on line with discount, the xml generated is invalid and refused by peppol.

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create an invoice with the following line:
  - qty: 2, price_unit: 100, discount: 10%, taxes: 21% + fixed tax 1€
  - qty: -2, price_unit: 0, taxes: fixed tax 1€
3. Generate an xml, and try validating it on peppol.
4. The validation fails with the error: [BR-27]-The Item net price (BT-146) shall NOT be negative.

**CAUSE**
Fixed tax not affecting the base of other tax are dispatched into new base lines and then merged into one line per fixed tax.
The new base lines they are dispatched to are created as a copy of the line they originated from.
It means we copy the discount from the original lines.
The fixed tax amount is the unit price of each new base lines.
When reducing the base lines into one line, we take the unit prices of the line, and apply the discount to the unit price.
But, since the unit price is the fixed tax amount, and fixed tax are not affected by discounts, we shouldn't apply discount.

**PROBLEM 2**
fixed division by 0 traceback when the aggregation of invoice lines is 0

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create the following invoice:
  - qty: 1, unit_price: 100, tax:0% + fixed tax 1€, set an analytic distribution account
  - qty: -1, unit_price: 50, tax:0% + fixed tax 1€, set the same analytic distribution account
3. Send the invoice to peppol.
4. A division by 0 should occur.

opw-6388219

Forward-Port-Of: odoo/odoo#276945

Before this commit, expect.waitForSteps and expect.waitForErrors gave 2 seconds, less than the 3 seconds of the DOM waits sitting next to them, on the same page and the same RPCs. Over 340 call sites in addons tests reach waitForSteps and not one of them passes an explicit timeout, so 2 seconds is what every step wait gets.

The problem is that the RPC chain a step wait sits on takes longer than that on a loaded machine. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the steps are in, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

Companion of https://github.com/odoo/odoo/pull/279983 to fix https://runbot.odoo.com/odoo/error/944188 kind of issues.

Forward-Port-Of: odoo/odoo#279984

**PROBLEM**
When using fixed tax not affecting the base on line with discount, the xml generated is invalid and refused by peppol.

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create an invoice with the following line:
  - qty: 2, price_unit: 100, discount: 10%, taxes: 21% + fixed tax 1€
  - qty: -2, price_unit: 0, taxes: fixed tax 1€
3. Generate an xml, and try validating it on peppol.
4. The validation fails with the error: [BR-27]-The Item net price (BT-146) shall NOT be negative.

**CAUSE**
Fixed tax not affecting the base of other tax are dispatched into new base lines and then merged into one line per fixed tax.
The new base lines they are dispatched to are created as a copy of the line they originated from.
It means we copy the discount from the original lines.
The fixed tax amount is the unit price of each new base lines.
When reducing the base lines into one line, we take the unit prices of the line, and apply the discount to the unit price.
But, since the unit price is the fixed tax amount, and fixed tax are not affected by discounts, we shouldn't apply discount.

**PROBLEM 2**
fixed division by 0 traceback when the aggregation of invoice lines is 0

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create the following invoice:
  - qty: 1, unit_price: 100, tax:0% + fixed tax 1€, set an analytic distribution account
  - qty: -1, unit_price: 50, tax:0% + fixed tax 1€, set the same analytic distribution account
3. Send the invoice to peppol.
4. A division by 0 should occur.

opw-6388219

Forward-Port-Of: odoo/odoo#276945

Before this commit, expect.waitForSteps and expect.waitForErrors gave 2 seconds, less than the 3 seconds of the DOM waits sitting next to them, on the same page and the same RPCs. Over 340 call sites in addons tests reach waitForSteps and not one of them passes an explicit timeout, so 2 seconds is what every step wait gets.

The problem is that the RPC chain a step wait sits on takes longer than that on a loaded machine. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the steps are in, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

Companion of https://github.com/odoo/odoo/pull/279983 to fix https://runbot.odoo.com/odoo/error/944188 kind of issues.

Forward-Port-Of: odoo/odoo#279984

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

closes odoo/odoo#276581

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

Steps to reproduce:
1. Install Calendar
2. Create a meeting in Calendar in form view
3. Set the video link on it
4. Turn on the debug mode
5. Now, clear the video link

Issue:
- Traceback
```
Uncaught Promise > Invalid props for component 'CopyButton': 'content' is not a string or object or function
```

Cause:
- The 'CopyButton' component expect content to be a string, object or function but receives false.
  It does not happen in previous versions because in the refector https://github.com/odoo/odoo/commit/c2f34517b2f9832a498981d0fa17ec39b9739cb6 set the `videocall_location` to false instead of empty string like before https://github.com/odoo/odoo/blob/499420f7062ab467ff6f50b30c547e54c35ae1e9/addons/web/static/src/core/copy_button/copy_button.js#L14
- but any field using the `CopyClipboardChar/CopyClipboardURL` widget passes its raw field value straight through as content. An empty char/text field is represented as false, so whenever such a field becomes empty, CopyClipboardField hands `false` to CopyButton, which fails prop validation (debug mode).


Solution:
- Fix it at the source: CopyClipboardField's template now falls back to an empty string when the field value is falsy,
  so CopyButton never receives false but a valid string.

opw-6360936

Forward-Port-Of: odoo/odoo#275236

[FIX] html_builder: prevent crash on legacy image shapes
When the Website Editor encounters an image shape that does not exist
in the registry, it fatally crashes upon saving (`TypeError: Cannot
read properties of undefined`), blocking the user from saving the page.

While an upgrade script exists to remap these shapes
([commit https://github.com/odoo/odoo/commit/f348be018f5740a31754494c905ea2b61bb718be](https://github.com/odoo/upgrade/commit/f348be0dcbc63c1f74f742b562509f81767564c0)),
timeline gaps leave SaaS databases vulnerable. For example, if a client
upgraded their database to 17.0 in Feb 2024, they bypassed the migration
script merged in Dec 2024. This leaves the legacy shape permanently
orphaned inside their modern views.

This commit adds a `getImageShape` fallback. Instead of crashing,the
editor now defaults to standard values and renders "None" in the UI,
allowing the user to select a new shape and save their work.

Steps to Reproduce:
1. Install Website.
2. Go to Site -> HTML / CSS Editor.
3. Add `data-shape="web_editor/basic/bsc_organic_2"` to an <img> tag.
4. Click "Edit" to open the Website Builder.
5. Click the image, OR click "Save".
6. JS traceback.

[opw-6286044](https://www.odoo.com/odoo/my-support-tasks/6286044?debug=assets)
[opw-6291591](https://www.odoo.com/odoo/my-support-tasks/6291591?debug=assets)

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

Forward-Port-Of: odoo/odoo#270356

## Problem

`pttExtensionHookService` registers a global `window.addEventListener("message", ...)`
handler that reads `data.from` without checking that `data` is defined first:

```js
browser.addEventListener("message", ({ data, origin, source }) => {
    const rtc = env.services["discuss.rtc"];
    if (
        source !== window ||
        origin !== location.origin ||
        data.from !== "discuss-push-to-talk" ||   // <- crashes if data is undefined
        (!rtc && data.type !== "answer-is-enabled")
    ) {
        return;
    }
    ...
```

Any same-window, same-origin `postMessage` sent by an unrelated browser
extension (a common content-script <-> injected-script pattern) can carry
`data === undefined`. The `source !== window` and `origin !== location.origin`
checks only filter out cross-window/cross-origin messages, so a same-origin
message from any other extension reaches this handler and crashes with:

```
TypeError: Cannot read properties of undefined (reading 'from')
```

This surfaces as an uncaught client error on any page with Discuss loaded,
after some time, unrelated to what the user is doing. The Discuss
push-to-talk extension itself does not need to be installed to trigger it,
since the crash happens before checking whether the message actually
originated from that extension.

## Solution

Use optional chaining (`data?.from`) so unrelated same-origin messages with
no `data` are safely ignored instead of crashing.

## Verification

- Reproduced against the live production `web.assets_web.min.js` bundle
  (traceback matches exactly).
- Confirmed the bug is still present in the latest `18.0` of both `OCA/OCB`
  and `odoo/odoo` (no newer commit touches this file since
  `dc58ef1ad904`, which fixes an unrelated issue).

Forward-Port-Of: odoo/odoo#279920
Forward-Port-Of: odoo/odoo#279476

Steps to reproduce:
- Open any PoS session
- Click on Orders and filter by "Paid" orders
- Select an order and click on "Details"
- Open the "Payments" tab and click on the "View" button of a payment
- Click on the payment method link

Traceback:
OwlError: The following error occurred in onWillStart: "Cannot find key "pos_payment_provider_cards" in the "view_widgets" registry"

Backend views opened from within the PoS UI (order details dialog, drill-down on many2one links, ...) share their arch with the backend, but `point_of_sale._assets_pos` excludes everything under `static/src/backend/`, so widgets defined there (e.g. `pos_payment_provider_cards`, `lna_checklist`,
`point_of_sale_test_epos`) are never registered in the PoS UI. Unlike missing field widgets, which fall back to the default widget with a warning, an unknown `<widget>` node makes the whole view crash since `Widget.parseWidgetNode` reads the registry without a fallback.

Those widgets are backend configuration helpers that are irrelevant in a PoS session, so instead of bundling each of them (and any future one) in the PoS assets, patch `Widget.parseWidgetNode` in the PoS bundle to skip unknown widgets with a warning, like missing field widgets do. This covers the form, list and kanban arch parsers at once.

opw-6382156

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

Forward-Port-Of: odoo/odoo#279255
Forward-Port-Of: odoo/odoo#276912

**PROBLEM**
When using fixed tax not affecting the base on line with discount, the xml generated is invalid and refused by peppol.

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create an invoice with the following line:
  - qty: 2, price_unit: 100, discount: 10%, taxes: 21% + fixed tax 1€
  - qty: -2, price_unit: 0, taxes: fixed tax 1€
3. Generate an xml, and try validating it on peppol.
4. The validation fails with the error: [BR-27]-The Item net price (BT-146) shall NOT be negative.

**CAUSE**
Fixed tax not affecting the base of other tax are dispatched into new base lines and then merged into one line per fixed tax.
The new base lines they are dispatched to are created as a copy of the line they originated from.
It means we copy the discount from the original lines.
The fixed tax amount is the unit price of each new base lines.
When reducing the base lines into one line, we take the unit prices of the line, and apply the discount to the unit price.
But, since the unit price is the fixed tax amount, and fixed tax are not affected by discounts, we shouldn't apply discount.

**PROBLEM 2**
fixed division by 0 traceback when the aggregation of invoice lines is 0

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create the following invoice:
  - qty: 1, unit_price: 100, tax:0% + fixed tax 1€, set an analytic distribution account
  - qty: -1, unit_price: 50, tax:0% + fixed tax 1€, set the same analytic distribution account
3. Send the invoice to peppol.
4. A division by 0 should occur.

opw-6388219

Forward-Port-Of: odoo/odoo#276945

Before this commit, expect.waitForSteps and expect.waitForErrors gave 2 seconds, less than the 3 seconds of the DOM waits sitting next to them, on the same page and the same RPCs. Over 340 call sites in addons tests reach waitForSteps and not one of them passes an explicit timeout, so 2 seconds is what every step wait gets.

The problem is that the RPC chain a step wait sits on takes longer than that on a loaded machine. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the steps are in, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

Companion of https://github.com/odoo/odoo/pull/279983 to fix https://runbot.odoo.com/odoo/error/944188 kind of issues.

Forward-Port-Of: odoo/odoo#279984

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

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

## Issue
When generating an invoice for a service product with an invoicing policy based on timesheets, the amount of hours invoiced is wrong if there exists a credit note linked to that SO.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Create on Order: Task
    - Project: Any project
    - Invoicing Policy: Based on Timesheets
3. Create a SO
    - Any Customer
    - Product P (any quantity)
    - Confirm the SO
4. In the created task, add a timesheet entry
    - Date: Today
    - Time Spent: 10:00 (10 hours)
5. Create and confirm the invoice for the SO
6. Create a Credit Note from the invoice, set the quantity to 4 hours, and confirm it
7. From the created task, add a second timesheet entry
    - Date: Any future date (e.g., today + 7)
    - Time Spent: 15:00 (15 hours)
8. Create a second invoice, but set a Timesheets Period that only covers the second timesheet entry
9. **The quantity on the newly created invoice is 9 hours, even though we're clearly trying to invoice the 15 hours from the second timesheet entry.**

## Cause
The second invoice is impacted by the credit note generated from the first one. When generating that second invoice, the [`_recompute_qty_to_invoice`](https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L149) method incorrectly computes the amount to invoice by taking into account `account.analytic.line` from outside the provided range.

The delivered quantity is correctly calculated by taking into account the provided range (through the `start_date` and `end_date` added to the domain passed to `_get_delivered_quantity_by_analytic`:

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L176-L180

But then, for each `sale.order.line`, we look at the related `account.analytic.line` without taking into account the provided dates, which leads to lines outside of the range impacting the invoice.

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L182-L193

In the example described in the *Steps to reproduce*, we start with a (correct) amount delivered of 15.0, we find two `invoice_lines_to_calculate` (the invoice of 10 hours, and the credit note of 4 hours), which leads to the quantity to invoice being set to `15 - (-4 + 10) = 9`. This seems like an odd behavior as it:
- doesn't invoice all the hours within the provided range (15 hours within the range, and we're only invoicing 9)
- doesn't invoice **all** the hours left to be invoiced (6 hours are already invoiced, 25 should be in total, and we're invoicing 9)

opw-6373870

Steps to reproduce:
- From the website editor, open the Theme tab.
- Upload a custom font.
- Open the media dialog and go to the "Documents" tab.

Issue:
The uploaded font files appeared in the Documents tab. When a zip file was uploaded, every font it contained appeared individually, along with the generated "CSS font face" attachment.

Cause:
Fonts uploaded through `/website/theme_upload_font` are created as public attachments. The Documents tab of the media dialog lists every public attachment that is not an image or an asset, so the font files (mimetype `font/...`), their font face declaration (mimetype `text/css`) and googleFontMetadata (server caches it as public attachment) were listed.

Fix:
Exclude those attachments from the Documents tab domain:
- whose mimetype starts with `font/`,
- whose description matches the font face declarations created in `snippets.options.js`.
- whose name equals "googleFontMetadata".

task-[4771523](https://www.odoo.com/odoo/project/974/tasks/4771523)

The product specifications table is displayed whenever the product has tags, even if none of them are visible on the ecommerce website.

The product tags template filters out non-visible tags, but the surrounding table remains rendered and appears empty.

Only display the tags table when at least one tag is visible on ecommerce.

@Tecnativa TT63855

**Description of the issue/feature this PR addresses:**

The condition used to display the product tags table considers all tags associated with the product, including those that are not visible on ecommerce.

**Current behavior before PR:**

When a product only has non-visible tags, the tags table is displayed without any content.

<img width="669" height="350" alt="image" src="https://github.com/user-attachments/assets/4758ea76-5186-4035-a065-aa4c71ce7053" />


**Desired behavior after PR is merged:**

The tags table is only displayed when the product has at least one tag visible on ecommerce.




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