The auto column conversion should be limited to simple and intuitive use cases. It shouldn't trigger the slow ORM recomputation if the field is computed. We always expect an upgrade script to handle more complex use cases.

This commit introduces two changes:

### 1. Removal of `drop_not_null` during auto column conversion
Before https://github.com/odoo/odoo/commit/50767ef90eadeca2ed05b9400238af8bdbe77fb3 We dropped the not_null constraint because the original column would be renamed. After that commit, we actually don't need to drop the not_null constraint since the `convert_column` will neither convert a not-null value to `null` nor convert 'null' to a not-null value. Keeping the not_null constraint shouldn't block the column convert.

### 2. Removal of `column.clear()` 
When a computed/related Float field is changed from `digits=None` to `digits='xxx'`, the `column.clear()` will trigger ORM recomputation during upgrade which is useless since `double precision` to `numeric` is lossless. The recomputation in ORM is slow and should be avoided. If the rerounding is really needed, a sql script is required for upgrade or installation.

The `column.clear()` was originally introduced to avoid `Missing not-null constraint` warnings in specific scenarios:
Case 1 (Upgrade Warning): from saas-18.4 to 19.0
old database: Selection field `l10n_be.export.sdworx.leaves.wizard.reference_year` upgrade: pre-migrate `util.rename_model(cr, "l10n_be.export.sdworx.leaves.wizard", "l10n.be.hr.payroll.export.sdworx")` new database: Integer field `l10n.be.hr.payroll.export.sdworx.reference_year` The column value which was a required stringified integer is auto-converted to an integer.
Case 2 (Installation Warning):
In pos_urban_piper, the required field `pos.config.name` is overridden from `translate=False` to `translate=True`. The column value which was a required text is auto-converted to `'{"en_US": "text"}'::jsonb`

The not_null constraint was previously lost by the `sql.drop_not_null` in `update_db_column` and is not restored by `update_db_notnull` because of the inconsistency between the variable `column['is_nullable']` and the actual not_null constraint in the database.

Thanks to change 1, we will no longer lose the not_null constraint in `update_db_column`. The constraint can be kept even without `column.clear()`.

By removing the `column.clear()`, we also revert the meaning of the `column` variable, which is the column's configuration (dict) before `update_db` if it exists, or `None`

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

During the rework of the follow-up report, we removed the
"No Follow-Up" field from journal items, making it impossible to exclude
individual journal items from triggering a follow-up.

In this commit we do the following:
-  Re-introduce a field for that, since it is a common
   requirement to be able to exclude individual items from the follow-up
   reports.
   The field is stored on the journal item, but can also be toggled from
   the journal entry. In case of multiple installments on the invoice,
   toggling the field on one installment will toggle it for all
   installments.
-  Adapt the Follow-Up Report and Customer Statement variants of the
   Partner Ledger to add a toggle for the "No Follow-Up" field on each
   report line, that toggles the field on the corresponding journal
   item(s).
-  Prevent the follow-up status on the partner to change when all of the
   overdue journal items are marked as "No Follow-Up".
-  Make sure users can toggle the "No Follow-Up" setting on the invoice
   level when opening the "Overdue Invoices" view from the partner's
   "Accounting" tab.
-  Make sure all receivable/payable lines without a due date (either
   from a manual miscellaneous entry or a PoS entry) are put under the
   "Due" section in the Follow-Up Report instead of the "Overdue"
   section. Since there is no due date, they can't be overdue.
-  Make sure the PDF and XLSX exports of the Follow-Up Report don't
   include the "No Follow-Up" lines, and the customer follow up email
   only includes the amount of the other lines.

Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9
and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615
Task: 5138378

Upgrade PR → https://github.com/odoo/upgrade/pull/8864

Forward-Port-Of: odoo/enterprise#96627

### Issue

Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).

### Analysis

Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.

### Solution

Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.

For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.

### Benchmarks

Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types

| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |

### References

opw-5130725

Problem
--------

In v18.0, the day billing period was removed from the sale.subscription.plan model.

For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance.

However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value.

- Screenshot Order with plan Daily: 
<img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" />

- Screenshot when trying to get in order on the website: 
<img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" />


Proposed Solution
--------

This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list.

The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection).

This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance.

- 
<img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" />