Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
  modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.

However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.

The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
  the minimum delay that made Google give us good page scoring but it
  may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?

Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:

- **The reasonable risk we take merging this in stable (we considered
  merging in a more recent version but it is needed for some specific
  projects and many websites would benefit from this improvement).**

- Any custom code that added behavior on buttons to be available during
  lazy loading... will just wait for lazy loading with a loading effect
  too now. This should be a good compromise as, again, that lazy loading
  is cached and should not take too long anyway.

Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).

Overall:
- This should not impact (neither improve nor worsen) most websites that
  are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
  experienced from bad internet connections.

Related to task-3770362

Forward-Port-Of: odoo/odoo#159572
Forward-Port-Of: odoo/odoo#158661

**Step to reproduce:**

- Install `Knowledge` and `Documents` modules (for test purpose)
- Go to Documents app
- Click on Action button -> Knowledge -> Insert view in article
- Select any article

**Issue:**

View is not loaded correctly in the article.
Error message: Something went wrong! The view does not exist or you
               are not allowed to access to it.

**Cause:**

In the imported view, we try to retrieve the selected Folders, but this last one need the search model to retrieve the data.

https://github.com/odoo/enterprise/blob/11daa694d4ca51939c2b458bced8ab9d48030ef8/documents/static/src/views/documents_controller_mixin.xml#L5

The method called to retrieve the folders (`getSelectedFolder`) is set on the documents search model (`DocumentsSearchModel`), however, the search model set in the embedded_view is the knowledge search model (`KnowledgeSearchModel`).

**Solution:**

Change the `KnowledgeSearchModel` class into a mixin so it can extend the (potentially) custom search model defined for any embedded view during the mounting process (default to the generic search model), instead of overwriting it.

opw-3752927

Forward-Port-Of: odoo/enterprise#59758

Steps to reproduce:
- Install Invoicing
- Create a product with $0 cost (e.g. Product X)
- Create a vendor bill:
  * Vendor: [any]
  * Invoice Lines:
    - Product: [none]
    - Label: [anything]
    - Price: [any]
    - Taxes: [any]
=> The displayed "Untaxed Amount", "Taxes" and "Total" are correct
- Save the vendor bill
- Edit the invoice line of the bill
- Add Product X => "Untaxed Amount", "Taxes" and "Total" are correctly set to 0 as expected
- Change Price to 100 manually

Issue:
"Untaxed Amount", "Taxes" and "Total" stay at $0.
Upon save, "Untaxed Amount" is correctly set to $100, but "Taxes" stays at $0.
If "Units of Measure" option is activated in the Settings (available with Sales, Purchase or Inventory app), the user will be in "uom.group_uom" and the issue will not happen.

Cause:
When the user isn't in "uom.group_uom" group, "product_uom_id" field is declared after "price_unit" field in the view.
Due to that, adding a product in the invoice line and changing the price to $100, will first set "price_unit" to $100 and then set "product_uom_id" that will trigger "_compute_price_unit" method where "price_unit" is recomputed to $0 (its cost).

Solution:
Move "product_uom_id" field before "price_unit" field in the view as it is the case when the user is in "uom.group_uom" group.

opw-3750740




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

Steps to reproduce:
- Install l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create an invoice:
  * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
  * Product: [any product with UNSPSC Category set]
- Confirm the invoice
- Go to the portal preview of the invoice
- Download the invoice from portal

Issue:
1) On the invoice, the CFDI document has been generated and processed without notice.
Downloading an invoice from portal should only download the invoice.

2) There are 2 buttons on the portal: "Download" and "Print".
The "Print" allows to print the invoice, even if it has not been generated and sent yet.

Cause:
When downloading an invoice from portal, we are going through the "Send & Print" wizard (without displaying it) with only "Download" option checked.
However, some localization (e.g. MX) may add specific options that are checked by default (e.g. CFDI), which triggers the corresponding flow.

Solution:
1) Make sure that all options of "Send & Print" wizard are deactivated, except "Download".
Download existing invoice documents or generate a Pro Forma document when downloading invoice from portal.

2) Remove "Print" button from portal view.

opw-3821371




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

In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.

Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)

When deleting this line, a traceback is raised

Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):

| ID | Product | Quantity |
|----|---------|----------|
| 1  | Table   | 6        |
| 2  | Lamp    | 1        |

Page 2 (`3 - 4 / 4`):

| ID | Product | Quantity |
|----|---------|----------|
| 3  | Chair   | 4        |
| 4  | Board   | 3        |

In this case we have two cached elements: the two elements visible on
the first page.

In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:

```js
{
    "1": {
        id: "datapoint_4",
        ...
        data: {
           sequence: 10,
           name: "Table",
           product_uom_qty: 6,
           display_type: false
           ...
        }
    },
    "2": {
        id: "datapoint_11",
        ...
        data: {
           sequence: 10,
           name: "Lamp",
           product_uom_qty: 1,
           display_type: false
           ...
        }
    }
}
```

