To reproduce:
 - Create an employee record for the connected admin user
 - Switch the user's company to another one (or the employee's company)
 - Upgrade to 17.0

A user who has the correct rights can change his company anytime to see employees from other companies So it doesn't make sense to have access right error during an upgrade. In this line: https://github.com/odoo/odoo/blob/140e58c5a68db674fc1d240147e4d669b29f2cad/addons/hr_expense/models/hr_expense_sheet.py#L385 The call to parent_id.user_id fail upgrades to 17.0 if the parent and the user have different companies.

Since Administrator-level users are not restricted, we put the check on that at the top to avoid errors during upgrades to 17.0. Note: in 17.1, it was made possible to have a manager from another company: https://github.com/odoo/odoo/pull/112768/commits/b841a24fc11cb83ca8e95fce7a83648d87cb90e3

Description of the issue/feature this PR addresses:

Current behavior before PR:

During upgrade, the Administrator doesn't have access rights to employees if he's not in the same company.

Desired behavior after PR is merged:

Since the admin can change companies to access other employees, it should not be blocking during the upgrade.


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

Forward-Port-Of: odoo/odoo#150660

This traceback arises when the user tries to `create a draft invoice`

Steps to produce

1. Install `sale_timesheet and l10n_in_sale`
2. Open `Sales/Orders/Quotations`
3. Create a `new record/save it/conform/create invoice`
4. Give the positive value to the down payment then click on `Create draft`

Error:

``` TypeError: SaleAdvancePaymentInv._prepare_invoice_values() takes 3 positional arguments but 4 were given
  File "odoo/http.py", line 2206, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1777, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1798, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1775, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1783, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2008, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 30, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/sale/wizard/sale_make_invoice_advance.py", line 136, in create_invoices
    invoices = self._create_invoices(self.sale_order_ids)
  File "addons/sale_timesheet/wizard/sale_make_invoice_advance.py", line 51, in _create_invoices
    return super()._create_invoices(sale_orders)
  File "addons/sale/wizard/sale_make_invoice_advance.py", line 171, in _create_invoices
    self._prepare_invoice_values(order, down_payment_lines, accounts)
```


When the user tries to Create a `draft invoice` traceback will arise because the method `SaleAdvancePaymentInv._prepare_invoice_values()` is being called with four arguments instead of the expected three.

Which leads to a traceback here
https://github.com/odoo/odoo/blob/f302a5a52845c739bff3bbc3c65f8117eadc0789/addons/l10n_in_sale/wizard/sale_make_invoice_advance.py#L10-L16

After applying this commit we will resolve the issue by adding the argument `Sale AdvancePaymentInv._prepare_invoice_values()`  the issue will be resolved

sentry-4928083299

Forward-Port-Of: odoo/odoo#152183

Before this commit:
The website selected in the website selector of the search view in the website.page list/kanban view was always set to the first one found in the DB and was never:
1. the one you visited in the website preview
2. or the one matching the URL of your backend.

But 1. was working fine before commit [1] from the frameworkjs which introduced a way to "reset" the screen between apps/menu switch.

Despite 1. working before commit [1], it was not ideally coded and worked "by chance", see below for a few facts and explication.

------------------

Fact 1:
When you have multiple websites and you are on a website, the website served is result of 2 possibilities:
1. All websites have a specific domain, then you can only see a given website on its own domain. Attempting to select another website in the website switcher will redirect you to that other website domain.
2. You have one or more websites without any domain, then you can see those ones from any domain by using the website switcher. It will force the website in session, and despite being on a domain which should serve a given website (the one which has its domain set that domain if there is one), it will serve you the one you selected in the website switcher.

Fact 2:
- It is the `website_preview` which is setting the currentWebsite property of the `website_service`.
- But the `website_service` can be used on its own, without any `website_preview` being involved in the process.
- When the website preview is unmounted, the currentWebsite from the website service is reset to null.
- The website page list component is reading the currentWebsite from the website service.
- When switching from the website preview to another menu like the website pages list, the page list component (PageControllerMixin) is actually initialized/created before the website preview is unmounted. In the end, the follow happen:
  1. Go to website preview -> it sets the website service current website
  2. Go to website page list
  3. The website page list component reads the current website from the website service which is set
  4. The website preview is unmounted, emptying the current website from the website service
  5. The website page list is shown to the user
  6. Any call from the page list component to the current website will now be "wrong" / not return the same as during its `onWillStart`, as website preview was unmounted just after that, emptying the website set in the website service.

