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

Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

When generating PDF reports with multiple records, the system tries to
split the concatenated PDF using outlines. In cases where the number of
outlines doesn't match the number of records or outlines are missing, it
falls back to generating individual PDFs per record.

Steps to reproduce:
- Create an invoice
- Add in terms section a couple of lines and a heading, so that the
  invoice span over multiple page and the heading will be positioned on
  a separate page
- Select multiple invoices, including the created one
- Download > PDF Without Payment
- Open the resulting merged PDF.

Issue: The final PDF contains duplicated pages.

Analysis: Because of the outline moved to the following page, the number
of outlines does not match the number of res_ids. This makes the
outlines structure not valid for splitting.  When the system falls back
to individual PDF generation, it successfully collected the individual
streams but also include the original bulk stream to the return value
that will be merged together, effectively duplicating the pages in the
final output.

opw-5394156

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

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

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

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

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

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.

### Steps to reproduce

1. Create an event with a paid ticket (e.g., 100 EUR).
2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR).
3. Open the event registration page.
4. The 100 EUR appears struck-through next to 80 EUR.

### Cause

Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts.

### Fix Rationale

A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount.

opw-5993477

**Steps to reproduce:**
* Install the **Stock** module with demo data.
* Create a delivery with quantity **N** and click **Mark as To Do**.
* Set the delivered quantity to less than the demanded quantity .
* Validate the delivery, with the creation of a **backorder**.
* Print the **Delivery Slip** report.

**Observed behavior:**
* Backorder lines appear **without units of measure**, while 
other lines correctly display their units.

**Cause:**
* The backorder line includes a **group restriction** that hides 
the unit unless the *Unit of Measure* setting is enabled.

**Fix:**
* Remove the group restriction so units of measure are 
always visible on backorder lines same as others.

<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/5f21139a-a4ab-4c39-8b16-3c68c94a163e" />
    After:
   <img src="https://github.com/user-attachments/assets/dd4de18b-dc2e-4686-8435-30864fe40aa4" />

</details>


---

> NOTE - This fix done after receiving confirmation from PO(dala)

---

opw-5265051

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