**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#239851

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

### 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

When users would follow the following step as they are makeing a private task,  they would be hit by an incorrect access error.

Steps to reproduce:
1.Open the form view to create a new task.
2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task.
4.Create the private task.
5.An access rights error occurs, stating that the user does not have permission to create the record.

⚠️ Note:
This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs.

Root cause:
When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation.

This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users.

Fix (implemented):
Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing.
To address this, we now require at least one user to be assigned to a task when it is not attached to a project.  This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record


Versions : 17.0 -> master
Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#242216

When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env.

In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle.

Steps to reproduce:
1. Configure Odoo with a PostgreSQL primary/replica setup.
2. Open a website in edit mode.
3. Trigger an asset regeneration (for example by changing a theme color).
4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle.

Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env.

opw-6034833

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

Forward-Port-Of: odoo/odoo#255530

There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in account_tax.py.

After 18.0, the tax-included behavior is controlled through the `price_include_override` field instead of `price_include`. However, this field was not added in the forbidden fields, allowing users to modify tax inclusion while a POS session is open.

This bypasses the safeguard and can lead to inconsistencies, as the POS caches tax configuration at session start.

For example, changing this setting mid-session may differences between POS receipts and backend invoices.

By adding `price_include_override` to the forbidden fields,
the UserError can properly be raised.

Additional note: test_fiscal_position_between_frontend_and_backend was updated to close the POS session before changing taxes since the safeguard now correctly blocks this.

Related ticket: opw-6042367

Forward-Port-Of: odoo/odoo#254487

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

**Steps to reproduce:**
* Install the *Manufacturing (`mrp`)* module.
* Enable *developer (debug) mode*.
* Open the *Shop Floor* interface.
* Select  work center as `Assembly 1`
* In the bottom-right corner, click the *gear icon*.
* Select **Move to Work Center** from the  *gear icon*.

**Observed behavior:**
* A traceback occurs when opening the *Move to Work Center* dialog.
* The following Owl error is raised: 

`OwlError: Invalid props for component 'MrpWorkcenterDialog': 'loadWorkcenters' is missing (should be a function)
    Error: Invalid props for component 'MrpWorkcenterDialog': 'loadWorkcenters' is missing (should be a function)`

**Cause:**
* `MrpWorkcenterDialog` is opened in *two different ways*:

https://github.com/odoo/enterprise/blob/7805022e77ff80a74563b7ff0032d8975c00b709/mrp_workorder/static/src/mrp_display/mrp_display.js#L469-L480

  * One caller opens the dialog and provides `loadWorkcenters`.
    In this flow, the dialog fetches work centers by calling this
    function.

https://github.com/odoo/enterprise/blob/7805022e77ff80a74563b7ff0032d8975c00b709/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L68-L76

  * Another caller opens the dialog and directly provides a
    `workcenters` list. In this flow, the dialog already has the data
    and does not need `loadWorkcenters`.

* Therefore, the real behavior is that `loadWorkcenters` is only
  required *sometimes*, not always.

* However, the component props defined it as mandatory:
  `loadWorkcenters: { type: Function }`

* In *debug mode*, Owl strictly validates component props by comparing
  what the component declares in `static props` with what the caller
  provides. When the dialog is opened without `loadWorkcenters`, Owl
  detects that a required prop is missing and raises an
  *Invalid props* error.

**Fix:**
* Mark `loadWorkcenters` as *optional* in the component props so the
  dialog works correctly in both supported flows:
  * Lazy loading of work centers via `loadWorkcenters`.
  * Using preloaded `workcenters` data.

---

opw-6010261

Forward-Port-Of: odoo/enterprise#110361