Fact 3:
Commit [1] changed the order listed above, now 4 occurs before 3, so when the page list component reads the website from the website service, the unmount of the website preview already kicked in, emptying that website service website.

-----------------

This commit is simply finding the current website_id by asking it to the server.
It will fix point 1. listed at the very beginning of the commit message, but will also make point 2. work.

----------------

Steps to reproduce 1:
- Without any domain set, go to your DB in the website preview of your website in the backend
- Switch to the website 2 in the navbar website switcher
- You are now viewing website 2 in the website preview
- Click on "Pages" in the "Site" menu to go to the page list view
- The website selected in the search view is the first one, not the website 2. Also, the page shown are from the website 1, not the website 2.
- This was working before commit [1] and this commit is fixing that.

But this commit is also fixing/improving flows which never worked:
- Before commit [1] (or in Odoo 16 to be simpler), do the same 4 first steps as above.
- You will see that the listed pages are the ones from website 2 and that the selected website is the second one, correct.
- Now just reload the page, it will show website 1, despite the website 2 being forced (if you did reload the page on the preview, it would still show website 2).
- This is because the website_preview was never involved after the reload since you reached the list view / website service without going through the website preview.
- The same can be seen if you go to the Pages list view directly through CTRL+K, in which case you won't go through the preview.

[1]: https://github.com/odoo/odoo/commit/9f6ed9f6d1ef7ec1870980498480cae0ffc729d8

Related to task-3676124
opw-3658648

Forward-Port-Of: odoo/odoo#151709
Forward-Port-Of: odoo/odoo#149070

Since https://github.com/odoo/odoo/issues/1432

To reproduce the problem, you need to ensure that a read_group returns several groups,
with the first element being a group with no value if you choose to group on a many2many (see test).

Here's an example to reproduce in website_sale:

- Install `website_sale` without demo-data
- Go to `eCommerce/Products`
- Create a new product
- Go to `Sales` tab in the product form view
	- Set a new `eCommerce shop/Categories` like `Sales`
	- Save
- Return to `eCommerce/Products`
- Remove default filters
- Group by `Website Product Categories`
- There are two group: `None` and Sales`
- Click on None
- Traceback

In this case, the orderby is website_sequence:sum ASC,
and will therefore return as first group None containing `Delivery Product`
and as second group `Sales` containing the newly created product.

What happens is that `read_group` will build `rows_dict` thanks to `_read_group`.

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2724

this `rows_dict` will be ordered according to `orderby`and then passed as an argument to the `_read_group_format_result` function

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2759

For each row, this function will convert `row[group]` (group in this case is the many2many field)
into a tuple containing (id, displayname) in case the value (`row[group]`)
is found which will be used to build the domain `[(field_name, =, value)]`.

So, for example, replacing
```py
rows_dict = [
  groupbyField': odoo.model(1),
  groupbyField': odoo.model(4),
]

