2 props were misconfigured:

- `countryID` Previous fix: https://github.com/odoo/odoo/commit/319bb52dcb022bd67b0d7349d5720221d6e1d7c4 made it so `country_id` would correctly register as a "many2one", but this made it conflict when it was passed as a `countryId` prop which expects it to be a number, rather than a many2one object.

- `selectedLocationId` OWL3 conversion in https://github.com/odoo/odoo/commit/55fd748ada717df5b27376c81a8eba53d9b8ddac incorrectly converted `selectedLocationId` to `optional(false)

https://github.com/odoo/odoo/blob/f5c1d2210f18d1644a7ce67fca806f5c5db3df69/addons/website_sale_stock/static/src/js/location_selector/location_selector_dialog/location_selector_dialog.js#L11-L16

Steps to reproduce:
- Create new Sales Order
- Add a customer + product of type "Goods"
- Click "Add shipping" and select "Pick up in store" delivery method
- Click on Pencil button in same row as "Pickup Point" field

Expected Behavior:
Pickup Location selector dialog should open

Actual Behavior:
Stacktrace due to `"selectedLocationId", "message": "value is not a string"` or `"countryId", "message": "value is not a number"`

Note that error doesn't occur when selecting pick up points via the website (i.e. ecommerce flow), possibly due to the props enforcement not occurring in the front end.

opw-6321167


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

On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po.

Steps to reproduce:
-------------------
* Create a PO and confirm it
* Open the receipt, validate and duplicate it
* Go on the duplicated receipt and change its Operation Type
* Confirm the duplicated receipt. 
-> the Received Qty on the Po counted the duplicated and modified transfer.

Observation:
-------------
When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892
https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15
the ```purchase_line_id``` will keep the link with the pol.
The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304

Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76
opw-6088239

Forward-Port-Of: odoo/odoo#276250
Forward-Port-Of: odoo/odoo#259570

Selecting an online media-library illustration for a product image (or any field using the media dialog) saved the wrong image, or failed with "Please try to reupload this image" or a "raw is undefined" crash.

Steps to reproduce
==================
1. Open a product and edit its image
2. In "Select a media", search a term (e.g. "new")
3. Click one of the online library illustrations

=> The wrong image is saved, or an error notification is shown

Root cause
==========
Library media results carry a media-library id, not a local ir.attachment id.
imageSave persists them as real attachments (save_library_media, run inside super.save) but then reads them back using the original media-library id. That id either collides with an unrelated local attachment, e.g. a type='url' demo record with no raw, hence the wrong image and the "reupload" warning or matches no record at all, so the read returns undefined and accessing .raw throws.

Fix
===
Use the ids of the attachments actually created by the render step, carried on the rendered <img> elements (dataset.attachmentId), instead of the media-library ids.

opw-6353273

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

Forward-Port-Of: odoo/odoo#274372

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

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

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

opw-6374566

Forward-Port-Of: odoo/odoo#277823
Forward-Port-Of: odoo/odoo#276547

Steps to Reproduce
---
- Create a normal parent task with one normal sub-task and one template sub-task.
- Open the parent task form view and observe the Sub-tasks stat button count and
notebook tab, check the subtask view as well.
- Create a template parent task with one normal sub-task and one template sub-task,
then repeat the same checks.

Issue
---
- Task templates are handled like regular subtasks in the subtask count, notebook, and
subtask view, without taking the parent task type into account.
- test_create_project_from_template_with_task_template_without_project
creates a template subtask without a project under a regular task.
With the child_ids domain only keeping valid template ,
a template task is no longer included when its parent is not a
template.

Current Behaviour
---
- For a normal parent task, both the normal sub-task and the template sub-task are
counted and shown in the opened subtask view and notebook.
- For a template parent task, the same filtering is applied, even though template subtasks
should remain accessible in that context.

Expected Behaviour
---
- For a normal parent task, only real sub-tasks should be counted and shown in the subtask
view and notebook, and on the project kanban card.
- For a template parent task, template subtasks should remain available in the subtask
view and notebook according to the parent template context.
-In the project kanban card, tasks must not be counted when their parent task is a template,
 even if the child task itself is not a template.