After sorting by quantity, we end up with

Page 1 (`1 - 2 / 4`):

| ID | Product | Quantity |
|----|---------|----------|
| 2  | Lamp    | 1        |
| 4  | Board   | 3        |

Page 2 (`3 - 4 / 4`):

| ID | Product | Quantity |
|----|---------|----------|
| 3  | Chair   | 4        |
| 1  | Table   | 6        |

It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).

But as we only need the quantity information, we only fetch this field
from the records on the following pages.

In terms of cache, we have something like this

```js
{
    "1": {
        id: "datapoint_45",
        ...
        data: {
           sequence: 10,
           name: "Lamp",
           product_uom_qty: 1,
           display_type: false
           ...
        }
    },
    "3": {
        id: "datapoint_16",
        ...
        data: {
           sequence: 10,
           name: "Board",
           product_uom_qty: 3,
           display_type: false
           ...
        }
    },
    "4": {
        id: "datapoint_32",
        ...
        data: {
           sequence: 10,
           name: "Table",
           product_uom_qty: 6,
           display_type: false
           ...
        }
    },
    "2": { //Chair
        id: "datapoint_1",
        ...
        data: {
           sequence: 10,
           product_uom_qty: 4,
        }
    }
}
```
We therefore have one new incomplete record in the cache

The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this

Page 1 (`1 - 2 / 3`):

| ID | Product | Quantity |
|----|---------|----------|
| 2  | Lamp    | 1        |
| 3  | Chair   | 4        |

Page 2 (`3 - 3 / 3`):

| ID | Product | Quantity |
|----|---------|----------|
| 1  | Table   | 6        |

So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
    "4": { //Chair
        id: "datapoint_32",
        ...
        data: {
           sequence: 10,
           product_uom_qty: 4,
        }
    },
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.

This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.

https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912

opw-3771077

When a background video and an animation coming from the left or the right are on a page at the same time, there sometimes is a horizontal scrollbar that appears for no reason. It can happen at any screen size but more frequently near 1000px and below. This issue seems to happen on Chrome only.

It seems to be a race condition between the calls to the `_adjustIframe` function in the `backgroundVideo` public widget. Indeed, this function is called when the video is added in the DOM and each time the screen is resized. When an animation is played, it triggers a resize of the window when it is over, which therefore calls `_adjustIframe`.

When the animation comes from the right/left of the screen, the animated element is translated from outside the page; the page width is therefore bigger but its overflow is prevented. When the video is loaded, the loading placeholder is removed. Depending on the time it takes to it to fully load, if the animation ends before it, the iframe is adjusted before the placeholder removal, leaving the iframe wrongly adjusted when it is finally removed.

Note that it is hypothetical, as everything refreshes when inspecting the DOM, making the scrollbar disappear. But this proves that no element is really overflowing, so it seems to be a value refreshing issue.

This commit adds a call to `_adjustIframe` when the video has loaded, to make sure its dimensions are recomputed/refreshed, preventing the scrollbar to appear.

Steps to reproduce:
- Drop a "Text-Image" snippet.
- Set a background video to it.
- Add the "Fade In-Right" animation to the image column.
- Save and then resize down the screen to 1000px or below.
- Refresh. 
=> When the video is loaded, a horizontal scrollbar may appear. If not, refresh until it does.

opw-3487117

Forward-Port-Of: odoo/odoo#159193

This traceback arises when the user changes the date with a new employee of no contract 
while creating a new Work Entry.

To reproduce this issue:

1) Install `hr_work_entry_contract`
2) Open `payroll` and create a new `Work Entry`
3) Select `Work Entry Type` as `Unpaid` and create a new employee 
4) Now try to change the `end date`

Error:- 

```
KeyError: False
  File "odoo/http.py", line 2252, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1828, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1848, 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 1826, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1833, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2058, 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_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, 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/web/models/models.py", line 1074, in onchange
    todo = [
  File "addons/web/models/models.py", line 1077, in <listcomp>
    if field_name not in done and snapshot0.has_changed(field_name)
  File "addons/web/models/models.py", line 1190, in has_changed
    return self[field_name] != self.record[field_name]
  File "odoo/models.py", line 6669, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "odoo/fields.py", line 1138, in __get__
    self.recompute(record)
  File "odoo/fields.py", line 1353, in recompute
    apply_except_missing(self.compute_value, recs)
  File "odoo/fields.py", line 1326, in apply_except_missing
    func(records)
  File "odoo/fields.py", line 1375, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 4982, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 102, in determine
    return needle(*args)
  File "addons/hr_work_entry/models/hr_work_entry.py", line 84, in _compute_duration
    durations = self._get_duration_batch()
  File "home/odoo/src/enterprise/saas-17.1/hr_work_entry_contract_planning/models/hr_work_entry.py", line 46, in _get_duration_batch
    res.update(super(HrWorkEntry, super_we)._get_duration_batch())
  File "addons/hr_work_entry_contract/models/hr_work_entry.py", line 119, in _get_duration_batch
    result[work_entry.id] = mapped_contract_data[(date_start, date_stop)][calendar][employee.id]['hours']
```

