**Steps to reproduce:**
1. Log in as a portal user.
2. Open a shared project and then open any task within it.
3. Observe the vertical spacing above the Follow/Unfollow button and the chatter 
component.

**Issue:**
The chatter UI has incorrect vertical spacing, causing elements like the
Follow/Unfollow button to sit too far down and appear misaligned.

**Cause:**
The pt-2 padding class was hardcoded in two separate locations: 
1. The compileChatter wrapper in project_sharing_form_compiler.js.
2. The portal.Chatter XML template.
When combined this caused a double-padding effect forcing excessive space.

**Fix:**
Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and 
the core XML template. This eliminates the double-padding conflict. This resolves 
the alignment issue in Project Sharing and does not affect the layout or 
functionality of other portal components.

task-4203362

Forward-Port-Of: odoo/odoo#268977
Forward-Port-Of: odoo/odoo#257490

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

Forward-Port-Of: odoo/enterprise#119017
Forward-Port-Of: odoo/enterprise#118773

Steps to Reproduce:

* Create a Hungarian company on 19.0 (or earlier).
* Configure NAV credentials through Settings.
* Upgrade the database to saas~19.2.

Issue:

* The upgrade fails while reloading the Hungarian chart template.

```python3

Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1626, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 202, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 502, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 215, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 253, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu/migrations/3.1/end-migrate_update_taxes.py", line 7, in migrate
    env['account.chart.template'].try_loading('hu', company)
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 181, in try_loading
    return self._load(template_code, company, install_demo, force_create)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/template_hu.py", line 11, in _load
    company._l10n_hu_edi_configure_company()
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 79, in _l10n_hu_edi_configure_company
    res_config_id = self.env['res.config.settings'].create({
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/res_config_settings.py", line 39, in create
    return super().create(vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_config_settings.py", line 48, in create
    record.company_id._l10n_hu_edi_test_credentials()
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 107, in _l10n_hu_edi_test_credentials
    raise UserError(
odoo.exceptions.UserError: Helytelen NAV hitelesítő adatok! Ellenőrizze, hogy a cég adószáma helyesen van-e beállítva.
Hiba részletei: HTTPSConnectionPool(host='api.onlineszamla.nav.gov.hu', port=443): Max retries exceeded with url: /invoiceService/v3/tokenExchange (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x798a970f1fd0>: Failed to establish a new connection: [Errno 111] Connection refused'))
```

Cause:

* Since the introduction of the Hungarian tax migration using `account.chart.template.try_loading('hu', company)` in saas~19.1, upgrades reload the Hungarian chart template.
* When `l10n_hu_edi` is installed, chart template loading triggers `_l10n_hu_edi_configure_company()`, which performs NAV credential validation through `_l10n_hu_edi_test_credentials()`.
* The credential validation performs a live request to the NAV service, making the upgrade dependent on an external service. https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/res_company.py#L99-L109 https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/template_hu.py#L11

Fix:

* Bypass NAV credential validation during the migration.
* The migration only updates localization data and does not modify the configured EDI credentials.
* This prevents temporary NAV connectivity issues from aborting the upgrade process.

see https://github.com/odoo/odoo/pull/253556

opw-6253523
upg-4326247

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

Forward-Port-Of: odoo/odoo#268178

Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040.

Steps to reproduce:
-------------------
* Enable TicketBAI for a Spanish company with POS
* Create an order and complete payment (TicketBAI sent)
* Refund that order from the POS and complete payment
* Open the new TicketBAI XML (downloadable on the order in the backend)

> Observation:
`CabeceraFactura` `NumFactura` matches the original sale; tax authority returns 5040 (duplicate invoice for same issuer/series/year).

Why the fix:
------------
The TicketBAI document `name` was set from `pos.order.name`, so `_get_tbai_seq_from_name` extracted the same numeric part as the original sale. `l10n_es_edi_tbai.document` derives Serie/Num from `name` via `_get_tbai_seq_from_name`. Refund POS names intentionally echo the original order label, so we derive the document name from the same components as non-refund orders (`get_reference_last_part()`), which is unique per receipt.

opw-6067965

Forward-Port-Of: odoo/odoo#257475

Steps to reproduce:
---
- Install `website_sale`.
- Create a product and from the Sales tab, add alternative products, making sure all products are published on the website.
- Open the main product on the website.
- In the alternative products section, open the editor, click the `brush` icon under `card design`.
- Under Actions > Buttons, click on the `cart` icon.
- Save the changes and click the `Add to Cart` button on an alternative product.

