Similar to: https://github.com/odoo/odoo/pull/184830

We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.

https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/web/static/src/core/py_js/py_builtin.js#L77-L79

However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s

In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:

`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.

This commit handles:
- website/model_page.py:
-
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L13-L18


https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L47-L57

The enterprise commit (https://github.com/odoo/enterprise/pull/82564)
handles two other cases:

- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2

- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`

In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:

- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in et la the python server

- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)

- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`

- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
-- context_today()
-- relative_delta()
-- datetime

opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091

Forward-Port-Of: odoo/odoo#206708
Forward-Port-Of: odoo/odoo#204172

**Problem:**
When adding a product that has the landed cost setting activated
to a Vendor Bill, the landed cost checkbox was not checked, thus
the product was not registered with a landed cost in the Vendor
Bill. Adding the product straight from the vendor bill worked fine.

**Steps to reproduce:**
- Make a product with a landed cost.
- Make a new vendor bill and go to the catalog from the Invoice Lines tab.
- Search for your product and add it to the Vendor Bill.
- Return to the Vendor Bill and see that the landed cost is not checked.

**Cause of the issue:**
The field is_landed_costs_line is set in an onchange function,
thus when adding a product from the catalog the said function
is not triggered and the is_landed_costs_line is not applied.
https://github.com/odoo/odoo/blob/01058b94d860ab508bc2c013af5fe887e08247d9/addons/stock_landed_costs/models/account_move.py#L61-L66

**Fix:**
An override of the create function was added to add the
correct landed cost even when the onchange function is
not called. With the onchange function and the create
function, this ensures that the is_landed_costs_line
will be set correctly regardless of where it is created
from.

opw-4521391

Forward-Port-Of: odoo/odoo#201622

### Steps to reproduce:
- Go to Expenses > Expense Reports
- Make sure that no expenses are present to make the sample data display
- Try clicking on the left panel to change the filter on the status
- It doesn't work

### Cause:
The display of sample data adds the class "o_view_sample_data" to the `Layout` component containing the control panel, the search panel and the list ([see](https://github.com/odoo/odoo/blob/e1b6f55840c9d5e2c0f6705add8d82a311fb04a7/addons/web/static/src/views/list/list_controller.xml#L6)). When this class is added, the events are ignored for div with `form-check` ([see](https://github.com/odoo/odoo/blob/e1b6f55840c9d5e2c0f6705add8d82a311fb04a7/addons/web/static/src/views/view.scss#L7-L10)) As the `SearchPanel` component is inside the `Layout` component and contains form-check for the filters on Selection fields (state for example), this filter also gets deactivated.

### Solution:
Add the class `o_view_sample_data` in the Renderer and not the Controller component, this way we make sure that only the interactions with the sample data get deactivated. Doing this implies adding a prop in the Renderer to pass the value of `useSampleModel` to the renderer.

Fix done for the list and kanban view which are problematic with the Expense Reports page.

opw-4707016

Forward-Port-Of: odoo/odoo#208100
Forward-Port-Of: odoo/odoo#206060

Similar to: https://github.com/odoo/odoo/pull/184830

We've recently introduced a new operator: “is within” in the domain 
selector, which can be used to find out whether a date is within a 
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.

https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79

However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s

In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:

`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via 
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.

The community commit (https://github.com/odoo/odoo/pull/204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18

https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50

This commit 
handles two other cases: 

- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2

- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`

In all three cases, the problem is the same: the problem is not only 
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:

- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server

- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)

- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`

- For the moment, the values we use are the same as those used by 
`is_within`, i.e.:
  - context_today()
  - relative_delta()
  - datetime
  - time


opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091

community: https://github.com/odoo/odoo/pull/204172

Forward-Port-Of: odoo/enterprise#83738
Forward-Port-Of: odoo/enterprise#82564

Problem: When viewing the project update of a project that timesheets on a service product with standard valuation, the 'cost_of_goods_sold' section is displayed when it should not be.

Purpose: The COGS section should only be displayed in the project updates if COGS lines exists in relation to the project. The behavior should stay consistent with v17.0 as with this commit: #203936

Steps to reproduce the issue:
1. Install Purchase, Sales, Project,sale_project, Inventory, Timesheets
2. Create a service product with standard valuation and creates project & task on order
3. Create a sales order with the service product
4. Invoice the sales order and confirm
5. Create another invoice not linked to the sales order but contains project's analytic account
6. Load the project update or dashboard of the project and notice there's a COGS section displayed despite no related COGS invoice line

opw-4684445

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

Forward-Port-Of: odoo/odoo#208019

This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions.

### Steps to reproduce:
1. Install both `stock`, `delivery` and `mrp`
2. Create a product with a kit BOM and weight
   - Set the kit UoM to Unit and the components to Kg
   - Add a weight to the components too
3. Create SO with the kit product
4. Add shipping (UPS)
5. Delivery product
6. `The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure Kg`

The sale price computed in `stock_delivery` does not take kits into account, which leads to conversion of UoM from different products (and therefore different UoM categories).
However, `sale_mrp` already computes the right value for kits.

It worked in earlier versions, thanks to the module loading order, but `_compute_sale_price` moved from the module `delivery` to `stock_delivery`.

Here is the (simplified) module dependency graph:
```
Odoo 16.0:
sale
`-> sale_management
   `-> delivery
`-> sale_stock
   `-> sale_mrp

Odoo 17.0:
sale
`-> delivery
   `-> stock_delivery
`-> sale_stock
  `-> sale_mrp
```

Odoo sorts modules by depth in the graph, and ordered alphabetically for modules with the same depth.
So in Odoo 16.0, `delivery` was loaded before `sale_mrp`, but starting Odoo 17.0, `stock_delivery` is loaded after `sale_mrp` since they both have the same depth.

opw-4385052

Forward-Port-Of: odoo/odoo#206753
Forward-Port-Of: odoo/odoo#190750

<b>Steps to reproduce:</b>

1. Setting > Navigate to Configure Document layout > layout : DIN 5008.
2. Accounting > invoice > PDF without Payment.

Note :Ensure the address has at least 33 characters without spaces to trigger the issue.

<b>Issue:</b>
   The footer of the invoice is not displaying correctly — the company name in the
   bottom left corner is overlapping and not aligned properly.

<b>Cause:</b>
   An upstream PR modified the footer text sizing, leading to layout issues when
   fields contain long values.

<b>Solution:</b>
Removed the `text-nowrap` class from the company details in the footer section.
Improved section alignment using `colspan` and made minor adjustments to footer text sizing.
These changes prevent content overlap in the company information section of reports,
ensuring proper display regardless of content length.

<b>opw: 4731515</b>

Before changes applied:
![image](https://github.com/user-attachments/assets/cf00bda8-ffde-4ea4-b5ca-59a47df152bd)
After changes applied:
![image](https://github.com/user-attachments/assets/354bf1ba-43b1-4a1e-aa66-142c3c44b38d)

Forward-Port-Of: odoo/odoo#206774