Fix
---
- Apply template-aware filtering to subtask counting,project kanban task count and subtask view
 behavior, depending on whether the parent task is a normal task or a template task.
- Update the test so the task template without a project is under
task_template_inside_template instead of the regular task.

task-5966684

Forward-Port-Of: odoo/odoo#275901
Forward-Port-Of: odoo/odoo#252403

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941

Forward-Port-Of: odoo/odoo#274677

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Forward-Port-Of: odoo/odoo#277640
Forward-Port-Of: odoo/odoo#272161

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

Forward-Port-Of: odoo/odoo#277227
Forward-Port-Of: odoo/odoo#276688

The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly sets `tax_ids` from the product, and the computed `tax_ids_after_fiscal_position` displays the mapped taxes in the UI. However, because `tax_ids` is readonly, the web client does not include it in the save payload. As a result, the taxes are silently dropped on save and `tax_ids_after_fiscal_position` recomputes to empty.

Steps to reproduce:
1. Create and pay a POS order with a product that has taxes
2. Go to the backend (Point of Sale > Orders) and open that order
3. Initiate a return for the order
4. In the return order, add a new product (exchange scenario)
5. Observe that taxes are correctly shown on the new line
6. Click Save
7. The taxes disappear from the order line

The fix adds `force_save="1"` to the `tax_ids` field in both the list and form views of `pos.order.line`, consistent with how `price_subtotal` and `price_subtotal_incl` are already handled in the same views.


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

Forward-Port-Of: odoo/odoo#269944
Forward-Port-Of: odoo/odoo#253680

Issue:
When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details.

Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country.

Steps to reproduce:
- Configure a Swiss company with a QR IBAN bank account
- Set the sales journal Communication Standard to Switzerland
- Create and confirm an invoice for a non swiss customer (US, BE)
- Observe in the pdf and in the other info tab -> no payment reference or payment details

Cause:
`get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated.

Solution:
Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency.

opw-6222417

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

Forward-Port-Of: odoo/odoo#272617
Forward-Port-Of: odoo/odoo#266861

On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po.

Steps to reproduce:
-------------------
* Create a PO and confirm it
* Open the receipt, validate and duplicate it
* Go on the duplicated receipt and change its Operation Type
* Confirm the duplicated receipt. 
-> the Received Qty on the Po counted the duplicated and modified transfer.

Observation:
-------------
When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892
https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15
the ```purchase_line_id``` will keep the link with the pol.
The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304

Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76
opw-6088239

Forward-Port-Of: odoo/odoo#276250
Forward-Port-Of: odoo/odoo#259570

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

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

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

opw-6374566

Forward-Port-Of: odoo/odoo#277823
Forward-Port-Of: odoo/odoo#276547

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941

Forward-Port-Of: odoo/odoo#274677

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Forward-Port-Of: odoo/odoo#277640
Forward-Port-Of: odoo/odoo#272161

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

Forward-Port-Of: odoo/odoo#277227
Forward-Port-Of: odoo/odoo#276688

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

Issue:
When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details.

Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country.

Steps to reproduce:
- Configure a Swiss company with a QR IBAN bank account
- Set the sales journal Communication Standard to Switzerland
- Create and confirm an invoice for a non swiss customer (US, BE)
- Observe in the pdf and in the other info tab -> no payment reference or payment details

Cause:
`get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated.

Solution:
Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency.

opw-6222417

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

Forward-Port-Of: odoo/odoo#272617
Forward-Port-Of: odoo/odoo#266861

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

- Opening Studio on a form containing a Many2many field using the many2many_tags_email widget crashes with an OWL prop validation error.

- **Steps to reproduce:**

1. Open any form view (e.g., Contacts) and enter `Studio`.
2. Create a new `Many2many` custom field on a model such as `res.partner`.
3. Set the field's widget to `many2many_tags_email` and save the customization.
4. Exit Studio and populate the field with one or more related records.
5. Open Studio again on the same form view.

