Versions
--------
- 17.0+

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

>[!note]
>Enterprise PR only adds a test.

Steps
-----
1. Have a confirmed subscription;
2. go to subscription management in portal;
3. set or change payment method.

Issue
-----
The following email is sent:
> A payment [...] amounting $ 0.00 for [...] has been confirmed.

Cause
-----
The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction.

It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1].

This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2].

Solution
--------
Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders.

opw-4169491

[^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003
[^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144

Forward-Port-Of: odoo/odoo#188440

Steps to reproduce:

- Navigate to Website
- Open the user dropdown menu and select "My Account".
- On the right-hand side of the page, click on "Edit information".
- Enter edit mode.
- Drag and drop a form inside the existing form.
- Save the changes.
- Re-enter edit mode.
- Click on any field within the newly added form.
- A traceback is triggered.

HTML5, as defined by the W3C, prohibits the use of nested \<form\> elements, as they are invalid and lead to undefined behavior in browsers. To address this, the website_form snippet has been updated to prevent it from being dropped inside another form.

This fix ensures compliance with HTML5 specifications and prevents invalid document structures from being created within the website builder.

Due to this commit [1], buttons were added as inline building blocks. As a result, you could insert blocks either directly before or after the button. Since this wasn't the case before, we never encountered any issues in forms, as nothing could be inserted there.

[1]: https://github.com/odoo/odoo/commit/507b80a12574c

opw-4305352

Forward-Port-Of: odoo/odoo#188028

**Description of the issue/feature this PR addresses:**
Improve job posting structured data with modifying remote job specific XML tags when the job is a remote job, in order to match the requirements from [Google Search results Job Posting structured data document](https://developers.google.com/search/docs/appearance/structured-data/job-posting)

Currently Odoo website's job detail page with remote job is not passing the rich results test from [Google search rich result test](https://search.google.com/test/rich-results), as jobLocation will be empty content when it is a remote job. In order to be eligible in appear in google's enriched search result, jobLocation should not be used in a remote job, instead jobLocationtype & applicantLocationRequirements should be applied.

**Current behavior before PR:**
Empty jobLocation content when the job is a remote job. No jobLocationType & applicantLocationsRequirement tag for remote job which not matching with google search result's requirement.

**Desired behavior after PR is merged:**
jobLocation tag will be removed if the job is a remote job. jobLocationType will be appeared and the content will be TELECOMMUTE, and applicantLocationRequirements will be company's country.

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

Forward-Port-Of: odoo/odoo#186706

Context
=======

`safe_eval` is Odoo's sandbox, this mechanism allows users and
eveloppers to write templates, server actions, and more without
worrying about the security risks associated with arbitrary code execution.

The current version of the sandbox heavily relies on Python's bytecodes
and compile-time verifications. This causes 2 major problems:

1) In every release of Python, its bytecodes are updated or modified.
   Which makes Odoo unusable until the security / framework team updates the
   whitelist of bytecode.

2) Most sandboxing issues we have faced for the last years was due to a
   lack of runtime checks (functions inputs (arguments) and outputs
   (return values)). All most every times those kind of issues were
   fixed with "dirty" hacks such as adding a list of
   "unsafe attribute" or adding a wrapper for modules that are exposing
   unsafe objects (such as the `sys` module)

Goal of the change
==================

During this rewrite we had a few goals:

1) Retain compatibility with the original version:
    * Find a way to keep the old checks (deny dunders, attribute storing
      and deleting)
    * Keep the same exposed API, limiting the amount of code that needs
      to be rewritten as much as possible

2) Add runtime checks to verify that every types passed and returns are
   safe by checking their type. The way that the sandbox does it is by
   using two set of types. One for the types we allow to instanciate
   (the ones that we have absolute trust, most of them are primitive
   types such as `str` and `int`) and the ones that we only allow as
   instance, this means that you CANNOT instanciate them inside of the
   sandbox (for example the sql cursor or the Odoo environement).

3) Eliminate the issues with the `.format` and `.format_map`.
   This is a well known issue within the Python security community, if
   you want more info : https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/


Linked with https://github.com/odoo/odoo/pull/138611

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

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

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

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