On the `_get_duration_batch` method, when the user creates a new employee without a contract, 
the calendar remains an empty recordset.

which leads to the traceback from the below lines.

https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112

After applying this commit will resolve the issue by making the code more robust 
and gives the default value for `work_entry.id`.

sentry-5095168051

Forward-Port-Of: odoo/odoo#159276

Follow-up of [1]. Commit [2] refactored the way we check if an option update needs to trigger a page reload: if the option is marked as a page option (`data-page-options="true"` on the option's main `<div>`), then it will reload whatever the method used if there is a `reload` parameter. Note that this `reload` parameter does not make much sense anymore, it should be reviewed/removed in master.

Problem: [2] made a mistake in its implementation, pushing an array instead of concatenating it. This worked by chance, as instead of asking "does this option method requires a reload", it was asking "does this set of option methods requires a reload"... and in that case, the code is fallbacking on retrieving common parameters, which `reload` likely is without custo. This could have been fixed in master only. Given the very low risk of breaking anything critical updating this code, it was chosen to prevent a potential crash in custo (which could occur as we give a wrong parameter type to a main method) and allow overrides to make `reload` a specific parameter for a specific method without the need of `data-reload` added in the DOM.

[1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-70f7fe38208aa7fe678f18e329d3c11b70065dee723921352b6005774e8bab53R456

Forward-Port-Of: odoo/odoo#159640

Description of the issue/feature this PR addresses:

- This PR addresses an issue in the `hr_contract` module where the `_compute_newly_hired` method can crash depending on the value type of the `new_hire_field` field.


Current behavior before PR:
- In an Odoo instance with `hr_payroll` installed, when querying the `newly_hired` field on the `HrEmployeeBase` model, the request fails with an error (refer to issue #154849).
- This failure is due to a change in the field used by Odoo to determine if the employee is newly hired, from a Datetime (`created_at`) to a Date (`first_contract_date`).
- The request also fails if the employee has never been associated with any contract because the return value is a boolean.

Desired behavior after PR is merged:

- This PR ensures that the `newly_hired` field can be queried without causing a crash, correctly indicating if an employee is newly hired.

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

**Steps to reproduce:**
- Install Accouting and Expenses
- Activate "Analytic Accounting" in Accounting settings
- Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans"
- Create an analytic plan with the following line:
  * Domain: Expense
  * Applicability: Mandatory
- Create an analytic account from the plan via "Analytic Accounts" smart button
- Create an expense without analytic
- Create a report from it
- Submit it to manager
- Try to approve it
=> An expected Validation Error will raise: "One or more lines require a 100% analytic distribution."
- Go to "Expenses / Expense Reports" (list view)
- Select the created expense report
- Try to approve it

**Issue:**
The report will be approved even if there is no analytic configured on it.

**Cause:**
"validate_analytic" option is not passed in the context when approving the report from list view as it is done in form view.

opw-3806787



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

Forward-Port-Of: odoo/odoo#160013
Forward-Port-Of: odoo/odoo#159043

Have an x2many with several pages containing a field with a readonly modifier (in the view, not in the field definition), e.g. `readonly="1"` in the arch. Have an onchange that returns an UPDATE command for a record that isn't in page 1 (so a record we haven't read), with a value for that readonly field. Before this commit, the value was sent in the UPDATE command, even though readonly fields shouldn't be sent.

The difficulty here is that we can't always evaluate those readonly expressions, as they can depend on other fields, which we didn't read if the record is in a page we didn't browse to yet. However, "static" expression like `"1"`, or `"context.get('something')"` can totally be evaluated, and they should. This is what this commit does.

Steps to reproduce the issue:
 - Install mrp
 - Go to Manufacturing > Products > Bill of Materials
 - New:
    - Product: quick create "B1"
    - Components: two lines: quick create "C1" and "C2" - Save
 - Manufacturing > Operations > Manufacturing Orders
 - New [in that form view, set the limit of the x2many to 1]:
    - Product: "B1"
    - Save - Change quantity to 2 - Save => Invalid Operation

opw 3819253

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

Description of the issue/feature this PR addresses:

- This PR addresses an issue in the `hr_contract` module where the `_compute_newly_hired` method can crash depending on the value type of the `new_hire_field` field.

Current behavior before PR:
- In an Odoo instance with `hr_payroll` installed, when querying the `newly_hired` field on the `HrEmployeeBase` model, the request fails with an error (refer to issue #154849).
- This failure is due to a change in the field used by Odoo to determine if the employee is newly hired, from a Datetime (`created_at`) to a Date (`first_contract_date`).
- The request also fails if the employee has never been associated with any contract because the return value is a boolean or none.

Desired behavior after PR is merged:

- This PR ensures that the `newly_hired` field can be queried without causing a crash, correctly indicating if an employee is newly hired.

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