Before this commit, "Copy to Clipboard" was sometimes not visible in the message action list when message had some text content.

This happens because message actions can condition overridden by some other modules, and the way overrides of action condition work is to have boolean value taking precedence over the local condition of action.

This architecture is meant to provide exhaustive list of actions to allow, which is quite useful to control what livechat visitors can have.

However this architecture requires overrides to properly return `undefined` when the local condition should apply, which was not the case for an override by `ai` module. So when `ai` module is installed, the "copy to clipboard" feature as not available.

This commit fixes the issue by adapting the condition in `ai` module to return `undefined` on non-AI conversations, and add test coverage for both `@mail` discuss suite and all overrides of discuss in `@test_discuss_full_enterprise`.

opw-5240768

https://github.com/odoo/enterprise/pull/99794

Before this commit, "Copy to Clipboard" was sometimes not visible in the message action list when message had some text content.

This happens because message actions can condition overridden by some other modules, and the way overrides of action condition work is to have boolean value taking precedence over the local condition of action.

This architecture is meant to provide exhaustive list of actions to allow, which is quite useful to control what livechat visitors can have.

However this architecture requires overrides to properly return `undefined` when the local condition should apply, which was not the case for an override by `ai` module. So when `ai` module is installed, the "copy to clipboard" feature as not available.

This commit fixes the issue by adapting the condition in `ai` module to return `undefined` on non-AI conversations, and add test coverage for both `@mail` discuss suite and all overrides of discuss in `@test_discuss_full_enterprise`.

opw-5240768

https://github.com/odoo/odoo/pull/236295

Steps to reproduce the bug:
- Create a storable product "P1" and "P2" with vendor "azure interior"
- for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1"
- Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2
- Validate the receipt
- Create a return for both P1 and P2

Problem:
A picking is created with destination location set to the subcontracting location for both products,
instead of setting the partner location only for subcontracted products.

Solution:
Ensure only the move line for subcontracted products uses the subcontracting destination location,
while other returned products go back to the supplier location.

When the `picking_id.partner_id`` is changed, it triggers a write on the
picking, which in turn triggers a write on its moves, but only on the
ones that are not scrapped.

However, since the `scrapped`` field is a stored computed field, and as
it hasn't been accessed before, it needs to be computed. And because
its computation depends on `location_dest_id`, that field also needs
to be recomputed. as a result, the `location_dest_id`` of the moves that
we manually set may be changed unexpectedly.

Therefore, in the `_create_return`` function, we check that the
picking’s `partner_id` is different from the moves’ partner_id before
updating it, to avoid unnecessary writes and the chain of recomputations
that could alter our values.

Resetting the picking’s partner_id based on the move’s partner_id could
actually be removed in master, as it serves no real purpose,
the move.partner_id itself is already derived from the picking’s
partner_id. We just keep it in stable versions to avoid any unexpected
behavior changes.

opw-5208289

Forward-Port-Of: odoo/odoo#234850
Forward-Port-Of: odoo/odoo#234521

Versions
--------
- 18.0+

Steps
-----
1. Have a product with multiple variants;
2. go to one of its attributes;
3. in the form, change the default extra price on multiple lines;
4. click on "Update extra prices";
5. add the updated variants to a sale order.

Issue
-----
Only the line on which "Update extra prices" was clicked has been updated, even though the button disappeared on all lines after clicking it.

Cause
-----
The `_compute_default_extra_price_changed` method only compares the `default_extra_price` of the current record to its `_origin` value. Consequently, after saving the form, it will return `False`, even though only one attribute has been updated.

Solution
--------
Aside from checking whether the value changed on the form, also check whether any product template attribute value has a `price_extra` that's different from the product attribute value's `default_extra_price`.

This way, clicking on "Update extra prices" once won't make the other update buttons disappear.

opw-5240236

Forward-Port-Of: odoo/odoo#235088

**Steps to reproduce:**
- Create some activities which should not be accessible to a specific user (according to the `_search` filtering of `mail.activity`)
- Go to Activity Menu > View all activities as the given user
- Ensure that the limit (default: 80) is lower than the total number of activities which should be returned and that the new activities are in the returned elements
- On `web_search_read` some records are removed by the `_search` override
- The pagination navigation buttons are disabled as the returned number of records is lower than the limit
- This means that some activities are not accessible to the user (everything above the given limit)

**Issue:**
The issue comes from the `_search` override which checks the records available to the user. As it's done after fetching with the limit, the resulting number of records can be lower than expected and this breaks the `_format_web_search_read_results` which considers that we have all the possible records and doesn't try to fetch the total count of records.

