To reproduce:
=============
- Create an accrual plan:
    - Carryover date: allocation
    - One level:
        - Accrues 2 days.
        - Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
    - Starts on 01/07/2024

we should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.

Problem:
========
we loop on each month in the allocation period to compute the accrued days when we reach the carryover date (01/07/2025) we set the expiring_carryover_days to the number of days accrued until that date which is 22 as we didn't yet add the days for June 2025, it's done after.

Solution:
=========
add additional accrued days when setting expiring_carryover_days on carryover date.

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

**Description of the issue/feature this PR addresses:**
Setup a model with a computed definition record field, like so:

```py
    properties_company_id = fields.Many2one(
        compute="_compute_properties_company_id",
        comodel_name="res.company",
    )

    @api.depends("company_id")
    @api.depends_context("company")
    def _compute_properties_company_id(self):
        for item in self:
            item.properties_company_id = item.company_id or self.env.company
```

Use this in a `Properties` definition:

```py
    properties = fields.Properties(
        definition="properties_company_id.properties_definition",
    )
```

Then simply try to export the model.

**Current behavior before PR:**

```python-traceback
Traceback (most recent call last):
  File "/odoo/src/odoo/odoo/http.py", line 2166, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/odoo/service/model.py", line 156, in retrying
    result = func()
             ^^^^^^
  File "/odoo/src/odoo/odoo/http.py", line 2133, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/odoo/http.py", line 2381, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/addons/web/controllers/export.py", line 400, in get_fields
    exportable_fields.update(self._get_property_fields(fields, model, domain=domain))
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/addons/web/controllers/export.py", line 321, in _get_property_fields
    field_to_get = Model._field_to_sql(Model._table, definition_record, self_subquery)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/odoo/models.py", line 2973, in _field_to_sql
    return model._field_to_sql(alias, field.name, query)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/odoo/src/odoo/odoo/models.py", line 2976, in _field_to_sql
    raise ValueError(f"Cannot convert {field} to SQL because it is not stored")
```

**Desired behavior after PR is merged:**
Should not fail.


With this commit, the code fallbacks to export all properties defined, even those that are not used among the exported records.


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

## Issue:
On Safari, the Apply and Dismiss buttons of the LinkPopover did not trigger their actions In some cases, it seemed to work only because a temporary link was not properly cleared
The Link Type Selection was also broken by the same bug

## Cause:
Safari triggers a `pointerdown` event through the `LinkPopover`, which changes the `selection` and calls the `handleSelectionChange()` method https://github.com/odoo/odoo/blob/e43135e94bf22bc2f7a115c37e8a082f96871ed0/addons/html_editor/static/src/main/link/link_plugin.js#L672-L678
At that point, `documentSelection` is `null`, causing the overlay to close before the `onClickApply()` on the Apply button
It's the same issue with the Dismiss button and the Link Type Selection

## Steps to reproduce:
- Install mail to get access to an html_editor
- Enable debug mode
- Go in Email Templates and open one of them
- Select a text and open link tools
- Add Odoo.com and click on Apply
- The link may seems to be created (if it's the case, there is no preview)
- You can confirm that with the link type selector that closed the popover before the fix

opw-5115887

Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.

It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].

This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).

Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
    def _load_records_write(self, values):
        values.pop('active', None)
        super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804

task-2963840

(Follow-up of https://github.com/odoo/upgrade/pull/3829)

Forward-Port-Of: odoo/odoo#104836

The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker.

This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop.

For a specific customer (opw-5025162), this was the case.

Benchmarks:

| No. stock.picking | avg no. quality checks | peak memory before | peak memory after |
| ----------------- | ---------------------- | ------------------ | ----------------- |
| 25                | 20                     | 2771 mb            | 235 mb            |

opw-5025162

The TableSizeComputer.compute() method can return cells with incorrect cell indexes. This can result in the _addColumn function only adding a column to some rows in the report editor.

TableSizeComputer.compute() does not handle cases where a conditional is used inside of a th element but the corresponding td element does not have a conditional.

Steps to reproduce
-----
1. Open the Delivery Slip in the report editor.
2. Click the header to show the dropdown and select elif: o.move_line_ids and o.state=='done'.
3. Hover over the last th element to select the column button.
4. Click Insert right and see that only the header row has an additional column.

Cause
-----
TableSizeComputer.compute() calculates how many possible cells can be in a row which can be more than the total number of columns you have if you have th or td elements with a conditional inside of them.

In the Delivery Slip report, a th element is present when using serial numbers and a different th element is present when not using serial numbers. The corresponding t-body has two different tr elements for these conditions. The compute method will have one less cell in these rows because the corresponding conditional is handled outside of the row.

Solution
-----
Only count mutually exclusive th or td elements once. This prevents the cellIndex from being larger than the total possible columns.

opw-ticket 5173345

#### [FIX] account_peppol: disallow disabling services
Currently it is possible to disallow any services in the configuration.
This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0".

1. Ensure Peppol is activated (test mode or production; not demo)
2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services
3. Any service can be disabled.

This commit hides the button to open the service wizard.
(Also in the wizard it is now not possible to disable services anymore.)

#### [FIX] account: generation of print-related entries in cog menu
Before this commit:
The dynamic generation of the print related entries in the cog menu
does not work correctly.

Problem / Solutions:
There is a check in the javascript that does not work as intended.
Thus the entries are not added to the cog menu in all cases.
The check was intended to only block it for "new" records (not saved yet);
to avoid issues in case the move has no id yet.
After this commit we just check the id directly.

#### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format
Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce .
There we improved the eInvoice format labels for clarity.
But 2 label were formatted differently than the others.
This commit fixes that.

#### References
task-4737164