**Problem**:
Loading large images into the cropper takes time. Closing the cropper early causes `this.imageRef.el` to be `null` or `this.initialSrc` to be `undefined`, leading to a traceback.

**What happens**:
1. Add a large image.
2. Click "Crop".
   - This triggers `show`.
   - While `loadImage` is still unresolved due to image size.
3. Click "Discard" to close the cropper before image loads.
   - **Issue**: `this.imageRef.el` is `null` and `this.initialSrc` is `undefined` as the component is destroyed but `loadImage` has not resolved yet, when it is resolved a traceback will be appear.

**Solution**:
Add a lifecycle flag as full mounting of the cropper might take time.

**Steps to Reproduce**:
1. Add a large image.
2. Open cropper.
3. Close cropper before image loads.
   - **Issue**: Traceback.

opw-4607020

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

Forward-Port-Of: odoo/odoo#203102
Forward-Port-Of: odoo/odoo#200729

### Issue:

Tldr: If a field A depends on an other computed field B and if the value of A is used in the computation of the field B, the ORM will consider that the value of A is false  (or empty record set) in the computation of B.

On the `mrp.production` model, the `product_tmpl_id` is a related non stored field:
https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L82 depending on the `product_id` field. This means that if we need to access the value of that field, we will first need to access the value of the `product_id` field. However, the `product_id` field is a computed field: https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L62-L66 So that if its value is marked as dirty in the cache at the moment we try to access the value of the `product_tmpl_id` of the we will launch a call of its compute method. This is problematic because the 'related' that launched the compute is used inside the compute method: https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/addons/mrp/models/mrp_production.py#L397 This is probelmatic because it would technically lead to an infinite recursion loop. So, to avoid any of these situation, when the computation of the `mrp.production.product_tmpl_id` has been started the filed has been marked as protected and is used as "False" in each of the subsequent computations:
https://github.com/odoo/odoo/blob/4cb362fcc3c2ba2489ef1de7c20c9a4fd8921ab8/odoo/fields.py#L1295-L1299 In particular, we will compute the `product_id` of the mrp.production considering that the `product_tmpl_id` is false and we will therefore set a wrong value on the bom.

### Steps to reproduce:

Using studio, you can create a set of fields linked to the 'product.template' and `mrp.production` models and an automated rule that will force a situation where the above situation will be triggered with the following flow:
- Create a product with 2 variants.
- Create a bom for the template of these products and one bom line:
    - 1 x COMP
- Create and confirm an MO for 1 unit of variant 2.
- Change the bom line to 2 x COMP.
#### > Return to the MO and click on update bom, the `product_id` of the MO has been altered to variant 1.

The details of the set up are the following:
1. Create a new field with the following configuration: Name: x_studio_1 Model: Product Field Type: many2one Stored: True Related Model: res.partner
2. Create a new field with the following configuration: Name: x_studio_2 Model: Manufacturing Order Field Type: char Stored: True Readonly: True Related Field Definition: product_tmpl_id.x_studio_1.name
3. Create an automation rule on the manufacturing order model that trigger on save and that trigger's the action of updating the record responsible to Joel willis.

### Fix:

We should not rely on the related field `mrp.production.product_tmpl_id` inside the compute method of the `mrp.production.product_id`. Particularly since we can access this value using the direct path to this value. This avoids any recursion issue.

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

Forward-Port-Of: odoo/odoo#203956

Steps to reproduce the bug:
- Start a new database without demo data (make sure the product variant option is disabled).
- Install the purchase module
- Enable the UoM option in the Purchase settings
- Go to Purchase → Configuration → Vendor Pricelist
- Create a new one

Problem:
A traceback is triggered:
“Caused by: TypeError: Cannot read properties of undefined (reading '0') at Many2OneUomField.template”

This issue occurs because, in the pricelist form view, the field “product_uom_id” is using the widget “many2one_uom”:

https://github.com/odoo/odoo/blob/b6732a405362373f6ad92a8557e9cef79357d055/addons/product/views/product_supplierinfo_views.xml#L27

However, this widget requires the “product_id” field to work properly: https://github.com/odoo-dev/odoo/blob/682f49c72c8fcb9c81e07b084de9333f14815058/addons/uom/static/src/components/many2x_uom_tags/many2x_uom_tags.xml#L13

But the “product_id” field is restricted to users with the “group_product_variant”, meaning it cannot be accessed by the widget. As a result, the widget tries to read an undefined element, causing the error:
https://github.com/odoo/odoo/blob/b6732a405362373f6ad92a8557e9cef79357d055/addons/product/views/product_supplierinfo_views.xml#L23

2:/ The same issue can occur with the BoM list:

- Create a BoM:
    - Product: P1
    - save
- Go to the BoM list:
    - Select the created BoM
    - Try to update its UoM directly from the list view

Problem:
The same error occurs.
Opw-4666641
Opw-4672104
Opw-4673028
Opw-4670980
Opw-4655011

Forward-Port-Of: odoo/odoo#203898

LATAM task 1299 / Adhoc Task 47453

---

### Description of the issue/feature this PR addresses:

Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes.

For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448

### Current behavior before PR:

Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals

![before-print-detail-other-taxes](https://github.com/user-attachments/assets/2bc416c9-4231-42c4-8c71-fd1f5531d3d2)

### Desired behavior after PR is merged:

We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes

![new-taxes](https://github.com/user-attachments/assets/d75ae2ad-b787-4399-a9d7-c6b3082c67ec)

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

Forward-Port-Of: odoo/odoo#203521
Forward-Port-Of: odoo/odoo#201257

Issue:
========

There is an issue during the generation of invoices from subscription that causes the is_invoice_cron field on the sale order to remain `True`. This prevents the processing of transactions and, as a result, does not mark the invoices as paid. Furthermore, this issue blocks the generation of subsequent invoices.

To reproduce:
=============

1. Create a subscription that does not require initial client payment, (can generate an invoice on the next invoice date).
2. Create 30 other subscriptions (equal to the batch size value) that cannot generate invoice until the client has made a payment.
3. Run the scheduled action “Sale Subscription: generate recurring invoices and payments.”
4. You will notice that the first Sale Order remains to “is_invoice_cron” as True

Problem:
========
the condition to trigger the cron to invoice subscriptions is based on the number of subscriptions that can be invoiced in a batch. But we are taking all the subscriptions while it should be only the subscriptions that can be invoiced.

Solution:
=========
filter the subscriptions that can be invoiced before checking the condition to trigger the cron to invoice subscriptions.

opw-4559250

Forward-Port-Of: odoo/enterprise#82477
Forward-Port-Of: odoo/enterprise#82340