…prone

Currently when we call copy data twice (e.g. due to some strangely designed 2many fields), the second call returns None instead of a list containing a values dict. Use case is linked to whatsapp, where a template contains variables and buttons. Buttons also contains variables, shared from templates. It means than copying a template and its buttons calls the copy_data twice on variables once from the template and once from buttons.

This is quite annoying as ``copy_data`` crashes, expecting sub calls to return a list with one element.

We plan to change this design but this fix target stable version, and anyway copy_data should be resilient in case this design happens in some module.

Looking at odoo/odoo@4ac2702c31f0e95f33f9ad554e7350bef9dab8bd None is appended to the returned list of values when converted into multi copy. In this fix we choose to do the same kind of behavior in order to be coherent. It now returns [None] instead of None, allowing notably to avoid issues with a one-liner filtering None from returned list.

Task-

Forward-Port-Of: odoo/odoo#160332
Forward-Port-Of: odoo/odoo#157576

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

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

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

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

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

Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs
for more details, each being related to a specific issue to fix.

Task-3807017, master fix task

Contains fixes done for following tasks / tickets
* Task-3619004 (WhatsApp: Fix variable computation and name)
* Task-3680030 (WhatsApp: Fix buttons / template duplication)
* Task-3829328 (WhatsApp: Allow to send yellow quality templates)
* Task-3644990 (Whatsapp: Fix retrying message with report on template)
* Task-3679715 (WhatsApp: Fix cron block or crash with shared users)
* Task-3576712 (WhatsApp: Sync template attachments at sync, avoid missing)
* Task-3640336 (WhatsApp: Fix Document Header / Report mismatch)
* Task-3605612 (WhatsApp: Fix header / upload / reporting usage)
* Task-3640336 (WhatsApp: Fix Document Header / Report mismatch)
* Task-3794483 (WhatsApp: Add account information in template views)
* Task-3794365 (WhatsApp: Ease module / variable name change)
* Task-3691887 (WhatsApp: Avoid draft templates in event mail schedulers)
* Task-3732188 (Whatsapp Event: Avoid crashing registration process)

Co-Authored-By: Amélie Dieudonné <amdi@odoo.com>
Co-Authored-By: Akshat Trivedi <aktr@odoo.com>
Co-Authored-By: Dato Nefaridze <dane@odoo.com>
Co-Authored-By: Nishant Jain <niai@odoo.com>
Co-Authored-By: Rahul Prajapati <rapr@odoo.com>
Co-Authored-By: Noé Antoine <nan@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>

Forward-Port-Of: odoo/enterprise#59987
Forward-Port-Of: odoo/enterprise#58535

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

If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the rule's method the registry will [return](https://github.com/odoo/enterprise/blob/961f67d776a8ec1d9293ed599f284807930496d5/web_studio/models/studio_approval.py#L200) a `None` model, which then causes an AttributeError.

We add a check for the Model's existence, so that any None models are skipped. This follows the approach in [base_automation](https://github.com/odoo/odoo/blob/d11ece23e97189f38040254917a3517e21386e47/addons/base_automation/models/base_automation.py#L847-L857), which was the technical inspiration for the [commit](https://github.com/odoo/enterprise/commit/3db107ae481a8da85aa356c729bae5fc246e655b) that implemented the approval rule logic.

Ticket: [3754939](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form), [3777251](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form)
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 606, in load_modules
    model._register_hook()
  File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 203, in _register_hook
    _patch(Model, approval.method, approval_method)
  File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 132, in _patch
    ModelClass = model.env.registry[model._name]
AttributeError: 'NoneType' object has no attribute 'env'
```

Forward-Port-Of: odoo/enterprise#58688