**Email layout is not translated to targeted sender's language with Sign mails**

Impacted versions:
- 16.0
- 17.0
- 18.0
 
Steps to reproduce:
 1. Create a partner with language other than the current user's language.
 2. Create a sign request and send the request to the created partner.
 3. The strings from the email layout like Odoo's `Powered By` and `Your Document` (Your Signature Request) are not translated to the partner's language, but translated with the user's language. This differs from the language in the body.
 
Current behavior:

Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies.  

Expected behavior:

After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.

Forward-Port-Of: odoo/enterprise#73784

Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence.

To reproduce this issue:

1) Install planning
2) Open any existing Open Shift planning slot
3) Enable the `repeat` and update the start and end date 
4) Give the edit value as `All shifts` and make sure the resource be empty 
5) Save the record.

Error:- 
```
IndexError: tuple index out of range
```

Here the `resource` is not required in planning slot. So, when the user tries to update an open shift 
with the `repeat` enabled and `resource_update` as `all`, it leads to a traceback from the below line.

https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/planning/models/planning.py#L866-L871

This is because when there is no `recurrence_slots` in the slot, 
we get an empty recordset for the `recurrence_slots`, 
which leads to the above traceback when trying to extract a value from the recurrency_slots.

We can resolve this issue by adding an extra check of `recurrence_slots` which makes the code more robust.

sentry-6096445646

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

FW fixes:
- updated test to match new sub test approach

OPW-3411799
OPW-4292166
Task-4353243


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

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

Enterprise: https://github.com/odoo/enterprise/pull/74188

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

Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations.

This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneous message to the IoT Box or to the Blackbox, all checkouts would become blocked, with the only alternative being to reload the handlers or restart the IoT Box. Furthermore, the subsequent actions appearing as refused may have executed successfully. Which means there would be a mismatch between the data stored in Odoo (multiple failed transactions) and the data sent to the SPF (one failed transaction, then many successful ones).

After this commit, the driver status is reset after being sent once. That way, when a new action is sent from the client to the IoT box, it's the status of the execution of this action and not the previous one that gets sent back to the client.

opw-4313538
opw-4182434
opw-4293988

Forward-Port-Of: odoo/odoo#186735