Issue:
---
- Clicking the `Add to Cart` button on alternative products does nothing.

Root cause:
---
- At [1], the `AddToCart` interaction uses the selector `.oe_website_sale button[name="add_to_cart"]` to find and attach click handlers. When the dynamic snippet renders alternative products, `startInteractions` is called on the `.dynamic_snippet_template` div. It searches for the button inside that div, but at [2], no element wrapping the button has the `oe_website_sale` class in the rendered product card template. So the selector matches nothing, and no click handler is attached.

Fix:
---
- Add `oe_website_sale` to the `o_wsale_product_btn` wrapper div in the product card template so the button becomes a descendant of `.oe_website_sale` within the injected content, allowing the interaction to attach correctly.

[1]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/static/src/interactions/add_to_cart.js#L5
[2]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L95-L113

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

Forward-Port-Of: odoo/odoo#263253

## Issue
When scheduling a sign request, the request appears immediately on the portal for the requested signer.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Create and send a sign request
    - Signer 1: Any portal user (e.g., Joel Willis)
    - Use the clock icon to schedule the signature request to a future date
3. Log in as the portal user used in step 2
4. Navigate to Signature Requests
5. **The signature request already appears in the list, even though it was scheduled for a future date.**

## Cause
The portal filters the sign requests shown based on the `is_mail_sent` field, which does not properly reflect when the signature request is shared to the user.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/controllers/portal.py#L40

In fact, when scheduling a signature request, the `is_mail_sent` field is unconditionally set to `True`, even if the signature request will only be sent later.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request_item.py#L289

## Fix
Since the `"scheduled"` `sign_request_item.state` option introduced by https://github.com/odoo/enterprise/commit/ed8d5a653e01b1378f0020e2f7a7c2d39fadf3e9 in 19.1, we can easily filter out the sign request items that are scheduled. That state is automatically updated by the `_cron_update_state`, introduced by the same commit as the `"scheduled"` option.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request.py#L493-L503

opw-6227472

Forward-Port-Of: odoo/enterprise#118491

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

Forward-Port-Of: odoo/enterprise#119610
Forward-Port-Of: odoo/enterprise#118479

Steps to reproduce
---
1. Register a grouped customer payment over several invoices, leaving one of them only partially paid.
2. Register a second grouped payment over two invoices: the partially paid one and a brand new invoice.
3. Open the first payment, its "Reconciled Invoices" smart button now lists the new invoice from the second payment, which it never paid.

Issue
---
The smart button is built from the stored `invoice_ids` many2many, which shares its relation table with `account.move.matched_payment_ids`. After reconciling, the register wizard links the payment to its invoices with `lines.move_id.matched_payment_ids += payment` at https://github.com/odoo/odoo/blob/f726393267a28cedd5febd2106de17ae3838f3ff/addons/account/wizard/account_payment_register.py#L1212.

When the payment groups several invoices, `lines.move_id` is a multi-record recordset. Reading `matched_payment_ids` on it returns the union of the payments already linked to all those invoices, and `+=` writes that union back to every invoice as a `(6, 0, ...)` replace command. So an invoice already paid by an earlier payment spreads that earlier payment onto every other invoice grouped in the new one, including brand new invoices, which then wrongly appear on the earlier payment.

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

Forward-Port-Of: odoo/odoo#267968

### Issue:
In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled

However, these fields must only be used for EU countries

For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors

### Cause:
`_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries

As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU

Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create a customer in Switzerland with a valid VAT number
- Create and confirm an invoice for that customer
- Go to Accounting → Audit Reports → General Ledger
- Select the full year
- From the gear menu, export DATEV DATA (zip)
- Open the `EXTF_customer_accounts` file

### Before the fix:
`EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty

