When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them.

This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails.

This fixes a first issue where name are lost if a formatted email was entered in email_cc field. Only address was kept, now the name is correctly found and put back.

This also fixes an issue for validated email detection, in order to compare normalized emails. This was introduced at odoo/odoo#185793 and may skip valid emails entered in email_to or email_cc.

This commit backports a tool introduced at odoo/odoo@dd4709e579841672b0c2a57d5f2941f3ce770801 which aims at allowing a quick convert from a string holding emails to a list of nicely formatted emails, using normalize version of email addresses. This is the standard we use in most flows.

Task-4376876
Followup of task-3704658

Forward-Port-Of: odoo/odoo#190033
Forward-Port-Of: odoo/odoo#189409

**Current behavior:**
When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page.

**Expected behavior:**
The total cost for the POS order should match the computed BOM price shown on the product page.

**Steps to reproduce:**

1. Create two products: Product 1 and Product 2.
2. Set both products to be tracked by "quantity" or make them "storable" and assign them to a product category with "average cost" as the costing method (instead of "standard price").
3. Create a Bill of Materials for each product, ensuring they share at least one component. Make sure BoM Type is 'kit'
   - Tip: For better visibility of the error, assign a quantity of 10 or more to the shared component in Product 2's BOM, and set the shared component’s `standard_price` (cost) to 5 or higher. This will make the discrepancy in the total cost more apparent.
4. Create the shared component as a new product and assign it a price.
5. Open a new POS order, add Product 1 and Product 2, and close the order.
6. Locate the order and observe that the "total cost" is incorrect.

**Cause of the issue:**
The stock move filter does not consider that stock moves for BOM lines need to belong to the current product. As a result, if two kit products share components, the stock moves for one product are mistakenly included in the calculation for the other, leading to an incorrect total cost.

**Fix:**
When filtering out the stock moves, ensure they are correctly associated with the current product by verifying that each stock move’s BOM line belongs specifically to the current product and does not include nested BOMs.

opw-4274532

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

Forward-Port-Of: odoo/odoo#187130

**Steps to reproduce:**
- Create a new mailing
- Add a link with "Link" widget
- Enter a link with the same domain (e.g. a link to an event)
- Insert the link

**Issue:**
The link is automatically converted to a relative link. This may cause some issue in a multi-company environment where each company has a website (i.e. has its own domain url) and "web.base.url" is configured with the domain of the other company.

**Cause 1:**
The "Autoconvert to relative link" checkbox is never displayed and is always applied as it is checked by default. The display toggle is done in "_onURLInput" function of "Link" component, but it is never called by the override function in "LinkDialog".

**Cause 2:**
Even if the "Autoconvert to relative link" checkbox is displayed, the link will be stripped from its domain as soon as an URL is inputted and save in "this.state.url".
When the checkbox is unchecked, "this.state.url" stays unchanged because it is not possible to retrieve the stripped domain from "this.state.url".

**Solution 1:**
Call the super function in "_onURLInput" function of "LinkDialog".

**Solution 2:**
Retrieve the URL from the input when the domain should not be stripped and update "this.state.url" with it.

opw-4357095



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

Forward-Port-Of: odoo/odoo#189351

### Context:
In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write" behavior that commits the rating encoded in `<int:rate>`. So the record is already updated with the new value. Only then renders the feedback submit Form, where the user can change their preselected rating and leave a commentary before submitting it via a POST request.