This results in the following error:
```.js
Error: Invalid props for component 'RecipientTag': 'onDelete' is undefined
(should be a value)

```
### Current behavior before PR:

- When opening Studio on a form containing a `Many2many` field with the `many2many_tags_email` widget, the field is rendered with `onDelete` set to undefined by `Many2ManyTagsField`. Starting from `saas-19.1`, the `many2many_tags_email` widget uses the new [RecipientTag] component, which requires onDelete to be defined. As a result, Owl's prop validation fails when RecipientTag receives `onDelete = undefined`, causing Studio to crash with an I nvalid props for component 'RecipientTag' error.

### Desired behavior after PR is merged:

- RecipientTag should allow onDelete to be optional so that it can also be used when the parent field does not provide a delete callback. This prevents the Owl prop validation error when opening Studio, while keeping the existing delete functionality unchanged for editable fields where onDelete is available.

opw:6395209

[RecipientTag]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/static/src/core/web/recipient_tag.js

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

Forward-Port-Of: odoo/odoo#277934

During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function _get_manual_value():

https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L359-L361

This method's goal is to search product.value records related to the current move.

https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L431-L447

This search is performed once per move selected previously even if they are not related to any product.value.

We propose to cache the id of every move that is linked to at least one product.value to ensure the search method is only performed for those and potentially reduce the number of calls to the search method.

Benchmark
------------

Reducing the execution time with this modification supposes that the majority of stock.move records are not linked to any product.value, which is usually the case.
The following benchmark shows the execution times of _run_average_batch() depending on that.

| No stock.move | No of moves linked to product.value | Before PR | After PR |
|---------------|-------------------------------------|-----------|----------|
|           100 |                                  10 |    1.03 s |   421 ms |
|          1000 |                                 100 |    7.13 s |   1.14 s |
|         10000 |                                 100 |   57.21 s |   1.55 s |
|         10000 |                                1000 |   60.42 s |   8.98 s |

When every stock.move is linked to a product.value, the modification will introduce more operations than needed and slow down the execution. The following benchmark illustrates that.

| No stock.move | Before PR | After PR |
|---------------|-----------|----------|
|           100 |    1.14 s |   1.15 s |
|          1000 |    8.21 s |   8.37 s |
|         10000 |   80.64 s |  81.51 s |

opw-6050007

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

Forward-Port-Of: odoo/odoo#257619

**Step to Reproduce:**

1. Create a database in 18.0 with `l10n_mt` installed.
2. Select the Malta chart template (COA).
3. Upgrade the database to 19.0.
4. Verify the tax grids.

**Issue:**

Tax grids remain unchanged after the upgrade and do not reflect the modifications introduced in [1].

The tax definitions are loaded from CSV data and don't happen during upgrade or module update it did through try_loading". Since the account tags already exist in upgraded databases, the changes are not applied during module loading and the updated grid assignments are not assigned to taxes.

**Fix:**
Apply the grid update directly through SQL during the upgrade or module update. The change is limited to tax grid assignments and does not require a full tax reload using ``try_loading`` or ``load_data``.

**Before fix:**
<img width="1458" height="724" alt="image" src="https://github.com/user-attachments/assets/eaac5e3f-d551-4ec0-b282-bb39a50438f9" />

**After fix:**
<img width="1240" height="583" alt="image" src="https://github.com/user-attachments/assets/74409c53-dce0-45b2-a6b5-e60f5c2d826d" />



Note: why this fix is needed because existing upgrade script do update move line grid but still tax have the old grid which is weird and will cause issue when journal entry will create. 

[1]:  https://github.com/odoo/odoo/pull/254894/changes/8921186850e31c53072d49a5dc760192f3edb902

opw-6325845
upg-4391393

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

Forward-Port-Of: odoo/odoo#272038

On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po.

Steps to reproduce:
-------------------
* Create a PO and confirm it
* Open the receipt, validate and duplicate it
* Go on the duplicated receipt and change its Operation Type
* Confirm the duplicated receipt. 
-> the Received Qty on the Po counted the duplicated and modified transfer.