### After the fix:
`EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled

`Land` is filled using the following priority:
1. Partner country_code
2. Country extracted from the VAT number
3. Empty

opw-5902565

Forward-Port-Of: odoo/enterprise#119780
Forward-Port-Of: odoo/enterprise#113835

### Issue
Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns
The Return mechanism implies that you need a Return Type in order to make a Closing Entry using the Validate button

Additionally, using the Generic Tax Report by default creates a risk in Multi-VAT environments, as it mixes taxes from all countries instead of isolating Peruvian taxes

### Cause
The new 18.3 accounting workflow requires at least one active Return Type associated with a country-specific report variant to display the Return options and process the closing entry Peru was relying on the Generic Tax Report, without a dedicated report variant
No Return Type was configured, which blocked Odoo's automatic VAT closing workflow and prevented the system from prompting the user to configure the required closing accounts

### Steps to reproduce
- Install `l10n_pe_reports` and `accountant`
- Switch to a PE Company
- Go to the Tax Report

Before the fix, no Returns button is available for any of the existing reports, making it impossible to use Odoo's automatic process to configure the tax accounts and trigger the closing entry

### Notes
This is fixed by creating a dedicated Peruvian tax report variant directly in Enterprise that inherits from the generic tax report A custom handler is added to force the domain filtering on Peruvian taxes only, and a corresponding Return Type is defined to restore the full closing entry process safely

opw-5978673

Forward-Port-Of: odoo/enterprise#117891

**Issue**
Printing a credit note for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print -> The generated PDF displays "lot1" instead of "lot2"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 1` since the credit is on a quantity of 1 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80 which would make it as -1 (since `qties_per_lot[sml.lot_id]` is 0 for the first iteration of `sml.lot_id`). Thus, it does not pass by this code (since quantity is greater than 0): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L87-L90 which would make it as 0.
- for the last one, `is_stock_return = False` as it should be, thus the quantity is 1 as it should be. The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 0, lot2: 1}`

The report then selects the first matching lot and stops: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6230281

Forward-Port-Of: odoo/odoo#266716

Cause:
----------------------------------------
Commit 121806b57816d0fbd48b5538d2a8beae35905d99 added a test verifying that the duration in German is correctly recognized. In the test, "2 Std. 30 Min. 45 Sek.", was supposed to be recognized as 2.5125 hours. But on some browser versions it fails, as in the latest Chrome version.

This is because we use `DurationFormat()` to get the localized units. This method is supported by all browsers and will use the browser's data to get the translations. This data comes from [Unicode CLDR](https://cldr.unicode.org/) which is updated regularly.

We would need to change the test depending on the Chrome version, so we just delete it. It appears that for German hours the CLDR definitions have historically shifted between two distinct representations: "Std." and "h"

As an example:
- CLDR 47:
https://github.com/unicode-org/cldr-json/blob/16f6b8578ba5fe98959034706f337674f816fc3f/cldr-json/cldr-units-full/main/de/units.json#L3526-L3527

- CLDR 48:
https://github.com/unicode-org/cldr-json/blame/4d06be52b51bb2f75688d0abe55c52a66afed790/cldr-json/cldr-units-full/main/de/units.json#L3916-L3917


So the test fails in CLDR 48 but succeeds in CLDR 47.

As the latest version of `ICU` (used by browsers) updates its dependency to CLDR 48 ([src](https://unicode-org.github.io/icu/download/78.html)) this explains why the latest Chrome version makes the test fail.

runbot-939543

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#119772
Forward-Port-Of: odoo/enterprise#102864

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

Importing attendees on an event that has an `after_sub` mail scheduler (the default on every event) fails with `savepoint "..." does not exist` and the import is aborted.

[`_update_mail_schedulers`](https://github.com/odoo/odoo/blob/b2f3270271f6/addons/event/models/event_registration.py#L298) runs the attendee scheduler synchronously on every registration create. The scheduler commits after each mail batch, which is fine from cron but problematic during an import: since [29460b723f49](https://github.com/odoo/odoo/commit/29460b723f49) [`load`](https://github.com/odoo/odoo/blob/b2f3270271f6/odoo/orm/models.py#L884) uses a single savepoint for the whole run, and any commit underneath releases it, so the next `ROLLBACK TO` / `RELEASE SAVEPOINT` raises `InvalidSavepointSpecification`.

When `import_file` is in context, trigger the cron like the async path already does so the mails are queued instead of running inline.

Steps to reproduce:

0. Have Contacts and Events installed
1. Events > Events, create a published event
2. Open the event, Attendees tab > Favorites > Import records
3. Upload a file with new attendees (Name, Email, no external id)
4. Click Import

=> "savepoint ... does not exist", import fails

Ticket [link](https://www.odoo.com/odoo/project.task/6124741)
opw-6124741

Forward-Port-Of: odoo/odoo#267586
Forward-Port-Of: odoo/odoo#260648

## The Problem
When computing a future leave balance, `_get_future_leaves_on` triggers
`_process_accrual_plans`, which iterates period by period and calls
`_get_leaves_taken` at each step. `_get_leaves_taken` re-enters
`_get_consumed_leaves` with `ignore_future=True`, but other accrual
allocations on the same employee were not guarded by `precomputed_allocations`,
causing `_get_future_leaves_on` to fire again for each of them, launching
another full accrual run recursively. With N periods and K allocations,
total work grew as $O(N^K)$.

## The Solution
Adding `not ignore_future` to the guard prevents future projection in any
nested context where it is both semantically incorrect and the source of
the blowup.

---

## Benchmarks
*Tested on a customer database with an employee having 2 accrual allocations and
pending future leave requests 6 months out:*

| | Queries | Request Time | Improvement |
| :--- | :--- | :--- | :--- |
| **Before** | 220K | 145.0s | — |
| **After** | 2.7K | 2.8s | **-98%** |

**Note:** More optimizations could be done to reduce the queries to a constant. However given the current design, it would be a bit big change and the current performance is already acceptable.

**OPW-6115804**

Forward-Port-Of: odoo/odoo#261172

Steps to reproduce:
---------------------------------------
1. Install Studio and Project app with demo
2. Go to Project App > studio > views > enable calendar view > close studio
3. Click on any project

Observation:
---------------------------------------
A traceback appears:
```
Caused by: TypeError: Cannot read properties of undefined (reading 'toMillis')
    at get uniqueId (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:21370:74)
    at Many2OneAvatarEmployeeField.template (eval at compile (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:1387:421), <anonymous>:25:122)
