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

Currently, an error occurs when a user sets an employee on a payslip.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Create an `employee` and make sure that the employee's version has no `contract start date`.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and set that employee.

`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

When a user sets an employee on a payslip, the system computes the worked day lines [1]. 
If the salary structure uses worked day lines, it creates the corresponding records [2] and 
calculates out days and out hours based on the contract dates.
During this process, the payslip dates are compared with the version's contract start date. 
If the version does not have a contract start date, it raises an error [3].

This commit ensures that the payslip dates are compared with the version's contract start date, 
and that out days and out hours are calculated only when the contract start date exists. Cases 
where no contract start date is defined are already handled in payslip [4].

[1]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1964

[2]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1985-L1988

[3]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/l10n_hk_hr_payroll/models/hr_payslip.py#L309

[4]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1092-L1096

sentry-7632216317

Currently, when a quotation is created from a repair order generated from a helpdesk ticket, 
the salesperson is not set on the quotation even if the customer has a salesperson assigned.

**Steps to Reproduce:**

 - Install `helpdesk_repair`.
 - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams`.
 - Open a team recod and enable `Repairs`.
 - Create a `contact/customer` with a `salesperson` assigned.
 - Go to `Helpdesk`, create a ticket for that `customer`, and select the `helpdesk team` 
   configured above.
 - Click `Repair`, then click `Create Quotation`.
 - Open the quotation and check the `Salesperson` field in the `Other Info` tab.

**Current behavior:**
The Salesperson field on the quotation remains empty.

**Expected behavior:**
The Salesperson field on the quotation should inherit the salesperson assigned to the 
selected customer/contact.

**Cause of the issue:**
When a repair order is created from a helpdesk ticket, default_user_id [1] is passed in the context . 
This value is propagated when creating the repair order [2] . Later, when creating the quotation from 
the repair order [3], the same context is reused.
Because default_user_id is already present in the context, it overrides the precomputation of user_id 
from the customer. As a result, user_id is initialized with an empty value and remains unset.

**Fix:**
This commit ensures that default_user_id is removed from the context before creating the 
sale order. Without a default value for user_id, the field is correctly precomputed from the 
selected customer, and the salesperson is properly assigned.
[1]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L52

[2]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L36-L40

[3]: https://github.com/odoo/odoo/blob/29328b8fccff833c14de317b51f3b4e5a8c40f75/addons/repair/models/repair.py#L357

opw-6344939

Forward-Port-Of: odoo/enterprise#126310
Forward-Port-Of: odoo/enterprise#122980

**Step To Reproduce:**

1. Configure a POS with German Fiskaly (l10n_de_pos_cert), Restaurant, and Kitchen Display (pos_preparation_display).
2. Create a new order in the POS and add the first product.
3. Observe that the order does not appear on the Kitchen Display.
4. Add a second product to the same order.
5. Observe that the order now appears on the Kitchen Display.

**Issue:**

The first product of a new restaurant order is not synchronised with the Kitchen Display when the German Fiskaly localisation is enabled.

**Reason:**

`syncAllOrders()` only processes orders returned by `getPendingOrder()` and ignores orders explicitly passed through `options.orders`. After the initial Fiskaly synchronisation, the order is serialised and removed from the pending queue. Consequently, the Preparation Display synchronisation receives no orders from `getPendingOrder()`, preventing the order from reaching the backend.

**Solution:**

Update `syncAllOrders()` to prioritize the orders explicitly provided through `options.orders`. When `options.orders` is not available, fall back to the existing behavior by synchronizing the orders from `orderToCreate` and `orderToUpdate`.

opw-6321376

Forward-Port-Of: odoo/enterprise#125743

### Issue:
When a `stock.move.line` is manually added to a component move of a Manufacturing Order via the debug View button, it is not linked to the MO

This causes the line to appear without a `production_id` in Move History (shown in gray in 18.3+ instead of colored)

### Cause:
`production_id` is set on move lines in `_action_assign`, overridden in `mrp` to propagate MO-specific data: https://github.com/odoo/odoo/blob/e8d4ea2dc71109e9afc5b894c9359bcfc08295ae/addons/mrp/models/stock_move.py#L352-L358