Observation:
-------------
When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892
https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15
the ```purchase_line_id``` will keep the link with the pol.
The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304

Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76
opw-6088239

Forward-Port-Of: odoo/odoo#276250
Forward-Port-Of: odoo/odoo#259570

## Current behavior:
Clicking on the Late activity for Lot/Serial in the notification systray doesn't apply the Late activities filter.

## Expected behavior:
Clicking on the Late activity for Lot/Serial in the notification systray should apply the Late activities filter.

## Steps to reproduce:
1. Install Inventory (stock) module, make sure to enable Lots & Serial Numbers in Inventory > Traceability
2. Create some new Lots / Serial numbers
3. Add some Activities with Due Date before today
4. Observe that the Clock icon on systray will count up, showing the number of activities that are late, for today and for future
5. Click on the Late activities (e.g. 2 Late) should only show the 2 late activities. Instead, no filter is applied, thus showing all the Lots / Serial numbers in the inventory

## Cause of the issue:
Missing filters for Late, Today and Future activities in the stock_lot_views.xml

## Fix:
Added 3 filters for Late, Today and Future activities

opw-6332560

Forward-Port-Of: odoo/odoo#272735

**Step to Reproduce:**

1. Create a database in 18.0 with `l10n_mt` installed.
2. Select the Malta chart template (COA).
3. Upgrade the database to 19.0.
4. Verify the tax grids.

**Issue:**

Tax grids remain unchanged after the upgrade and do not reflect the modifications introduced in [1].

The tax definitions are loaded from CSV data and don't happen during upgrade or module update it did through try_loading". Since the account tags already exist in upgraded databases, the changes are not applied during module loading and the updated grid assignments are not assigned to taxes.

**Fix:**
Apply the grid update directly through SQL during the upgrade or module update. The change is limited to tax grid assignments and does not require a full tax reload using ``try_loading`` or ``load_data``.

**Before fix:**
<img width="1458" height="724" alt="image" src="https://github.com/user-attachments/assets/eaac5e3f-d551-4ec0-b282-bb39a50438f9" />

**After fix:**
<img width="1240" height="583" alt="image" src="https://github.com/user-attachments/assets/74409c53-dce0-45b2-a6b5-e60f5c2d826d" />



Note: why this fix is needed because existing upgrade script do update move line grid but still tax have the old grid which is weird and will cause issue when journal entry will create. 

[1]:  https://github.com/odoo/odoo/pull/254894/changes/8921186850e31c53072d49a5dc760192f3edb902

opw-6325845
upg-4391393

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

Forward-Port-Of: odoo/odoo#272038

On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po.

Steps to reproduce:
-------------------
* Create a PO and confirm it
* Open the receipt, validate and duplicate it
* Go on the duplicated receipt and change its Operation Type
* Confirm the duplicated receipt. 
-> the Received Qty on the Po counted the duplicated and modified transfer.

Observation:
-------------
When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892
https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15
the ```purchase_line_id``` will keep the link with the pol.
The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304

Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76
opw-6088239

Forward-Port-Of: odoo/odoo#276250
Forward-Port-Of: odoo/odoo#259570

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941

Forward-Port-Of: odoo/odoo#274677

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Forward-Port-Of: odoo/odoo#277640
Forward-Port-Of: odoo/odoo#272161

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

Forward-Port-Of: odoo/odoo#277227
Forward-Port-Of: odoo/odoo#276688

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

# Setup
You'll need two users :
	- Internal User A that can create projects
	- User B with a granted portal access

Optionnal third user to compare the flows :
	- Internal User B that can create tasks in a porject

# How to reproduce
- With User A, create a new project with atleast a single stage
- Go to the project settings
- Make sure that Visibility is set to : "All internal users and invited portal users"
- Click on Share Project
- Add User B as a new Collaborator with the Edit acess mode
- Confirm by clicking on Share Project
- Still in the project settings, click on the blue user icon in the top right to edit the Followers :
	- Make sure you are following the project
	- Click on the edit button and make sure Task Created is checked

 Optionnal for easiness of testing :
 - Go to the User A settings and in Preferences > Notifications : In Odoo

