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

Steps
-----
1. Create a sales order with a deliverable product;
2. set sales team to a team you're not a member of;
3. validate the delivery;
4. create & confirm an invoice for the order;
5. via the delivery form, create & validate a return delivery;
6. create a new invoice for the order.

Issue
-----
The sales team on the initial invoice is the same one as on the order. The sales team on the second invoice is changed to a default value.

Cause
-----
The `team_id` gets recomputed on a `move_type` change. The reason the `move_type` changed after creation, is because the `_create_invoices` method first wants to have the final total of the invoice before deciding whether it should be an `out_invoice` or an `out_refund`: https://github.com/odoo/odoo/blob/d7af5c443b03c18e364a74571560b3583969c1d7/addons/sale/models/sale_order.py#L1401-L1407

Solution
--------
Knowing that the `action_switch_move_type` method could recompute the `team_id`, protect the field when calling it in `_create_invoices`.

opw-4563006

Forward-Port-Of: odoo/odoo#205167

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

Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request.
This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test.

Checking the logs:

2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow
2025-04-11 04:56:57,155 13 INFO 78181121-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /test_sale_product_configurators/tests/test_sale_product_configurator.py:TestProductConfiguratorUi.test_02_product_configurator_advanced

That indicates that we are in the case where the request don't have a cookie, despite the route being called from a chrome.

It is most likely due to the fact that the browser cookie are cleared at the end of a browser js call, before navigating to about:blank

2025-04-11 04:56:57,119 13 INFO 78181121-16-0-all odoo.addons.test_sale_product_configurators.tests.test_sale_product_configurator.TestProductConfiguratorUi: Deleting cookies and clearing local storage

It is actually easy to reproduce by adding a sleep before navigating to about:blank in browser.clear(). We can see that the websocket route is still called periodically at the end of a test. This error will occur when this request is made just between
the cookies are cleared and the page navigates to about:blank.

One possibility is to avoid to clear the cookie since the user profile is deleted after the browser is stopped, but unfortunately in this version the browser is kept between tests of the same class.

It is maybe not sufficient but navigating to a blank page before removing the cookies should reduce the possibility of having a request without cookie reaching the server. In this case a sleep after about:blank, before clearing the cookie shows that we don't have repeated call to /websocket anymore.

Another possibility is to check if the request is a websocket request and to not open a cursor in that case if we don't have a cookie identifying the test. This cannot be done for all requests since it is possible that some call are made when generating a pdf, or any call that would open a TestCursor without being inside a browser_js or url_open

Combining both solution should hopefully highly reduce this error. 

A final decision was made to also forbid any request coming after a browser_js.
- browser_js is the main source of request reaching the server asynchronously. Other ways to create a request on the server is synchronous with the test and will wait for the result.
- After a browser js, it is unlikely to make another request outside an url_open or browser_js. It was the case for some xmlrpc requests, the dirty solution was to make the test non strict during this request. Those tests could still be a small cause of randomness.

Note: The explicit deletion of the session cookie is also removed, it is not  needed since all cookies are cleared just after, and having a request that could reach the server without session cookies feels a little like a good solution to have random access error.

Forward-Port-Of: odoo/odoo#206129
Forward-Port-Of: odoo/odoo#206006

Currently an exception was generated when the user tries to save the new employee record after clicking on call icon.

Steps to reproduce:
1) Install HR module
2) Create a new employee record by giving employee name 
3) Click on the call icon of work phone
4) Now tries to save the new employee record

Error: `KeyError:  name`

This issue occurs because, while clicking the call widget, it creates the record but does not update it in the browser.

As a result, when the user tries to save manually, It again  creates the record with an empty vals_list.

So it will leads to the above traceback from the below lines

https://github.com/odoo/odoo/blob/2d64d94487d24278dc3c6615343a793e1ec94daf/addons/hr/models/hr_employee.py#L386

This fix resolves the issue by ensuring that clicking the call icon before saving retains the user input. Additionally, I have added a test to verify this behavior.

sentry-6234873849

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

Forward-Port-Of: odoo/odoo#195278

Unbuilding a returned product will break the stock valuations.

To reproduce the issue:
1. Create a FIFO product
2. Produce
3. Deliver
4. Return
5. Unbuild

Issue: Looking at the remaining qties of the SVL, we see that the
layer of the unbuild didn't consume the quantity of the return. This
may lead to more important issues in the stock valuation.

When processing the unbuild, we `_run_fifo` to consume the existing
SVLs. To do so, we first try to find the candidates. Here is the
problem: since [1], in case of an unbuild, we force to use the SVL
of the MO only. This will not work with the above use case: the SVL
of the MO has been consumed by the delivery. Therefore, we don't
find any candidate. This is the reason why we have some
inconsistencies on the layers.

Instead of getting the SVL of the MO only, we should simply give it
the priority and be able to find some other candidates.

[1] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c

OPW-4683083

Forward-Port-Of: odoo/odoo#206450

**Problem**: 
When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab).
If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange rate between the currencies. 

**Steps to reproduce**:
- in settings, activate another currency (ex:kr)
- create a new product
- set the product type as "storable product"
- set a cost in the general information tab and a currency (ex:1000kr)
- in the inventory tab set the route as "Buy"
- in the pruchase tab add a vendor line, with a vendor name, a quantity (ex:10) and a price in another currency (ex:8$)
- click on the replenish button and set a quantity below the minimum quantity of the vendor line you just created

**Current behavior**:
A RFQ is created, with a price equal to the cost set in general information and the currency of the vendor in the purchase tab (here:1000$).

**Expected behavior**:
When the conditions of the vendor's pricelist aren't met the price should be 0 and the currency should be the one of the vendor

**Fix**:
I reversed the changes made in this commit
https://github.com/odoo/odoo/pull/158650/commits/caf4974b770b3295faebdaab5014a879760ccd67 and adapted the test
Now, if the seller variable is empty (which happens when no pricelist is matched), the price is set to zero
https://github.com/odoo/odoo/blob/953eb7cc241e290e3e5d1ef19048213a206a1947/addons/purchase/models/purchase_order_line.py#L599

opw-4547212

Forward-Port-Of: odoo/odoo#202011

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


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

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

Forward-Port-Of: odoo/enterprise#82564