In the normal flow, `_action_assign` is called by `_action_confirm` on the `stock.move`:
https://github.com/odoo/odoo/blob/737e28b9c8609d488d93ce7ce05941ff93779e04/addons/stock/models/stock_move.py#L1644-L1646

But when a line is added manually, the move is already created with state `assigned`, so `_action_confirm` skips the call and `_action_assign` is never executed

### Fix:
Setting `production_id` in `_action_assign` was incorrectly placed — there is no reason to set it during move assignment
Moving it to the move line creation avoids the issue entirely and removes the dependency on a code path that may not be triggered

### Steps to reproduce:
- Install `mrp`
- Create a BoM for a tracked product with 2 tracked components
- Enable Developer mode
- Create a Manufacturing Order for the product
- Unhide the View button on a component move and click it
- Add a new line for the first component (qty: 1)
- Confirm and Produce All the MO
- Go to Inventory > Reporting > Move History
- Add `production_id` via Studio (or check line color in 18.3+)

Before the fix, the manually added line has no `production_id` (and in 18.3+ the line is gray instead of colored)

opw-6250911

Forward-Port-Of: odoo/odoo#272035

In a MO for a product tracked by serial number, when changing the serial number after confirming the mo, it will silently assign a serial number.

**Steps to reproduce**

* Create three products:
  - "Component"
  - "Final" with a bom containing "Component" and tracked by Serial number
  - "Setup" with a bom containing "Final"
* Create and confirm a MO for "Setup"
  - assign the serial number "PROD" to "Final"
* Produce "Setup"
* Create and confirm a MO for "Final"
* Generate a serial number
* Clear the serial number
* Generate a new serial number
* Produce "Final" 
-> In Product Moves you can see that the serial number assign was "PROD"

**Observation**

First when creating the MO, it will create a stock move for "final" and create a stock move line without assigning any quant. action_confirm -> _action_assign
https://github.com/odoo/odoo/blob/ff0dd8fcc8dfbb5e5cb798c90d68be41d56b7b4c/addons/stock/models/stock_move.py#L1643-L1646 
In _action_assign it will bypass_reservation since the location is "production": https://github.com/odoo/odoo/blob/ff0dd8fcc8dfbb5e5cb798c90d68be41d56b7b4c/addons/stock/models/stock_move.py#L1948 https://github.com/odoo/odoo/blob/ff0dd8fcc8dfbb5e5cb798c90d68be41d56b7b4c/addons/stock/models/stock_location.py#L411-L413 
and create the sml:
https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/stock/models/stock_move.py#L2048

When adding the Serial number it will be added to lot_producing_ids, set qty_producing and call set_qty_producing ->_set_quantity_done -> _set_quantity_done_prepare_vals: https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/mrp/models/mrp_production.py#L1593-L1597 
In set_qty_producing->_set_quantity_done ->_set_quantity_done_prepare_vals nothing will be done since there already is a stock move line with the right quantity: https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/stock/models/stock_move.py#L2368-L2371

Second when clearing the Serial number it will call action_clear_lot_producing_ids, where it will
  - Erase the lot from lot_producing_ids
  - Set qty_producing to 0
  - and call _set_qty_producing _set_qty_producing -> _set_quantity_done -> _set_quantity_done_prepare_vals: where it will erase the stock move line since it's new quantity is 0: https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/stock/models/stock_move.py#L2353-L2355

Lastly this means that when add in the new lot, it will not already have a stock move line, and it will create a new stock move line based on available quants: https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/stock/models/stock_move.py#L2392-L2402

The lot_ids on the moves is supposed the get assigned when we produce the product: https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/mrp/models/mrp_production.py#L1911-L1913

opw-6240857

Forward-Port-Of: odoo/odoo#268542

## Problem
When computing qty_delivered on a sale order line, intercompany 'delieveries' from the other company would count towards the delivery total.

## Solution
When retreiving the relevant moves for quantity calculation (_get_outgoing_incoming_moves), we will filter out any moves not belonging to the SOL's company. This will prevent moves from other companies into the interco location from being counted towards qty_delivered.

