This commit provides a cron job to migrate attachment binary to the
cloud storage. The cron job is designed to be manually triggered from
by the "Run Manually" button of the Scheduled Action's form view.

The cron job will try to upload some attachments once
    1. size is greater than the minimum upload file size defined by
       (ir.config_parameter: cloud_storage_min_file_size)
    2. id is greater than the number defined by
       (ir.config_parameter: cloud_storage_migration_min_attachment_id)
    3. res_model is in a white list
       (ir.config_parameter: cloud_storage_migration_message_models)
       (ir.config_parameter: cloud_storage_migration_all_models)
    4. not used by documents.document
 
optional configurations to avoid timeout issues
- cloud_storage_migration_max_file_size:
  max bytes for each migrated attachment
- cloud_storage_migration_max_batch_file_size:
  max total bytes for migrated attachments in one cron job execution

The cloud_storage_migration_min_attachment_id which can be accessed
from the list view can be treated as the progress of the cron job.
Manually setting it to 0 and retriggering the cron job will retry the
upload process for previously failed or ignored attachments.

taskid: 5387110


Steps

1. install a cloud storage module (cloud_storage_google, cloud_storage_azure)
2. install the cloud storage migration module (cloud_storage_migration)
3. Go to Settings for Cloud Storage Settings <img width="505" height="206" alt="image" src="https://github.com/user-attachments/assets/d72d7b52-5ce7-4209-8645-4a8ac35dd049" />
4. [Configure the cloud storage settings](https://www.odoo.com/documentation/19.0/applications/general/integrations/cloud_storage.html)
5. Setting the Minimum File Size. Attachments smaller than the size won't be uploaded to the cloud storage <img width="457" height="96" alt="image" src="https://github.com/user-attachments/assets/8dc4e6fe-9c84-44f5-a83a-28c7b2fad30a" />
6. After 4, configure settings for the cloud storage migration 
&nbsp;&nbsp; a. <img width="464" height="209" alt="image" src="https://github.com/user-attachments/assets/37352453-ff0e-4e03-a4d5-7fdb8168dee1" />

&nbsp;&nbsp; b. Cron Job:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. the link to the cloud storage migration cron job
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ii. the cron job is designed to be a job only triggered by clicking "Run Manually".
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iii. It will re-trigger itself until all relevant attachments are migrated.

&nbsp;&nbsp; c. Parameters:
<img width="882" height="571" alt="image" src="https://github.com/user-attachments/assets/9926ed9f-81ac-4917-b759-872ed2584217" />

&nbsp;&nbsp; d. Progress Bar:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i.progress of the migration job
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ii. calculated by `cloud_storage_migration_min_attachment_id / cloud_storage_migration_max_attachment_id`

&nbsp;&nbsp; e. Attachment Report:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. <img width="1907" height="298" alt="image" src="https://github.com/user-attachments/assets/33a77835-c6b6-4bc4-b20a-4ec68acba783" />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ii. a view to help administrator analyze which model's attachments should be migrated

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iii. help to configure step 6.c.i.4 and step 6.c.i.5

&nbsp;&nbsp; f. Message Attachments
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. help to configure step 6.c.i.4

&nbsp;&nbsp; g.All attachments
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. help to configure step 6.c.i.5


7. Click Cron Job and then Click Run Manually 
<img width="409" height="123" alt="image" src="https://github.com/user-attachments/assets/f60cdfcf-e6a6-4503-87fc-0be7f14ceede" />




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

step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

### Issue:
In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised:
```
Odoo Warning
You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed.
```

### Steps to reproduce:
- Create a product tracked by quantity
- Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point)
- Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1)
- Click on Order
- Open the created MO and the Shop Floor (Remove the filters to see the WO)
- Complete the Quality Point
- Modify the Reordering Rule (Min/Max: 2)
- Click on Order - the error should be raised

### Cause:
The MO to update is retrieved here:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153

In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked

In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: 67c2127
However, it could still theoretically be triggered under specific conditions

In 19.0, the new stock.reference system (odoo/odoo#212679) ensures the MO is detected as different, so a new one is always created

opw-5012588
enterprise: https://github.com/odoo/enterprise/pull/101313

### Steps to reproduce:

- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
    - Final Product (FP) with an empty bom
    - By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination

### Cause of the issue:

Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.

### Note:

The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f

opw-5350222

Forward-Port-Of: odoo/enterprise#101087

When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.

When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.

Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.

In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.

#### speedup

In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.

In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.

opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753

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

In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an Access Error when trying to open an invoice. Among the Accounting groups, only  *Accounting / Read-only* does not inherit from *Accounting / Invoicing*, which means that only the users in *Accounting / Read-only* could not access the invoices.

By granting read rights to both *Accounting / Invoicing* and *Accounting / Read-only*, we ensure that any user belonging to an Accounting group can see the invoices from the Veri\*factu module.

### Steps to reproduce:
1. Install *Accounting* (`accountant`) and *Spain - Veri\*Factu* (`l10n_es_edi_verifactu`).
2. Go to Settings > Users & Companies > Users and select a user.
3. In the *Access Rights* tab, set the user's *Accounting* access right to *"Read-only"*.
4. Log out, then log back in as the user selected in step 2.
5. Go to Accounting > Customers > Invoices and select any invoice.
6. An access error pops up.

opw-5343391

Forward-Port-Of: odoo/odoo#238291