- Log in with User B (in a new incognito tab on the side is best)
- Go to Projects > The project that has been shared
- Create a new task

# The problem
No notification is sent to User A. If the same flow is done using User C, then a notification is correctly sent.

# Cause
The fields that determine to which users the notifications are
sent to is `message_follower_ids`. In our case, the value
of that field does not contain User A, so no notifcation is sent
to them.

The method responsible for assigning values to that field is
`_message_auto_subscribe()` which adds follower using
subtypes parent relationship. The parent subtype of tasks are
projects. So, essentially, we look for followers of the parent project,
and see if we can add them to our task.

Before proceeding with the assignation, we check that the parent
subtype's field was actually edited :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L4778-L4781

So we look that `updated_values` contains "project_id".
`updated_values` is created by the the `mail_thread`
create method by joining the values in `vals_list` and
the context default variables. In our case, this should be enough
since `default_project_id` is provided when creating
a task :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L340-L344

But, a bit before this, the task create method edits the context to replace 'default_project_id' by 'default_create_in_project_id' :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/project/models/project_task.py#L1102-L1109

So we do not detect that `project_id` has been changed and don't actually add the followers.

# Proposed solution
We remove the custom 'default_create_in_project_id` context

opw-6026932

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

Forward-Port-Of: odoo/odoo#258905

Description of the issue/feature this PR addresses:

report_stock_quantity uses m.quantity instead of the done quantity converted to the product's base UoM when computing the forecast for done inter-warehouse moves. This causes incorrect forecast values when a done stock move uses a UoM with a factor greater than 1.

Current behavior before PR:

When a done inter-warehouse move uses a UoM with factor > 1 (e.g. a box of 25 units), the forecast only subtracts the raw done quantity (e.g. 2 boxes) instead of the converted quantity in the product's base UoM (e.g. 50 units). This causes the forecast chart to show incorrect negative values before the move date.

Steps to reporduce:

- Create a storable product with base UoM = Units
- Create a UoM "Box of 25" with factor = 25 in the Units category, and add it to the product's allowed UoMs
- Create a second warehouse
- Do an inventory adjustment of 800 units into warehouse 1
- Create an inter-warehouse transfer of 2 "Box of 25" (= 50 units) from warehouse 1 to warehouse 2 and validate it
- Open the forecast chart for the product filtered to warehouse 1

Desired behavior after PR is merged:

The forecast report for done inter-warehouse moves correctly converts the done quantity to the product's base UoM using the move's UoM factor, so the forecast chart shows accurate values regardless of the UoM used on the move.


opw-6266745


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

Forward-Port-Of: odoo/odoo#271766

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

Forward-Port-Of: odoo/odoo#269496

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941

Forward-Port-Of: odoo/odoo#274677

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

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

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

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

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

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

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

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

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

Forward-Port-Of: odoo/odoo#278139
Forward-Port-Of: odoo/odoo#273823

Description of the issue/feature this PR addresses:
A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one.

Current behavior before PR:
- Enable Multi-Companies in the settings.
- Create a second company (Company B).
- Open Accounting > Configuration > Cash Roundings.
- Create a cash rounding with strategy "Add a rounding line" and precision 1.00.
- Make Company A the active company in the company switcher.
- Set the cash rounding's profit and loss accounts to Company A accounts.
- Switch the active company to Company B.
- Set the cash rounding's profit and loss accounts to Company B accounts.
- Make Company A the active company again, keeping both companies active.
- Create a customer invoice for Company B.
- Add one invoice line whose total is not a multiple of the rounding precision.
- Set the invoice's cash rounding to the one above.
> Adding the rounding line raises a cross-company UserError: the company-dependent account is resolved against Company A while the invoice belongs to Company B.

Desired behavior after PR is merged:
The rounding line resolves the company-dependent profit/loss account against the invoice's own company, so the rounding line always uses that company's account and no cross-company error is raised. Covered by the added test TestAccountMoveCashRoundingMultiCompany.




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

