### 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#190400
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#189904
Forward-Port-Of: odoo/odoo#187413

Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would not come through.

This specifically happens when a lengthy operation is performed in the calls behind the "order" button, such as calling preparation printers.

Example steps to reproduce
1. set up a clean DB with pos_restaurant installed
2. configure an epson printer as preparation printer
3. open the POS session
4. select a table and add some products
5. click on "order" and immediately click on "back"

The order status is still in the "to be sent" state, while the printer effectively printed the order. You now have to get back to the table view and send the order changes again if you ever want to complete any payment for that order. It will then send it again to the preparation printer.

The end result is inconsistencies between the pos session and the database in terms of data.
In terms of business flows and operations, it results in multiple sends of the same order, which in turn could lead to losses e.g. due to wrong preparations/unneeded preparations.

opw-4367939
opw-4246953

Forward-Port-Of: odoo/odoo#189749

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#190531
Forward-Port-Of: odoo/odoo#189409

Steps to reproduce:
 - Install the planning module.
 - Open Gantt view in day scale.
 - Create a planning slot from 11am to 12pm for an employee whose working hours
   are 8-12 and 13-17
 - The default hours will be shown as 13 to 12

Issue:
 - When an employee works two shifts for example 8-12 and 13-17, and we are
   creating a slot from 11-12, the slot timing will show as 13-12 instead of
   8-12.

Cause:
- here is an example of how the planning slot will be calculated and what is
   miscalculation
 - When click on cell 9-10 the calculated hours
   <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table>
 

   so that slot timining will be 8 - 12

- When click on cell 11-12
  <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table>
   So that the slot timining will be 13-12 which should not be possible

Fix:
- We previously relied on the ```_adjust_to_calendar``` method to calculate the
  resource's working hours. However since the working hour intervals are
  already computed using ```_work_intervals_batch```, we are removing the method
  call to reduce code duplication. Calculate the working hours using
  ```_work_intervals_batch``` and return the appropriate work intervals based on
  the resource's working calendar.

task-3916687

Forward-Port-Of: odoo/enterprise#75594
Forward-Port-Of: odoo/enterprise#64961

### 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#75300
Forward-Port-Of: odoo/enterprise#74188