## Steps to Replicate (runbot v19)
1. Create a route
    - Pull Comp B -> Interco, MTO, Comp B delivery
    -  Pull Interco -> Comp A, MTS, Comp A receipt
    (You can review the test for more info about this route config)
    (There is also this video showcasing the issue on runbot: https://drive.google.com/file/d/1YeUie4EhWPyg_RuJkNf40S9zARB4jXWY/view)
2. Attach a product to this new route
3. Create a SO for the product and confirm it
4. You should see 4 pickings, validate the chain
5. The qty_delivered on the sale order is double the demand

opw-6361559

Forward-Port-Of: odoo/odoo#275694

**Issue**
The height is not correctly computed in the picking form when editing product description.

**Steps to reproduce**
- Create a delivery for a product
- Add a description to it
- Click on editing the description
 -> Observe that the description is partially hidden because the widget height is incorrectly computed

**Cause**
Since commit https://github.com/odoo/odoo/commit/e4f4171e1bc838840c0bd6111cd78f348b201ac2, `useProductAndLabelAutoresize` no longer assigns a height to the widget root.

The corresponding widget is `MoveProductLabelField`, which extends `ProductNameAndDescriptionField`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/stock/static/src/views/picking_form/stock_move_product_label.js#L5 It uses `useProductAndLabelAutoresize`:
https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/product/static/src/product_name_and_description/product_name_and_description.js#L54-L56 
**Solution**
Explicitly add a div around the product display and description to still use the `Autoresize`

Forward-Port-Of: odoo/odoo#271564

### 1. Prevent tour failure by waiting on the correct loading class

Before this PR, the tour introduced in commit [1] and modified in commit [2] could fail non-deterministically because it waited for `o_we_ui_loading` to disappear. However, this class was added with a delay in `operation.js`, allowing the next tour step to run before the loader was shown.

After this commit, the tour waits for `o_loading_screen`, which is added immediately and remains visible until the operation finishes. This ensures that the tour waits correctly before proceeding.

[1]: https://github.com/odoo/odoo/commit/091b8dee407fe30a115d4bb2e96d4d
[2]: https://github.com/odoo/odoo/commit/544a03775119021442d66486c24711

**runbot:** [941508](https://runbot.odoo.com/odoo/error/941508)

---

### 2. Prevent tour failure by clicking the "Close" button instead of pressing "Escape"

Before this PR, the tour step introduced in commit [1], which pressed the <kbd>Escape</kbd> key to close the Insert Snippet dialog, could fail non-deterministically with the error:

> It is not allowed to do action on an element that's below a modal.

After this PR, instead of pressing <kbd>Escape</kbd>, the tour clicks the **Close** (`X`) button to close the dialog. This is a more reliable way to close the dialog and prevents the non-deterministic failure of the sync color shape tour.

[1]: https://github.com/odoo/odoo/commit/544a03775119021442d66486c24711d

**runbot:** [944543](https://runbot.odoo.com/odoo/error/944543)

---

### 3. Prevent tour failure by adding steps to open sliding panel for color-related options

Before this PR, the tour introduced in commit [1] and modified in commit [2] was breaking, because it expected the color-related options to be directly available under the theme tab. However, after commit [3], the color-related controls were moved into a sliding panel.

This PR adds the missing steps to open the sliding panel before accessing the color-related options, allowing the tour to complete successfully.

[3]: https://github.com/odoo/odoo/commit/8e104a3a416781a903f3b3b4b77e5f8be24fc7b0

**runbot:** [944587](https://runbot.odoo.com/odoo/error/944587)

Forward-Port-Of: odoo/odoo#279395
Forward-Port-Of: odoo/odoo#278743

recently in 19.1 a commit adds a warning and disables the button in the signup for if you are alreafy logged in. The issue is that for websites without the header (which is the case for internal, but can happen to customers) there is no way to get to the homepage (except from writing to the url or hiting the back button)

This created an issue in internal as an example, since our customers have aparently bookmarked the login page, and they would simply login again before this. For some people, since they would access the page so often, google automatically fill up the url when they type odoo to odoo/web/login

This commit aims to introduce a link to the home page that will be displayed in the warning message. This way cusotmers can get to the home page, and we will hopefully stop the support tickets this has created

opw-6331783

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

Problem:
When testing the import of contacts with a user without accounting access rights, the test fails and leads to an error.

Steps to reproduce:
1- Remove accounting access rights from your user (Set Accounting to No) 2- Open Contacts app
3- Try importing contacts (you can download the available template and use it as the file you are asked to upload)
4- Test the import
5- Notice the error you receive

Cause:
When importing contacts, the commercial fields (fields related to the contact's parent) are loaded and then written. Some of these fields may have access rights that the user trying to import doesn't have. As a result, when trying to load/write them, the user may get an error.

Solution:
Use sudo() when loading them. This shouldn't be an issue since they are only copied from the parent. Also, sudo() is already being used when writing the values,
https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/odoo/addons/base/models/res_partner.py#L996 so sudo() should also be used when loading them.

opw-6396086

Forward-Port-Of: odoo/odoo#278638

*:mrp_subcontracting_purchase

Issue before this commit:
========================
- In inter-warehouse transfers with `multi-step delivery` and in multi-step manufacturing flows, demand moves were not correctly counted in the monthly demand.

- Also, direct transfers to customer and subcontracting locations generated from `orderpoint` were also not counted correctly (when checked before move scheduled on the same day). This resulted in lower monthly demand values than the actual demand and could lead to inaccurate purchase planning.

Steps to Reproduce:
=========================
- Install `purchase_stock` module and enable multi-step routes.
- Set the Outgoing Shipments in the warehouse to 2-step/3-step.
- Create a second warehouse and configure it to `resupply from another warehouse`.
- Create a storable product and assign a vendor.
- Create an orderpoint for the product in the second warehouse, set the route to the warehouse resupply route, and trigger the replenishment.
- Go to Purchase → Create RFQ for the vendor and open the catalog.
Observation:
The replenishment transfer demand is not correctly counted in the monthly demand

Cause of the issue:
=========================
- In [PR](https://github.com/odoo/odoo/pull/244180), the monthly demand move domain was updated to filter out intermediate customer delivery moves using `move_dest_ids.origin_returned_move_id`. However, inter-warehouse replenishment delivery moves also have `move_dest_ids` linked to receipt moves of the other warehouse, but `origin_returned_move_id is not set` since they are not return move Because of this, these valid demand moves were incorrectly excluded from the monthly demand computation.
- Also, in inter-warehouse flows with multi-step delivery, `delivery moves` stay in the `waiting state` since they wait for another operation, so they were also not counted. Additionally, `orderpoint-triggered` moves use a `fixed midday scheduled time`, and since monthly demand was computed using the current timestamp as the limit  date, same-day moves could be excluded if checked before midday.

After This Commit:
=========================
- The monthly demand move domain was updated to correctly count inter-warehouse, manufacturing, and subcontracting resupply demand moves while still avoiding inflated demand from intermediate moves. The move state domain was also updated to `include waiting moves` in multi-step flows, and the limit date now uses the full current day so same day moves are counted correctly.

Enterprise PR: odoo/enterprise#115944
TaskID-5490137

Forward-Port-Of: odoo/odoo#279853
Forward-Port-Of: odoo/odoo#262435

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

When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line.

This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and bypassed calling `super()` on them. Consequently, if a line already had an analytic distribution (such as inheriting the project's), the system would skip computing the product's specific distribution rules entirely.

This commit resolves the issue by reverting that change, ensuring the base compute method is always called so product-based rules execute correctly. While this means manual analytic entries added before the compute trigger might be overwritten, there is no perfect solution to prevent losing both manual and product distributions. As concluded with the Product Owner in a similar PR for Purchase Orders, we prioritize keeping the product's automated distribution, as it is much harder to manually reconstruct after its removal.

The corresponding test is also reverted to its original state to reflect this expected behavior. A small test is added to ensure that the analytic distribution results are unchanged when adding a project to the SO.

opw-6279406

**Steps to Reproduce:**

- Accounting > Configuration > Settings > Analytics > enable Analytic Accounting
- Accounting > Configuration > Analytic Accounting > Analytic Distribution Models
  - Create a new model with any product (e.g. “Bolt”) and any Analytic Distribution (e.g. “Production”)
- Create SO, enable “Analytic Distribution” in filters
  - Add any customer, add the above product (e.g. “Bolt”), save
  - Observe that the “Production” Analytic Distribution is automatically populated
- On the same SO > Other Info> Project > add (e.g. “Home Construction”)
  - Then go back to Order Lines and remove the previous SOL and create a new one with the same product > save
  - Observe that the “Production” Analytic Distribution is not added (although “Home Construction” is)


**Current behavior before PR:**

- Product analytic distributions are not automatically applied when the Sales Order is already linked to a project

**Desired behavior after PR is merged:**

- Product analytic distributions are automatically applied even when the Sales Order is linked to a project

**Note:**

This commit basically ports a fix/revert (https://github.com/odoo/odoo/commit/54852978617cfb2d8c5afdcf80adbf6c0605093c) introduced to the project_purchase module for the same issue. Their commit message is quite detailed in explaining the issue. To quote:

>However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic
distribution, as it is much harder to add it again after its removal.
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.

The referenced initial commit is here: https://github.com/odoo/odoo/commit/3dfa98bd3b9d5ababe3a7548d604e22350023799

Forward-Port-Of: odoo/odoo#274893

Steps to reproduce
1. Create two products and assign the same vendor to both in the Purchase tab
2. Create two Sales Orders using the dropship route (one product per order)
3. Generate and merge the corresponding Purchase Orders, then confirm the merged PO
4. Validate the dropship transfer

Issue
stock.picking.sale_id is a Many2one (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/sale_stock/models/stock.py#L99)
computed from procurement.group.sale_id, and stock.picking.group_id is a
stored related on move_ids.group_id (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/stock/models/stock_picking.py#L186).
A single picking can therefore only resolve to one SO. _create_picking
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order.py#L290)
builds one picking per PO and _prepare_stock_moves assigns every move
the merged PO's group_id
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order_line.py#L307),
so when a merged dropship PO carries lines from multiple SOs every move
lands in one picking under the PO group. Only one SO gets linked and
the others stay "not fully delivered" even after validation.

Solution
Override PurchaseOrderLine._prepare_stock_moves to set group_id to the
SO's procurement_group_id when sale_line_id is set, so each dropship
move is created in its originating SO's procurement group.

Override PurchaseOrder._create_picking to detect dropship POs whose
order lines span more than one SO and create one picking per SO group
by calling _prepare_picking and _create_stock_moves per group.
picking.group_id then resolves to the SO group via the stored related
field, picking.sale_id points to the right SO, and delivery_status
updates correctly on validation.

opw-6094608

Forward-Port-Of: odoo/odoo#279843
Forward-Port-Of: odoo/odoo#257823

**Description of the issue/feature this PR addresses:**
`test_search_date_category` is failing across runbot builds

Remove the blanket deletion of all repair orders at the start of test_search_date_category and replace the exact count assertion with assertIn. This avoids interfering with other test data and makes the test resilient to pre-existing records in the database.

**Current behavior before PR:**
```
ERROR: TestRepair.test_search_date_category
Traceback (most recent call last):
  File "/data/build/odoo/addons/repair/tests/test_repair.py", line 915, in test_search_date_category
    self.env['repair.order'].search([]).unlink()
  File "/data/build/odoo/addons/rating/models/mail_thread.py", line 21, in unlink
    result = super().unlink()
             ^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/mail/models/mail_thread.py", line 391, in unlink
    res = super(MailThread, self).unlink()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/mail/models/models.py", line 46, in unlink
    result = super().unlink()
             ^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/models.py", line 4131, in unlink
    func(self)
  File "/data/build/odoo/addons/repair/models/repair.py", line 421, in _unlink_except_confirmed
    repairs_to_cancel.action_repair_cancel()
  File "/data/build/enterprise/quality_repair/models/repair.py", line 114, in action_repair_cancel
    res = super().action_repair_cancel()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/repair/models/repair.py", line 475, in action_repair_cancel
    raise UserError(_("You cannot cancel a Repair Order that's already been completed"))
odoo.exceptions.UserError: You cannot cancel a Repair Order that's already been completed
```
**Desired behavior after PR is merged:**
`test_search_date_category` passes

opw-[4998413](https://www.odoo.com/odoo/my-tasks/4998413)
runbot.build.error-[231146](https://runbot.odoo.com/odoo/runbot.build.error/231146)

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

Forward-Port-Of: odoo/odoo#267852

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