```

Issue:
---------------------------------------
The traceback is yielded from the `get uniqueId` getter from the `Many2OneAvatarUserField` component:
https://github.com/odoo/odoo/blob/be8b1bbad757fda27df579ce36cbc97324f58f62/addons/mail/static/src/views/web/fields/many2one_avatar_user_field/many2one_avatar_user_field.js#L48-L50

where `write_date` is undefined. This getter was added by, https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4#diff-94c14c7d2a5fe89c7558f5dffbd6cd126bcba0b140e821ef317f25ac15eb9352 which handled the case of undefined `write_date` for the related Kanban component
https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/kanban_many2one_avatar_employee_field.js#L49-L52

For the Kanban record for User Avatar, a similar solution is applied in this problematic getter. https://github.com/odoo/odoo/pull/251000/changes/80b5e529304ad9a0bdaf55a49e64ac8097a0380a

Solution:
---------------------------------------
Handle missing `write_date` safely using optional chaining to avoid undefined errors

Similar fix applied for the employee avatar in https://github.com/odoo/odoo/pull/260069/changes/6658b41310106bb4e425ae537a1af6a8ed71f864

Note:
---------------------------------------
For `saas-19.3` It is solved in commit https://github.com/odoo/odoo/commit/8847084c14ae4e0595eed7e006c58e161ce450ea

opw-6210249

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119597
Forward-Port-Of: odoo/enterprise#118759

Opening the Inventory Valuation report iterated every storable product to compute total_value, which on large catalogs used several GB of RAM and timed out workers.

The report now searches only products that have stock (under the same valuation context that total_value uses) or that are lot-valuated, and feeds that smaller set into stock_value and stock_accounting_value. For historical (at_date) reports the search runs with to_date in context so qty_available is scoped to that date. _get_accounts_by_product() also switches to search_fetch so only categ_id is loaded upfront.

Benchmarks were measured on a customer database restore with ~360k storable products. After filtering, ~2.5k products feed into the valuation today and ~2.2k for a historical date.

Benchmark opening Inventory Valuation report (Accounting)
| Date       | Before | After  | Speed up |
|------------|--------|--------|----------|
| Today      | ~88s   | ~2s    | 41x      |
| Historical | ~245s  | ~173s  | 1.4x     |

The historical improvement is more modest because stock_value still has to compute total_value at the historical date for the remaining products, which traces SVL/stock.move history; the filter eliminates the dominant per-product overhead today but only the tail in the historical case.

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

Forward-Port-Of: odoo/odoo#265931
Forward-Port-Of: odoo/odoo#254010

A product can have expiration date (use_expiration_date) enabled after being changed from lot/serial tracking to no tracking (quantity).

The issue this causes is that it can open the expiration popup since from saas-18.4 there is a line where if `ml.removal_date <= datetime.datetime.now()` the picking is expired.

So, if the product previously met these conditions, it will still be able to enter this flow.

And since this product doesn't use a lot_id it displays “You are going to deliver the product False, False which is expired or should at least be removed from stock”

What should happen:
When a product is not tracked, use_expiration_date should be False as expiration dates are intended to be managed through lots or serial numbers.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
- Tracking: By Lots
- Use Expiration Date: enabled
- Set a value greater than 0 for removal_time
3. Change the product tracking to By Quantity.
4. Create and validate a receipt for the product.

Related Tickets: opw-6255673

Forward-Port-Of: odoo/odoo#268135