```
with
```py
rows_dict = [
  groupbyField': (1, 'First record'),
  groupbyField': (4, 'Fourth record'),
]
```

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2460-L2462

If the value is False, we'll use the 'not in' operator instead.
To do this, we need to retrieve the ids of all the other groups to
include in this one all the records that aren't in any group,
either by retrieving the id if it's a model,
or by retrieving the first element of the tuple if it's already been modified,
or by directly retrieving the value of the field if it's not a many2x.

Except that if the first element is directly a group without a value,
it won't be able to retrieve the values of the other groups,
because the condition for checking that it's a `BaseModel` instance contained a typo

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2465-L2467

Forward-Port-Of: odoo/odoo#151497

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.

Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py

if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):

In SaaS 16.4, this line returns the following SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";

Here, we check if the Active state is True to block the message if necessary.

In 17, this same line returns this SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";

I correct it in a PR https://github.com/odoo/enterprise/pull/55498

But if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c

with the fix of this PR, the discussion on Whatsapp is now possible and we keep the fix of the previous commit.

opw-3704136

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

Forward-Port-Of: odoo/odoo#152273

In form views, when the user closes the tab while having unsaved changes, and if those changes are valid, we want to save them automatically before leaving.

Before this commit, there could be situations where the changes weren't actually saved. For instance, if they involved an heavy payload for the write rpc, or if the network connection was poor, it might happen that the xhr is killed. Or at least, browsers do not offer any guarantee to wait for those xhr to reach the server.

Instead of a classical xhr, we thus use navigator.sendBeacon which ensures that the data will be sent reliably [1]. There's a drawback though, as its payload is limited. When the payload is too heavy, sendBeacon simply returns false and does nothing. In this case, we prevent the page from unloading and display a notification suggesting the user to manually save his changes before leaving.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon

Task 3537838

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#151834
Forward-Port-Of: odoo/odoo#149944

Commit [1] introduced a way to "hide" an ir.ui.view through a new visibility field.
That field has multiple possible values to restrict the access. One of those is "Restricted Groups", but when selected it's really hard to figure what to do next because nothing happens on screen: there is no "groups" field where to add the groups.

Those groups should actually be added a bit below, in the groups_id field which is "hidden" inside the "Access Rights" second tab. This is because the groups_id field already existed (in base module) before introducing the website visibility feature which just relied on that field when set to "Restricted Groups".

Note that another possible value for visibility is "Password", and in this case a password field appear below the visibility field as one would expect.

[1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900c

![image](https://github.com/odoo/odoo/assets/30048408/7cad0a47-cbe3-464c-8e86-3c4f30f8c848)

Forward-Port-Of: odoo/odoo#152392
Forward-Port-Of: odoo/odoo#151602

**Steps to reproduce the bug:**
Run the following command: `-i purchase_stock,l10n_fr -d cro_test --test-enable --test-tags purchase_stock --stop-after-init`

**Problem:**
An error is triggered:

“odoo.exceptions.UserError: Cannot find a stock input account for the
 product Analytic Product. You must define one on the product category,
 or on the location, before processing this operation.”

When installing the "l10n_fr" module, the French accounting for the default company will be set. so the
"property_stock_account_input_categ_id" will not be set when creating a product category with "property_valuation" set as real_time because the user's company has no chart of accounts:

https://github.com/odoo/odoo/blob/c3b4c7d8f2c260c31f9549d480ed2db4159a8119/addons/stock_account/models/product.py#L833-L835

Therefore, when validating the picking related to the purchase order created:
https://github.com/odoo/odoo/blob/31d1a2a8a0f1490dd49d86628c0f856ca82198c8/addons/purchase_stock/tests/test_purchase_order_process.py#L124

The product accounts are then retrieved, but will be False: https://github.com/odoo/odoo/blob/9215e73fa229d64167de076ef0a288dd8d89a2cc/addons/stock_account/models/stock_move.py#L336 https://github.com/odoo/odoo/blob/493502bc4ad3ac35b1c0cb2eeb73ac6b6d0fe5b5/addons/stock_account/models/product.py#L29

**Solution:**
skip the test if the user's company has no chart of accounts.


opw-3698341

Forward-Port-Of: odoo/odoo#152128
Forward-Port-Of: odoo/odoo#151712

In databases with multiple companies, currencies and lots of `account_move_lines`, generating consolidations journals can take a lot of time. There are two bottlenecks for that. The first one comes from `_apply_historical_rates`. The second one is the creation of the `consolidation_journal_lines` records. Nothing can be done about the latter as there are just a lot of records to create. This commit focuses on the former.

To speed up `_apply_historical_rates`, a rate_cache is passed through the context to the `get_rate_for` method of consolidation rates. This method is called a lot of times (once by move_line) with mostly the same values (company_id and chart_id are fixed, only the date changes). Adding a small cache vastly reduces the number of queries on `consolidation.rate`.

Also, instead of calling `res_currency_rate._convert` to convert an amount from a given currency to another one, a currency_rate cache is introduced. This cache contains a mapping between `(from_currency, to_currency, company_id, date)` and the conversion rate. That way, `res_currency_rate._get_conversion_rate` is only called for new key-value, which greatly speeds up the generation of consolidations journals.

#### speedup
Customer database with 2.5M account.move.lines, 2M account.moves, 202 consolidation_periods, 243 consolidation accounts, 0 consolidation_rate, 17 companies, 8512 accounts.

Timing to generate consolidation journals.

| #account_move_lines, #res_currencies | Before PR | After PR |
|:----------------------------------------------------:|:--------------:|:-----------:|
| 1036 amls, 2 currencies | 7s | 1.89s |
| 4329 amls, 7 currencies | 2.2min | 19.3s |
| 15301 amls, 7 currencies | 1.4min | 1.4min|
| 43749 amls, 6 currencies | 22.1min | 2min|
| 134055 amls, 7 currencies |21.6min | 3.3min|

The third entry only contains non-historical consolidation accounts so no visible speedup is expected.

Forward-Port-Of: odoo/enterprise#55692
Forward-Port-Of: odoo/enterprise#54030

Steps to reproduce:
-------------------
In Data Cleaning app, try to apply a custom filter on Company with "contains" or "not contains" operator.

Issue:
------
A traceback occurs.
For this line: `res = self._obj.execute(query, params)`, we have `IndexError: list index out of range`.

Cause:
------
There is a mismatch between the `%` in the query and the number of parameters.

The query is constructed by combining subqueries with a template. These subqueries will be determined using the `mogrify` method and will be concatenated to the main query template.
The `'` characters are correctly escaped with `\` , but the `%` characters are not.