**Fix:**
The main issue can't be directly fixed without modifying the way the access are checked in the `_search` override.

This could be mitigated by changing the search limit, making the search as superuser, or adding specific filtering but each has its own limitations.

Adding `force_search_count` should allow the user to navigate between pages anyway and see all the available activities. But the number displayed in the pagination will often be incorrect for the current and total count. (e.g. we can have 75 records but 1-80/150 is displayed out of 140 actually readable records)

opw-5046389

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

Forward-Port-Of: odoo/odoo#233585

Currently, an error occurs when the user immediately removes a catalog product after adding it.

Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)):
 - Install the `sale_management` module.
 - Go to `Sales Orders` and create a new `sale order`.
 - In the order line, click on the `Catalog` button.
 - `Add` a product and then immediately `remove` it.

`ValueError: Expected singleton: sale.order.line()`

After [this commit], when the user clicks the Remove button immediately after clicking the Add button (within 500 ms). In this case, the system proceeds with the last request due to the useDebounced delay [1], which removes the product. However, since there is no order line yet for that product [2] and the quantity is 0, the order line [3] is not created. When it attempts to retrieve the discounted price, it raises the error [4].

This commit ensures that if no order line exists, the product's price is returned according to the sale order's pricelist.

[this commit]: https://github.com/odoo/odoo/pull/233098/commits/697c559791fdf00b5602b9459bbdf21f392757d8

[1]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/product/static/src/product_catalog/kanban_record.js#L17-L19

[2]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2202

[3]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2218-L2219

[4]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1602-L1603

sentry-7019831319

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

Forward-Port-Of: odoo/odoo#235470