Steps to reproduce:
-------------------
1. Install sale_timesheet.
2. Create a service product with:
   - Invoicing Policy: Prepaid/Fixed Price
   - Create on Order: Project & Task
3. Create a sales order with this product.
4. Open the generated project > dashboard and verify that "To Invoice" shows $1.
5. Create a project update and observe that "To Invoice" also shows $1.
6. Return to the sales order, create and post the invoice.
7. Open the project dashboard again and verify that "To Invoice" is now $0.
8. Create another project update.

Issue:
------
The project update margin still displays $1 under "To Invoice" even though the sales order has already been fully invoiced.

Cause:
------
The project update template displays the aggregated profitability totals (`profitability['total']['revenues']` and `profitability['total']['costs']`) instead of the dedicated `to_bill_to_invoice` and `billed_invoiced` values, causing stale "to invoice" amounts to persist after invoicing.

Solution:
---------
Use the `to_bill_to_invoice` and `billed_invoiced` values when rendering the project update profitability report.

opw-6323869



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

Steps to reproduce:
- set the "Product Price" decimal precision to 3
- create two products with a price of 42.609 and a 15% excluded tax
- create an automatic promotion granting a 20.4% discount on these specific products
- in the PoS, sell both products: the reward line shows -20.00 and the order total 78.00
- pay 100.00 in cash and validate

The synced order total becomes 78.01 while the customer paid 78.00.

The discount reward line is created in the frontend with an unrounded price unit: -(85.22 * 20.4%) = -17.384879999999995. The frontend computes taxes on the price unit rounded to the "Product Price" precision (see `get_unit_price()`): -17.385 -> -17.39 - 2.61 = -20.00 tax included, hence the 78.00 total displayed and paid.

However, the raw value is what is sent to the server and stored as-is (`pos.order.line.price_unit` is declared with `digits=0`). Whenever the backend recomputes the amounts from the lines - e.g. when a cash change makes `_process_payment_lines()` call `_compute_prices()` - the taxes are computed on the raw value: -17.38 - 2.61 = -19.99, and the order total drifts to 78.01.

Round the reward line price unit to the "Product Price" precision when creating it, as `_getRewardLineValuesProduct()` already does, so the stored value is the one the frontend computed its totals with.

opw-6322031

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

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

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

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

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

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

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

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

opw-6388781

Forward-Port-Of: odoo/odoo#277114

### [FIX] website: fix GMaps deprecation console warning for s_google_map

Google deprecated the synchronous script loader for initializing the
Maps JS API. This caused browser console warnings.

The fix adopts Google's official `importLibrary()` bootstrap pattern,
which loads map libraries (places, maps, marker) lazily on demand rather
than all at once.The version is updated to `v=weekly`, which Google
recommends as it receives updates weekly versus quarterly for version
numbers(`v=number`).

Steps to reproduce:
1. Add the `s_google_map` snippet(not the`s_map`, enable debug mode)
2. Open the browser console and observe the deprecation warning


### [IMP] website: warn user to reload after GMaps config changes

Switching from the legacy Google Maps APIs to the new APIs requires
enabling additional services in Google Cloud. Existing maps using the
legacy API continue to work, but when an admin edits a map without a
proper configuration, the `GoogleMapAPIKeyDialog` dialog opens.

Google Maps configuration changes (API key update or enabling services)
do not take effect during the current editor session because the Maps
JavaScript API is loaded at page initialization.

Before this commit, such misconfigurations (disabled services or invalid
API keys) only triggered a dialog showing a generic Google Maps error.

After this commit, a notification informs the user that the page must be
reloaded for configuration changes to take effect.

The setup instructions are also updated to reference the
"Places API (NEW)" service.


### [IMP] website: replace deprecated Places API calls in GPS picker

The GPS picker relied on `PlacesService.nearbySearch` and `getDetails`,
which are part of the deprecated Places API. The new places API replaces
these with `Place.searchNearby` and `fetchFields`.

