**Steps to reproduce**
- Create a database in v18.0.
- Install the stock and sale modules.
- Create a storable product.
- Add 100 units as on-hand quantity using an inventory adjustment in the internal location (e.g., WH/Stock).
- Create a transit location.
- Create an internal transfer and move 20 units from the internal location (WH/Stock) to the Transit location.
- WH/Stock now contains 80 quantities.
- Transit location contains 20 quantities.
- See stock valuation of product.

**Issue**

- In v18, `value_svl` and `quantity_svl` are computed from [Stock Valuation Layers](https://github.com/odoo/odoo/blob/18.0/addons/stock_account/models/product.py#L213) After that, `total_value` is calculated using the formula [`avg_cost * qty_available`](https://github.com/odoo/odoo/blob/18.0/addons/stock_account/models/product.py#L205). However, when calling `qty_available`, no location context is passed to specify which locations should be considered. Because of this, `qty_available` only considers quantities from internal locations. As a result, the final `total_value` is computed based only on the internal location quantity (80).

- When the customer migrates the database to v19, the displayed `total_value` changes. In v19, both (100 qty) internal and transit locations are considered when computing the quantity used for valuation. This happens because a valuation [context](https://github.com/odoo/odoo/blob/19.0/addons/stock_account/models/product.py#L203) is passed when selecting the locations for the quantity computation. Due to this change, the quantity used in the calculation includes both internal and transit locations, which can lead to a different `total_value` being displayed compared to v18.

**Solution**

- To resolve this issue, the valuation context has been passed when computing the value in the function. This context includes both internal and transit locations. As a result, when `qty_available` is computed, it considers these locations, and the resulting `total_value` remains consistent with the valuation logic.

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

Forward-Port-Of: odoo/odoo#254120

### Issues:

The customer stock.lot.report is not well behaved with respect to multiple partial returns which can lead to returned lots that are not correctly flagged as returned and to duplicate records.

### Steps to reproduce:

- Create a product tracked by SN and put 3 units in stock SN1, SN2, SN3
- Create, confirm and validate a delivery for these two units for Bob.
- Click Return, return 1 unit and validate the return for the SN1
- Click Return, return 1 unit and validate the return for the SN2
- Open the contact form of Bob > Lots serial numbers smart button
#### > There are two lines referring to SN2 both are flagged as un-returned

### Cause of the issue:

In order to determine if a lot has been returned the `stock.lot.report` joins the stock_move_line table with it self based on picking and returns of these:
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock/report/stock_lot_customer.py#L48-L71 Records are then grouped to represent single move lines and a move line is expected to be returned to be returned if it is related to at least one move line on a return of its picking sharing the same lot related data (see the definition of `has_return`):
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock/report/stock_lot_customer.py#L22-L34 Now the issue is that the group by close actually group records based on the `sml_return.id`:
https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock/report/stock_lot_customer.py#L73-L89 which does not make sense since we expect to aggregate `sml_return.id`'s to compute the `has_return` field and since we do not want a move line of the original delivery to appear twice simply because it is linked to two returns one with and one without returned move line.

opw-5974155

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

Forward-Port-Of: odoo/odoo#256396

[FIX] website_profile, gamification: fix weekly/monthly leaderboards

Prior to this commit, the leaderboard pagination logic was flawed when
filtering by specific time periods (e.g., "This Week" or "This Month").

The system would first retrieve users sorted by their *all-time* global
karma, apply pagination (taking the top X users), and only then calculate
the karma gain for the specific period for those few users.

This caused users with high recent activity but low all-time karma to only
be displayed much later in the page order than they should.

This commit fixes the issue by introducing a pre-search step that
calculates the karma gain for the requested period at the database level.
Pagination is now applied to this specific result set, ensuring users are
correctly ranked by their actual performance during that week or month.

Note: A new method `_get_users_by_tracking_karma_gain` was added to
`res.users` to handle this logic. This approach was chosen to strictly
preserve the signature of existing methods for the stable version.
A distinct refactor to unify these calculation methods is planned for
the master branch.

Steps to reproduce:

- Install the eLearning module.
- Create a few users with different karma_points (more than 25 to have 2 pages).
- Go to /profile/users.
- Group by week.
- Paginate, and you will notice that the order is wrong; the first user on the second page might have more points than users on the first page. Also, when the logged-in user is not on that page, they do not appear at the bottom.

task-5344657
opw-3979785

Forward-Port-Of: odoo/odoo#256908
Forward-Port-Of: odoo/odoo#176626

Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.

Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.

See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/

Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.

Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear

task-6013408

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

Forward-Port-Of: odoo/odoo#253293

The fix introduced in https://github.com/odoo/odoo/pull/216737 can lead to "over-eager" filtering when an external email address matches a localpart (left part) alias in a input email list contains internal emails (aliases to filter) AND external email addresses (should not be filtered).

The `_find_aliases` method is used to identify internal system emails (aliases, bounces, catchalls) to prevent mail loops and ensure correct recipient filtering during notification grouping.

Before this fix, when the `mail.catchall.domain.allowed` system parameter was set, the logic for local-part aliases (where `alias_incoming_local` is True) failed to correctly associate the local part with the allowed domains. This resulted in external email addressed being returned by the system, potentially leading to incorrect notification routing.

We now use a more robust approach:
- Pre-filter local parts based on the allowed domains to reduce DB load.
- Utilize Python Sets for O(1) lookups of static and local aliases
- Explicitly validate the (local_part, domain) combo during the final filtering.

Example Scenario:
- Config: mail.catchall.domain.allowed = "test1.com,test2.com"
- Alias: "info" (alias_incoming_local=True)
- Input: ["info@test1.com", "info@test3.com"]

### Output Before Fix:
["info@test1.com", "info@test3.com"]
(The function failed to recognize info@test3.com as an external alias to be ignored based on the `mail.catchall.domain.allowed` config)

### Output After Fix:
["info@test1.com"]
(Correctly identifies the internal alias tob filtered while ignoring the external one)


OPW-5469264
OPW-5504201

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

Forward-Port-Of: odoo/odoo#244272

**Issue:**
- When opening the full composer from the chatter, the body of the default email
template is not loaded. Only the subject line from the template appears,
while the body remains empty or contains only the user's signature.

**Steps to reproduce:**
1. Install `contact`
2. Open any contact form.
3. In the chatter, click 'Send message' and then expand button
4. Write a something in body, then save this as a new template.
5. Set this new template as the default (using Debug Mode > Set Default Values).
6. Click 'Send message' in the chatter,
7. Click the 'Full composer' (expand) button without typing anything.

**Observed behavior:**
- The full composer opens with the correct subject from the default template,
but the body is empty.

**Cause:**
- The `onClickFullComposer` method always passes a `default_body` value
in the context to the mail.compose.message wizard. Even if the chatter input is empty

**Solution:**
- Forward isBodyEmpty in the context from onClickFullComposer.
If the user typed content, do nothing. If the body is empty and a default template is available,
allow the backend to apply the default template by removing default_body.

opw-5405056

Forward-Port-Of: odoo/odoo#254735
Forward-Port-Of: odoo/odoo#239851

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112566