Over the last years email providers and third party services will preemptively crawl URL in emails to verify if they are "dangerous" (e.g. Microsoft's Safe link and Defender fatures).
By doing so, the rating for the records will be set to the last clicked URL using the above HTTP route, without any input from a human user.

It will be creating a number of false positive or negative ratings that do not represent the real satisfaction of the surveyed customer.

### Proposed solution:
We are removing the implicit "one-click write" behavior of the route and favoring the Form submission expecting human input. This will increase the likelihood a given rating was the result of the customer clicking on the link and taking the time to leave a feedback, versus random inputs from URL bots.

### Future outlook:
With the ever-changing landscape of URL crawler bots, trying to develop counter measures to identify and flag bot behavior is possible, but would add immense overhead and maintenance cost of the code for an arguably minor feature, i.e. the customer can rate the ticket by just clicking the picture in the email.
Other methods to make these routes more resilient to URL crawlers might be revisited in the future, but for the short-term this seems like a sufficient solution to the unwanted behavior.

OPW-3411799
OPW-4292166

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

Forward-Port-Of: odoo/odoo#189513
Forward-Port-Of: odoo/odoo#187373

### Steps to reproduce:

- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse
- Go to Inventory > Products > Products
- In the search bar type `foo` string > Search Warehouse for `foo`
- Click on any product Kandan record
- Click on the Forecast smart button of the product
#### > Traceback

### Cause of the issue:

Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains:
https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer.

### Fix:

The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else.

### Note:

This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue:
903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805

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

Forward-Port-Of: odoo/odoo#189494
Forward-Port-Of: odoo/odoo#187413

### Steps to reproduce:

- Enable Multi-Steps Routes in the settings
- Inventory > Configuration > Warehouse Management > Locations
- Pick any location
- With studio add the one2Many field `Store to sublocation` (`location_out_id` of `stock.putaway.rule`) > Close studio
- Try to add a line on the associated list
#### > Traceback

### Cause of the issue:

Adding a line will trigger an onchange of the`stock.putaway.rule` model in order to compute the default data of the new subrecord. However, the code will crash during the `_search_count` of the `_onchange_location_in` because of an invalid domain: https://github.com/odoo/odoo/blob/29939aa5fb1455af89a37293d2f76541ff1645ef/addons/stock/models/product_strategy.py#L80-L88 THis crashed since in our case the `location_out_id` will be a new record created during the onchange to represent the 'stock.location' and from which we are looking at the form. As such, a NewId will be given and treated as an integer in the domain leading to a traceback when the db is served.

### Fix:

Onchange method should be robust with respect to the usage of New records and hence the records used here should be replace by their origin if it even exists.

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

Forward-Port-Of: odoo/odoo#189878
Forward-Port-Of: odoo/odoo#188053

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in manufacturing in 2 steps
- Create an MO for a product and add an operation (no need of component)
- Confirm the MO and go to your operation in the shopfloor
- Click on the 3 dots > Add component > add any component
#### >  Back to the MO: No transfer was created from stock to pre-prod

### Cause of the issue:

When you add component from the shopfloor, you will trigger a call of the `add_product` method to create and confirm the raw move associated to the MO:
https://github.com/odoo/enterprise/blob/2e2efe8421b2f85950e50ff102cdabf98d2d91ab/mrp_workorder/wizard/additional_product.py#L36-L37 However, if the `procure_method`` of this move is not set to mto/mtso it will not trigger other rules in order to generate the other transfers

### Note:

A priori, the issue should not be reproducible in 18.0+ as this part of the code was refactored and the issue was fixed by 235047b68e6a24a14e32b94b1d4a15a580dc5ad2

opw-4236272

Forward-Port-Of: odoo/enterprise#74919
Forward-Port-Of: odoo/enterprise#74178

### Steps to reproduce:

- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse
- Go to Inventory > Products > Products
- In the search bar type `foo` string > Search Warehouse for `foo`
- Click on any product Kandan record
- Click on the Forecast smart button of the product
#### > Traceback

### Cause of the issue:

Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains:
https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer.

### Fix:

The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else.

### Note:

This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue:
903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805

Community: https://github.com/odoo/odoo/pull/187808

opw-4290818

X-original-commit: 856409a1fb35c6c49fe4c404931587a95d99d370

Forward-Port-Of: odoo/enterprise#75088
Forward-Port-Of: odoo/enterprise#74188

### Steps to reproduce the issue:

1. Create two Companies, one in EUR, the other in USD
2. In EUR Company, create two Invoices with the following settings:
    - Total price of 1000
    - Invoice date: today and one month ago
    - You must be able to isolate them using Partner Ledger filters (not date)
3. In USD Company, add EUR Rates as follows:
    - Today: 1USD = 1EUR
    - One month ago: 1USD = 0.9EUR
4. In USD Company, open General Ledger and isolate the Invoices
5. First, set the timeframe from beginning last month to end of this month
6. The Invoice of last month is using the current rate, with an amount of 1000$
7. Second, set the timeframe to the current month only
8. The Initial Balance is using the previous rate, with an amount of 1111.11$

### Explanation:

The initial balance is the balance of the company before the start of the currently reviewed timeframe. To calculate it, we must update the options to target the time before the current timeframe. Since we retrieve the rate used for this calculation using the updated options, we use the last rate before the current timeframe instead of the rate used in the current timeframe.

### Fix reasoning:

Since every amount must be calculated using the current rate, we will retrieve it using the main options and not the updated ones.

opw-4299153

Forward-Port-Of: odoo/enterprise#75441