In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:
https://github.com/odoo/odoo/blob/f7ee5633a8c80afca05074b8574e9c2a720e4bc9/addons/point_of_sale/models/pos_config.py#L496

Steps to reproduce:
1. Install PoS and IoT applications -- will install `pos_enterprise` module.
2. Set is_posbox = True, via the PoS settings.
3. Uninstall IoT application -- will uninstall `iot` and `pos_iot` modules.
4. Try to install a module that writes in a column of the pos_config with is_posbox=True

We get an error like:
```
...
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 569, in _button_immediate_function
    raise UserError(_('The method _button_immediate_install cannot be called on init or non loaded registries. Please use button_install instead.'))
odoo.exceptions.UserError: El método _button_immediate_install no puede ser llamado en registros init o no cargados. Por favor, utilice button_install en su luga
```

The issue is that when we uninstall `iot` module the flag is never reset. This then causes issues if we try to install a module that writes on any value of `pos.config`. Observed during upgrades, e.g `l10n_es_pos` at xml load of data files. Other modules also affected.

The solution we propose here is to introduce a _soft_ dependency between pos_iot -- which is an enterprise module -- and pos_enterprise. The former checks at uninstall if the latter is installed to clear the `is_posbox` flag.

Forward-Port-Of: odoo/enterprise#59810

**[FIX] website: fix conditional visibility depending on date field**

Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. This change resulted in a
modification of the HTML structure for date(time) input fields.

Consequently, a bug emerged in the visibility options for fields reliant
on a date(time) field. Specifically, the time condition selector failed
to display the time conditions because they are rendered based on the
HTML structure of the fields.

Since the code was not adjusted to fit the new structure, this
functionality stopped functioning.

[1]:  https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628

task-3790809

----------------------------------------------
**[FIX] website: fix traceback with website form date(time) fields**

Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. A traceback appears when loading
a website form containing a field dependent on a date(time) field.

This traceback occurs because when checking the value of an empty
date(time) field (which happens when the user hasn't yet filled out the
form), we parse the field value into a Date(Time).

Before the changes in commit [1], we parsed this differently, which
didn't crash but returned "NaN" with an empty date(time) field.

In this commit, we now check whether a date(time) is valid and if not,
we now assign it "NaN" to maintain exactly the same behaviour as before
the commit [1]. Any value other than "NaN" would not work with the date
comparison system and would break certain conditions.

This commit also adds steps to the "website_form_editor" test tour so
that it fails without this commit.

[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628

task-3790809

Forward-Port-Of: odoo/odoo#158288

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#159982
Forward-Port-Of: odoo/odoo#159276

Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address.

Steps to reproduce:
-------------------
* Go to the **Contacts** app
* Select any contact (ex: Azure Interior)
* Under **Contacts & Addresses** select Add
* Select **Invoice Address**
* Write the address then **Save & Close**
* Go to the **Point of Sale** app
* Add items
* For customer, select the contact we just modified
* Select **Payment**
* Select any payment method
* Select **Invoice**
* Validate
> Observation: The invoice address is not used

Why the fix:
------------
We observe a discrepancy between the sale and pos output for the same workflow.
* Sale
  * Sale order form: `Customer` -> Azure interior (Has a field for invoice address)
  * Account move form: `Customer` -> Azure interior, Az inv (Use the invoice address)
* PoS
  * PoS order form: `Customer` -> Azure interior (Does not have a field for invoice address)
  * Account move form: `Customer` -> Azure interior

In stable we can't add the invoice address on the PoS order form but we can still stay consistent with the sale workflow in terms of account move.

In the sale workflow, the move is created with `invoice_vals_list` https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1207

Having a look at `invoice_vals_list`, we can see that the customer_id is set using the invoice contact address. https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1004

With `partner_invoice_id` computed as follows:
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L340-L342

Thus, we also send the invoicing contact address as partner_id when creating the move in pos;

opw-3797434

Forward-Port-Of: odoo/odoo#159856
Forward-Port-Of: odoo/odoo#159172

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

Forward-Port-Of: odoo/odoo#160129

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

Forward-Port-Of: odoo/odoo#156447

**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#160143
Forward-Port-Of: odoo/odoo#159043

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

Forward-Port-Of: odoo/odoo#159264

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

Forward-Port-Of: odoo/odoo#159255