Solution:
---------
Don't use mogrify, so that we can keep the subquery parameters
and pass them directly to the main query.
By leaving the values wrapped with `%` in the parameters,
there are no more escape problems.

Note:
This is a better fix than manually escaping the `%` if necessary like:
```py
if operator in ('not ilike', 'ilike'):
	value = f'%{value}%'
```

opw-3668433

Forward-Port-Of: odoo/enterprise#55204
Forward-Port-Of: odoo/enterprise#54287

The Location API allow developpers to specify options when requesting a device's location - notably, it can request 'high accuracy' positioning.

By default, 'high accuracy' is set to false so that the location API returns a position *quickly*. We can assume that it will return a position based on e.g. WiFi networks it sees around it and an API call to a location provider like Google, Apple, Here, etc. Setting 'high accuracy' to high will make this process much slower (20-30s is not gonna be an exception), but it means that devices with built-in GPS will usually provide an far more precise location.

In Sign, it's rather important to have reliable data rather than a quick process.

Assuming a person signing something for real, it's safe to assume that the browser will have the time to provide a precise position before the user submits their signature. If not, the position will simply not be saved.

opw-3677499

Forward-Port-Of: odoo/enterprise#55588
Forward-Port-Of: odoo/enterprise#55411

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.

Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line:

if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):

In SaaS 16.4, this line returns the following SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";

Here, we check if the Active state is True to block the message if necessary.

In 17.0, this same line returns this SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";

This time, the Active state is not checked, so regardless of whether it's False or True, the message is blocked. This makes it impossible to have a conversation with a customer in Odoo 17.0

The solution is to add ('active', '=', True) to the line in 17.0

if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c

Forward-Port-Of: odoo/enterprise#55498

Problem
---------
With the integration of Codabox in l10n_be_codabox, we need to managed the automatic import of SODA. This is currently done but can be improved.

Objective
---------
Adapt the following point:

1. Put the date from <GenDate> by default in the date of document
2. Add the period linked to the document in the ref of the document. This info is store in the field <AccountPeriod>
3. In the matching form between SODA account and Account in the company: Merge the account and the name from SODA (to be consistante with the
 column in which the user should add account)

Solution
---------
1. Simply add the date data from the XML in the dictionary that will be passed to the wizard creating the account move and make sure the wizard gives that value in the move create method.
2. Concatenate the formatted <AccountPeriod> text to the ref.
3. Add a compute method to computes the display_name for the current model as it is done in account_account. Use the display name in the wizard view in readonly instead of the SODA account codes and names.

task-3615994

Forward-Port-Of: odoo/enterprise#55540
Forward-Port-Of: odoo/enterprise#53204