Error handling is consolidated into a single try/catch since the new
Places API throws on failure rather than returning a status code,
removing the need for `PlacesServiceStatus` checks.


### [IMP] website, *: replace deprecated Google Autocomplete
*: website_form_project

google.maps.places.Autocomplete is deprecated in the new Places API.
The replacement (`AutocompleteSuggestion.fetchAutocompleteSuggestions`)
does not fire DOM events, making it incompatible with the old
event-listener pattern used in GPSPicker.

A new Owl component (`PlacesAutoComplete`) is introduced to wrap the new
API, built on top of the existing `AutoCompleteWithPages`.


References:
https://developers.google.com/maps/documentation/javascript/load-maps-js-api
https://developers.google.com/maps/documentation/javascript/advanced-markers/migration
https://developers.google.com/maps/documentation/javascript/legacy/places-migration-overview

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

## Description

When validating an invoiced order in PoS Restaurant, an intermittent `undefined: Backend Invoice` error can occur if the user validates the order before the draft synchronization has completed.

This issue is difficult to reproduce consistently because it depends on network latency and the timing of user interactions.

### Steps to Reproduce

1. Open a PoS Restaurant session.
2. Add products to an order.
3. Click **Order** to start synchronizing the draft order.
4. Immediately click **Payment**.
5. Enable **Invoice** (select a customer if needed).
6. Click **Validate** before the draft synchronization finishes.
7. Under slow or unstable network conditions, the payment validation may fail with:

```
undefined: Backend Invoice
```

## Root Cause

During payment validation, `_finalizeValidation()` calls `push_single_order()` to synchronize the current order before creating the invoice.

In PoS Restaurant, `sendDraftToServer()` synchronizes draft orders asynchronously without acquiring `pushOrderMutex`, while `push_single_order()` performs synchronization while holding the mutex. Although both methods share the `syncingOrders` set, they are not synchronized through the same locking mechanism, allowing them to race.

The race happens as follows:

1. `sendDraftToServer()` starts synchronizing the draft order and adds its ID to `syncingOrders`.
2. Before it finishes, the user clicks **Validate**.
3. `_finalizeValidation()` calls `push_single_order()`, which invokes `_save_to_server()`.
4. Since the order is already in `syncingOrders`, `_save_to_server()` skips it and returns an empty array (`[]`).
5. The existing code only checks `!syncOrderResult`. Since an empty array is truthy in JavaScript, execution continues.
6. `_finalizeValidation()` then accesses `syncOrderResult[0]?.account_move`, where `syncOrderResult[0]` is `undefined`, resulting in the `undefined: Backend Invoice` error.

## Fix

Check that the synchronization result is both defined **and non-empty** before accessing its first element.

### Before

```javascript
if (!syncOrderResult) {
    return;
}
```

### After

```javascript
if (!syncOrderResult || !syncOrderResult.length) {
    return;
}
```

If `push_single_order()` returns an empty array, `_finalizeValidation()` exits early instead of attempting to access `syncOrderResult[0]`, preventing the exception.

This patch does **not** remove the underlying race condition; it simply handles the empty synchronization result safely.

## Notes

* This issue only affects **17.0**, where synchronization relies on `createFromUi()`.
* In **18.0**, the synchronization flow was redesigned around `syncFromUi()` and local model updates, so this specific race condition no longer occurs.

## Reproduction Videos

The issue is timing-dependent and requires slow network conditions together with rapid user interactions. After multiple attempts, it was successfully reproduced several times on Runbot.

1. [Reproduction Attempt 1](https://drive.google.com/file/d/1-KmaTiCErwv_OsWxYdmCvRUSI9oY3FOF/view?usp=sharing)
2. [Reproduction Attempt 2](https://drive.google.com/file/d/1MSG57nhZXfrAv1wuEkRbsmLstW5Hk9jg/view?usp=sharing)
3. [Reproduction Attempt 3](https://drive.google.com/file/d/1fXdyfNKUgJLTrrDZTi_FXuCmupBL3x-f/view?usp=sharing)

opw-6367134