#### Steps to Reproduce
1- Create a fresh database on Odoo 19.0.
2 - Install both the Appointments and Website modules.
3 - Go to the website appointment page generated by the module.
4 - Click Edit in the website builder.
5 - The website editor crashes with the SelectionPlaceholderPlugin error.
#### Issue
After Odoo 19 introduced the new [SelectionPlaceholderPlugin](https://github.com/odoo/odoo/blob/19.0/addons/html_editor/static/src/main/selection_placeholder_plugin.js) in the HTML editor, the appointment progress bar view began to crash, specifically when clicking the “Edit” button of the website editor on the appointment page.

This issue did not occur in earlier versions because the plugin did not exist. And the old editor never scanned or validated raw text nodes.

The appointment progress bar template contained a `li` node using d-flex directly on the `li` element.
In Odoo 19, the HTML Editor’s selectionPlaceholder plugin inspects the DOM after every render to determine where the selection placeholder blocks must be inserted.

Because d-flex changes the internal layout of the `li`, Owl and the HTML editor produces intermediate text nodes / inline nodes inside the flex container. During placeholder evaluation, the editor scans siblings before/after each block using:

```python 
selection_blocker_predicates(blocker)
```

This logic expects HTML elements, as it calls:
```python
blocker.hasAttribute(...)
```
However, the flex layout caused the plugin to receive a non-element node (e.g. a TextNode) as blocker.

Since TextNodes do not implement .hasAttribute(), the editor raised:
 ```python
TypeError: blocker.hasAttribute is not a function
```
This error propagated into:
 ```python
OwlError: An error occurred in the Owl lifecycle
```
which broke the entire website editor.

#### Traceback
```python
UncaughtPromiseError > OwlError

Uncaught Promise > An error occurred in the Owl lifecycle (see this Error's "cause" property)

Occurred on localhost:8069 on 2025-11-11 13:57:55 GMT

OwlError: An error occurred in the Owl lifecycle (see this Error's "cause" property)
    Error: An error occurred in the Owl lifecycle (see this Error's "cause" property)
        at handleError (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:762:101)
        at App.handleError (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:1420:29)
        at ComponentNode.initiateRender (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:854:19)

Caused by: TypeError: blocker.hasAttribute is not a function
    at selection_blocker_predicates (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14305:1708)
    at http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14306:115
    at Array.map (<anonymous>)
    at checkPredicate (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14306:106)
    at isSelectionBlocker (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14306:243)
    at SelectionPlaceholderPlugin.updatePlaceholders (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14307:272)
    at http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:12434:52
    at Array.forEach (<anonymous>)
    at Editor.startPlugins (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:12434:38)
    at Editor.attachTo (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:12425:6)
```
#### Fix

To avoid creating confusing DOM structures for the editor, the template was updated to:
- Wrap the inner content to keep the same UI layout without affecting the parent `li` block semantics.

##### This insure
- The items stay a clean block-level element.
- The HTML editor correctly identifies block boundaries.
- The selection placeholder plugin no longer receives invalid nodes.

OPW - [5226904](https://www.odoo.com/odoo/project/70/tasks/5226904)

Currently an error occurs when user change the move line quantity.

Steps to Reproduce [video](https://drive.google.com/file/d/12r0DxsKZkvuVjoCsRgXlHJ23NpaqciV7/view?usp=drive_link):

 - Install the `purchase_stock` module.
 - Create a `product` with category: `Costing Method: FIFO`.
 - Create a `purchase order` and add the newly created product to it.
 - Click `Confirm Order`, then click on `Receipt` and `validate` it.
 - Click on `Moves`, open the record, set the `Quantity to zero`, and `save`.

`ZeroDivisionError: float division by zero`

This error occurs when a user confirms a purchase order, validates its picking, and changes the move line quantity to zero. It then tries to update the move line value and the product's standard price due to the FIFO costing method, but the valued quantity becomes zero from [1], which raises an error at [2].

This commit ensures that if the move line has a zero quantity, the product's standard price remains unchanged.

[1]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/stock_account/models/stock_move.py#L333-L343

[2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/stock_account/models/product.py#L218

sentry-6993648057

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

- Go to Recruitment > Applications > All Applications.
- Open an applicant form and click "Generate Offer".
- Repeat a few times so that the "Offers" smart button shows a list view.
- From the list view, click "New" to create an offer.
- Compare both flows:
  * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window.
  * With "New" button: the generated offer link has `token=False`, which leads to an invalid link.

#### Issue
In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links.

#### Fix
Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user.

#### Additional
- Mark the field `access_token` as readonly.

task-5051394

Forward-Port-Of: odoo/enterprise#93561

## Issue:
When adding landed costs to stock moves, the resulting move value was increased regardless of the quantity remaining in stock
As a result, moves with no remaining quantity could still receive additional value, incorrectly affecting products that are no longer in stock

## Cause:
The valuation is determine using the `move._get_value()` function, which uses the standard price when there is no linked PO, Bill, or Credit Note
However, it distributed the landed cost share based on the move itself, without considering whether the move’s quantity was still available in stock

## Steps to reproduce:
- Create a product (Tracking: Quantity, category: AVCO)
- Receive 2 units of the product.
- Deliver 1 unit
- Create a Landed Cost for the receipt with an additional cost of 100 $
- Open Inventory > Reporting > Move Analysis
- Add Value in Measures
- Look for the current month (add a product filter if needed)
- You should have Quantity: 2 and Value: 50$ after the fix

opw-5128570

Forward-Port-Of: odoo/odoo#232857
Forward-Port-Of: odoo/odoo#231936

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

**Steps to reproduce:**
1. Install the `Accounting` and `l10n_ph_reports` modules.
2. Create a contact with the company flag enabled.
3. Create an invoice using that contact.
4. Go to `Reporting → Summary Lists of Sales and Purchases → Sales`.

**Observed behavior:**
* The `Registered Name` column in the report is blank for companies.

**Cause:**
* The query logic was incorrectly showing the registered name only when a last name was present. This issue arose due to the change in how company/individual differentiation is handled.

**Fix:**
* Update the query logic for the Odoo report:
  - **Always display the registered name in the Odoo report**:
    - If individual: show `First Name`, `Middle Name`, `Last Name`.
    - If company: show `commercial_partner_id.name`.
  - **For the export file**:
    - If company: only show the registered name.
    - If individual: show `First Name`, `Middle Name`, `Last Name`.

The fix ensures that **Registered Name** is always displayed in the report, and the export behaves as expected for both individuals and companies.

Note: spec provided by po -> 
<img width="1662" height="431" alt="image" src="https://github.com/user-attachments/assets/a7a58a9e-b769-4815-ad0a-cef9c8e2eff7" />


opw-5143677

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

Steps to reproduce:
-------------------------
1. Install Website and AI modules.
2. Open the website editor.
3. From the Intro block, search for the AI snippet and add the snippet contains 'Need Help?'.
4. Click on the added block, then click the Save icon from the Style tab.
5. Save the snippet
6. Go to Blocks → Custom Blocks and add the saved snippet.

Observation:
-------------------------
A traceback is raised:
```
TypeError: Cannot read properties of null (reading 'remove')
    at AILivechatOptionPlugin.onSnippetDropped
```

Issue:
-------------------------
The `onSnippetDropped` method
https://github.com/odoo/enterprise/blob/bb3699cc112acb3ec545d3aa5f3d8f7263a5dac6/ai_website_livechat/static/src/website/plugins/ai_livechat_option_plugin.js#L39-L51 executes every time a snippet is dropped into the layout. When the snippet is first added, the method removes the `<div>` with class `s_ai_livechat_preview`. Upon saving, the snippet is stored without that `div`. When re-adding the saved snippet from custom tab, the method runs again but fails since the `s_ai_livechat_preview` element no longer exists, resulting in the traceback.

Solution:
-------------------------
Added the optional chaining operator to safely remove the `s_ai_livechat_preview` div only when it exists.

opw-5227072

### Steps to reproduce:

- Go to Inventory > Reporting > Stock
- Toggle studio and enable debug mode
- Click on the "On Hand" column
#### > UncaughtPromiseError > OwlError > Uncaught Promise:
> Got duplicate key in t-foreach: /list[1]/field[x]_hide_trailing_zeros

#### Note:

We enabled debug mode to raise template rendering issues but without debug mode the template of the left studio panel is simply not rendered.

### Cause of the issue:

The `qty_available` displayed in the `product.product` list view https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/stock/views/product_views.xml#L574-L575 is associated with a `stock_action_field` widget. However, since e4c51ad8a6da17339923875de7fa303544b717e1 this widget has become an hybrid entity able to support both the float and the monetary fields: https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/stock/static/src/fields/stock_action_field.js#L12-L22 The issue is due to the fact that the template of sudio component `TypeWidgetProperties` can not be rendered for our `qty_avaialble` field as it receives the `hide_trailing_zeros` boolean attribute twice in this `t-foreach`:
https://github.com/odoo/enterprise/blob/4ba22ee091938d382fb79ef386b4761e4e15479a/web_studio/static/src/client_action/view_editor/interactive_editor/properties/type_widget_properties/type_widget_properties.xml#L23-L25 
This happens because the `stock_action_field` adds it twice in its supportedOptions:
https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/stock/static/src/fields/stock_action_field.js#L55-L67 once because of the `floatField.supportedOptions`: https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/web/static/src/views/fields/float/float_field.js#L119-L124 and once because of the `monetaryField.supportedOptions`: https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/web/static/src/views/fields/monetary/monetary_field.js#L113-L118

opw-5188594

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

**Steps to reproduce:**
1. Install eCommerce.
2. Open a product > Sales Tab > Alternative Products
3. Add products with  an internal reference (default_code) and Attributes.
4. Go to website > scroll down to the alternative products section.

**Issue:**
- The "Alternative Products" snippet displays the product's internal reference 
  in the title.
- This occurs only for products with attributes and variants(attribute_line_ids)
- The behavior is inconsistent with the main product page, where only the 
  product name is shown

Cause :
- The QWeb template was accessing the product name through values['data']['_record'] (which is a product.template) 
whose display_name includes internal reference  (e.g., [E-COM06] Corner Desk Right Sit).
 This occurs for products that have attribute_line_ids.
https://github.com/odoo/odoo/blob/f0a34badefd432e9c2ab36acaf018d20d0e342fe/addons/website_sale/data/product_snippet_template_data.xml#L17-L20
    <img width="1920" height="458" alt="image" src="https://github.com/user-attachments/assets/c3088149-b6c8-4cd7-8db4-129f0282a09d" />
- However, values['data'] already contains a clean display_name 
  (e.g., Corner Desk Right Sit) i.e. as expected.

**Solution:**
- Updated the QWeb template to use the correct field from the prepared data:
             `t-out="data.get('display_name') or product.display_name"`
- This ensures that the title displays a clean product name consistent with the
   main product page, without the internal reference

**opw-5122632**

Steps to reproduce:
---------------------------
1. Install the Recruitment app with demo data.
2. In Settings, add an Email Alias for the company.
3. Open the Recruitment app.
4. Click the Configure button on the job position kanban card.
5. In the Job Position form view, add an email alias.
6. Use the breadcrumbs to navigate back to the job positions.

Observation:
---------------------------
The email field for the job position is misaligned in the kanban card.

Issue:
---------------------------
The `div` containing the email is missing a `justify-content-*` class https://github.com/odoo/odoo/blob/5ab45d45073463495e517aca9fd061415a73e893/addons/hr_recruitment/views/hr_job_views.xml#L77

Solution:
---------------------------
Add the missing `justify-content-between` class to align the email properly.


Before:
<img width="1909" height="749" alt="before" src="https://github.com/user-attachments/assets/51790c71-f30d-4402-ae24-a5ccfb30ff9a" />

After:
<img width="1914" height="697" alt="after" src="https://github.com/user-attachments/assets/711f83f6-208e-44c3-83e2-8b736c697a9d" />

opw-5246587

### Steps to reproduce:
	- Create a sale order with a SOL and an optional product
	- Preview the sale order and add the optional product to the order
	- Go back to edit mode and change the pricelist
	- Click on 'Update Prices'
	- Notice the optional product price won't change

### Cause:
When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation.

If sale_subscription is installed we will set the product's prices to 0 

https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 

so the price of the 'Optional product' SOL will change but will be equal to 0

### Fix:
An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed

opw-5058609

Forward-Port-Of: odoo/odoo#234968
Forward-Port-Of: odoo/odoo#230053

### Steps to reproduce the issue:

(Easier to reproduce client side with CRM installed)

0. Install crm
1. Create Second Company
2. Create New User with Current Company as Default Company and Second Company in Allowed Companies
3. Create CRM Team belonging to Second Company
4. Add New User to Members of CRM Team
5. Receive error:

>     [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company.

### Explanation:

`crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it.

### Fix reasoning:

Removing restriction, as we want to avoid other multi-company issues by changing the behaviour.

opw-4214192

---

@nd-dew note:
Situation recap
![image](https://github.com/user-attachments/assets/9377ec70-0a57-4a48-b071-de588cde06a6)

So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). 

However looking at the tests it seems like this is desired limitation.

Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority.

Forward-Port-Of: odoo/odoo#189441

When using the takeout preset with the self order, we're supposed to send a confirmation email to the customer. Currently, this mail does not get sent.

Steps to reproduce:
-------------------
* Open the Restaurant config, make it only use the takeout preset
  (by default) and enable self ordering + QR
* Log out
* Open the mobile menu
* Make an order
* Fill out the information for takeout (slot, name, mail) and continue
* Check the mails
> Nothing being sent

Cause:
------------
The email is supposed to be sent after entering the takeout informations and selecting the button "continue".
https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/pos_self_order/static/src/app/pages/cart_page/cart_page.js#L131-L135

The call to the db is made here:
https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/pos_self_order/static/src/app/pages/cart_page/cart_page.js#L156-L162
Which utlimately resolves in calling:
https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/point_of_sale/static/src/app/services/data_service.js#L526

This uses the call_kw route which requires the user to be connected.
https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/web/controllers/dataset.py#L28-L29

However the usecase we describe is mainly used by non connected users. If a user is not connected we will never call `action_send_self_order_receipt` which sends the email.

Why the fix:
------------
We do not want to use a public route to send the email. What we want is to send the email directly from the backend when the order is created.

In order to achieve this we need to send the email given by the customer when sending the order. To do that we need to override `serializeForORM` as the email is a computed field.

Currently we cannot send the receipt by email as we cannot render it from the backend. This is currently a limitation but does not induce a stepback compared to using a public route as the route to send the email would usually be executed before the payment of the order, in which case we didn't sent a receipt.

opw-5164546

Forward-Port-Of: odoo/odoo#232975

The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker.

This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop.

For a specific customer (opw-5025162), this was the case.

Benchmarks:

| No. stock.picking | avg no. quality checks | peak memory before | peak memory after |
| ----------------- | ---------------------- | ------------------ | ----------------- |
| 25                | 20                     | 2771 mb            | 235 mb            |

opw-5025162

Forward-Port-Of: odoo/enterprise#95568

[FIX] project_mrp_workorder_account: allow WO completion

Steps to reproduce:
- Enable Analytic Accounting.
- Assign a project A to User A.
- Create user B with Manufacturing User + Timesheet User rights.
- Create a storable product “P1” with the following BoM:
    - Component: 1 unit of C1
    - Workorder: Operation of 60 minutes
    - Project: Project A
- As user B:
- Create a mo to produce one unit of “P1”
    - confirm the MO
    - start the workorder and try to mark it as done.

Issue:
An access error is raised when creating analytic lines:
"Sorry 'user B' doesn't have read access to account.analytic.line"

Explanation:
Since the project is assigned to Mitchell Admin and not to Marc Demo,
the access rule below applies:
https://github.com/odoo/odoo/blob/19.0/addons/hr_timesheet/security/hr_timesheet_security.xml#L50-L62

Because Marc Demo belongs to the "Timesheet User" group but not to
the "Accounting" group, he lacks the required access rights,
which triggers the analytic line read restriction.

opw-5262213

**Issue**
In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`.

**Steps to reproduce**
1. Go to Inventory > Operations > Procurement > Replenishment
2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order)
3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included

**Cause**
`qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a).

In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results.

Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency.

**Solution**
Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values.

opw-5150643

Forward-Port-Of: odoo/odoo#234908