Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.

1. Directly create an invoice.
    - Create and confirm a subscription with a combo product.
    - Create an invoice for this subscription and try to confirm it.
    - Validation error shown in display and error generated in log

2.  When cron "Payment: Post-process transactions" trigger:
    - Enable the Automatic Invoice option in the Subscription settings.
    - Activate a demo payment provider (e.g. Demo: Payment Provider).
    - Create and confirm a subscription that includes a combo product.
    - Click on "Pay" to process the subscription payment.
    - An error occurs when the above-mentioned cron is triggered, and it
      tries to create an invoice for a subscription order.

Error: `new row for relation "account_move_line" violates check constraint
 "account_move_line_check_accountable_....`

This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`

This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].

[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309

sentry-6763423503

Forward-Port-Of: odoo/enterprise#90989

This commit fixes two issues related to the milestones settings of generated projects in SO:

First issue:
* Steps to reproduce:
    - Create a product whose invoicing is based on milestones
    - Add this product to an SO
    - Confirm the SO
    - Create a project from the action button in the SO form view ('Create a Project'), with or without a project template
    - The generated project does not have the milestone setting enabled

* Expected behavior:
    => When creating a project from the SO in which there is at least 1 product with invoicing based in milestone, the setting "Milestone" should be checked by default

Second issue:
* Steps to reproduce:
    - Create a product with an invoice policy based on milestones
    - Create another product with another policy
        => Both products must be configured to create a project on SO confirmation, without a project template
    - Create a new SO with both products as SOLs
        => Set the second product (other policy) in first sequence, then the first product (milestones based) in second sequence, as the order of SOLs
    - Confirm the SO
    - The generated project does not have the milestone setting enabled

* Expected behavior:
    => The generated project should have the milestone setting enabled, as at least one product with an invoicing policy based on milestones has triggered the generation of that project

task-5090253
version: 19.0

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

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Enterprise: https://github.com/odoo/enterprise/pull/92951

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

Forward-Port-Of: odoo/odoo#224947
Forward-Port-Of: odoo/odoo#223852

The "Supported Payment Methods" snippet introduced in [^1] was designed to cache payment methods to minimize server calls. However, this cache was stored in session storage, meaning it wasn't invalidated on page reloads. While this behavior worked well for regular customers, it was problematic for admins who needed to see backend changes reflected
immediately upon reloading the page.

This commit shifts the caching logic to rely on the HTTP caching mechanism. This change eliminates a significant amount of frontend code and centralizes the logic in the backend.

The new approach disables caching for logged-in internal users while enforcing caching for regular customers visiting the website. Since payment methods are not expected to change frequently, a 7-day cache policy is enforced. After this period, the client must revalidate with the server, ensuring any inconsistencies are resolved in a timely manner.

Additionally, a safeguard has been added to the snippet to prevent warnings in the console.

task-2889752

[^1]: https://github.com/odoo/odoo/pull/213234

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Community: https://github.com/odoo/odoo/pull/223852

opw-5009635

Forward-Port-Of: odoo/enterprise#93995
Forward-Port-Of: odoo/enterprise#92951

### Issue:
Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill the vendor bill form view.

#### Steps to reproduce:
- Install "l10n_ec_edi" and switch to an Ecuadorian company
- Have a file downloaded from the SRI.
- Go to Accounting > Vendor > Bills
- Click "Upload" and select the file
- The generated move is not populated with the data

### Cause:
We are expecting the XML to not be in the tag `CDATA` and it gets ignored.

### Solution:
The change is in `_get_import_file_type` to detect the new type of file as `'l10n_ec.factura'`.

The CDATA content can be fetched by getting the content of the tag `comprobante`. We then try to convert the content of `comprobante` to XML. If it's possible, we have an XML on which we can do the same check as before to know if it's an Ecuadorian invoice. We then replace the `file_data['xml_tree']` by the content of `CDATA` to have the correct XML for the data extraction.

opw-5004636

Forward-Port-Of: odoo/enterprise#94184

### Issue
PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError.

### Solution
Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type.

### Affected Reports
- `account.report_original_vendor_bill` - Vendor bill reports
- `hr_expense.report_expense_sheet` - Expense sheet reports

### Affected Versions
- 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense)

### Reproduction Steps

#### Option A: HR Expense Report
1. Create HR expense record
2. Add attachment with type=url/cloud_storage pointing to valid PDF URL
3. Link attachment to hr.expense record
4. Generate expense report → TypeError occurs

#### Option B: Vendor Bill Report
1. Create vendor bill (account.move)
2. Add attachment with type=url/cloud_storage pointing to valid PDF URL
3. Link attachment to account.move record
4. Print Original Vendor Bill → TypeError occurs

### Error Details
```python
TypeError: a bytes-like object is required, not 'bool'
  at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream
  from /odoo/addons/hr_expense/models/ir_actions_report.py:29
```

#### Reference
Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view

OPW-5036638

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

Forward-Port-Of: odoo/odoo#227571
Forward-Port-Of: odoo/odoo#226094