## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:

1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />

## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
    - Any name
    - Model: *Contact*
    - Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**

## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.

https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17

related: https://github.com/odoo/enterprise/pull/115492

opw-6219824

Forward-Port-Of: odoo/odoo#265163

## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />

## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
    - Any name
    - Model: *Contact*
    - Rule:
        - Field to Clean: *Name (Contact)*
        - Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**

## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:

https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23

This causes the IDs to be summed up and appear in the group headers.

## After

<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />

related: https://github.com/odoo/odoo/pull/265163

opw-6166623

Forward-Port-Of: odoo/enterprise#115492

Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased.

For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`.

However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision.

This is inconsistent with sales: sale order lines preserve very small unit prices correctly.


**Current behavior before PR:**

A product with `standard_price = 0.001235` keeps that value on the product form.

When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost.

The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line.

**Desired behavior after PR is merged:**

Purchase order lines preserve the computed unit price precision, just like sale order lines already do.

A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision.

---

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

Forward-Port-Of: odoo/odoo#269413
Forward-Port-Of: odoo/odoo#267941

# How to reproduce
- Create an Event registration
- Add a follower
- Click on the enveloppe icon next to the sender's name in the chatter

# The problem
A traceback appears

# Cause of the issue
When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105

But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing :
https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27

opw-6178443

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

Forward-Port-Of: odoo/odoo#265263

Steps to reproduce:
1. Install Knowledge.
2. Create an article.
3. Open the more actions menu.
4. Click "Add Cover".
5. Upload a cover image.

Issue:
- The upload crashes with the following traceback:
`Uncaught Promise > this.props.setAbortUploadsCallback is not a function`

Cause:
- `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop.

Solution:
- Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded.

Alternative approach: 
- Make ImageSelector tolerate callers that do not provide
  setAbortUploadsCallback by calling it with optional chaining.

opw-6176716

Forward-Port-Of: odoo/enterprise#120467
Forward-Port-Of: odoo/enterprise#116906

When setting the done state on an already done WO, a traceback is raised.

Steps to reproduce the error:

- Install ``mrp_workorder`` module with demo data
- Go to Manufacturing > Open any confirmed MO >
  In Work Orders Tab, Set the status to Done, again set the status to Done

Traceback:
```py
UnboundLocalError:
cannot access local variable 'wo' where it is not associated with a value
```

As long as the MO is not in the done state,
the dropdown for the workorder status remains visible,
allowing users to mark an already done WO as done again.
In this case, the WO is not added to "ids_to_update" list at [1],
so ``action_mark_as_done`` is called on an empty workorder recordset at [2],
For ``self`` containing no records, ``wo`` is never defined,
leading to the above traceback from the following line. https://github.com/odoo/enterprise/blob/3c4f44f316625f3315d176adfad5e1f1a6bea00a/mrp_workorder/models/mrp_workorder.py#L842

[1]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L168-L176
[2]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L184-L185

sentry-7477198216

When setting the done state on an already done WO, a traceback is raised.

Steps to reproduce the error:
- Install ``mrp_workorder`` module with demo data
- Go to Manufacturing > Open any confirmed MO >
  In Work Orders Tab, Set the status to Done, again set the status to Done

Traceback:
```py
UnboundLocalError:
cannot access local variable 'wo' where it is not associated with a value
```

https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/static/src/components/wo_list_view_dropdown/wo_list_view_dropdown.xml#L4-L5
In the commit [1], condition was changed from ``state`` to ``production_state``.
``production_state`` is the related to the state of MO,
So, as long as the MO is not in the ``done`` state, the dropdown remains visible,
allowing users to mark an already done WO as done again.
In this case, the WO is not added to ``ids_to_update`` list at [2].
so ``action_mark_as_done`` is called on an empty workorder recordset at [3],
leading to the above traceback from following line https://github.com/odoo/enterprise/blob/3c4f44f316625f3315d176adfad5e1f1a6bea00a/mrp_workorder/models/mrp_workorder.py#L842

[1]: https://github.com/odoo/odoo/commit/5b1197647b558eacd501fdd816056cfd56f45ced
[2]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L168-L176
[3]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L184-L185

sentry-7477198216

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

This commit ensures product images follow their visual order in the
product image viewer when using the grid layout.

Steps to reproduce:
- Open a product page with multiple images (or add Extra Media to the 
  product)
- Change layout mode to "Grid" and click save
- Click any image to open the product image viewer
- Navigate between images

Images do not follow the visual left-to-right order. This regression was
introduced by [commit], which replaced the row-based grid with a
column-first layout. As a result, `querySelectorAll` returns images in
DOM order, which no longer matches the visual order.

To fix this, images are now reordered based on their visual placement in
the grid so navigation matches the order seen by the user. Images are
traversed in visual left-to-right order while also accounting for
varying image heights and multi-column alignment.

[commit]: https://github.com/odoo/odoo/commit/9a3628b9735550bf8ecc2252ea1b7338f68ab966
task-[4364143](https://www.odoo.com/odoo/project/974/tasks/4364143)

Forward-Port-Of: odoo/odoo#270732
Forward-Port-Of: odoo/odoo#254077

Currently, an error will occur when user multi edits name of projects.

Steps to replicate:
- Install `project` and open projects.
- From the list view select multiple projects and edit their name.

Error:
```
File '/home/odoo/src/odoo/saas-19.3/addons/project/models/project_project.py', line 754, in write
    analytic_account_to_update.write({'name': self.name})
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py', line 1728, in __get__
    record.ensure_one()
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 5341, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: project.project(8, 9, 10)
```

Cause:
- As multiple records were changed at the moment, `self` had multiple recordsets and trying to access `self.name` [1] causes this error.

Solution:
- Avoided accessing `self.name` on a multi-recordset during multi-edit.
- Updated analytic account names using the name recieved in the vals.

For test_orm changes:
- Added these fields to the translated field write whitelist to explicitly mark this usage as supported as both the fields are translated.
- Copied `field_names` so that removing values during the test does not mutate the original whitelist.


[1]: https://github.com/odoo/odoo/blob/a69ec43f490735f639292d116b0207182c5b2581/addons/project/models/project_project.py#L608

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

Forward-Port-Of: odoo/odoo#269830
Forward-Port-Of: odoo/odoo#267620

This commit does not bring native support for EPD on credit notes, only makes custom support a little easier and cleaner.

It is quite easy to support EPD (early payment discounts) on refunds by extending
- `_early_payment_discount_move_types`
- `_is_eligible_for_early_payment_discount`

However, this approach breaks when it reaches `inverse_tax_rep` in `_get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line`, which assumes tax repartition lines with `document_type == 'invoice'` and raises when called on `tax_rep` lines of 'refund' type instead.

This commit fixes that by selecting source and target repartition lines according to the `tax_rep`'s document type, which ensures:
- the `.index()` no longer raises a `ValueError`, as `tax_rep` is now looked up in the matching set (`refund_` for refunds, `invoice_` otherwise)
- `inverse_tax_rep` returns the corresponding line in the opposite set, preserving the original invoice->refund mapping while adding the refund->invoice one

Since `inverse_tax_rep` is a closure, downstream modules cannot patch it without copying the whole ~170-line method. Making it symmetric here lets custom EPD-on-refund support work without that duplication.

task-[6265601](https://www.odoo.com/odoo/all-tasks/6265601)

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

Forward-Port-Of: odoo/odoo#271102

## Description

When loading demo data from **Settings** after installing `l10n_in` without demo data, the `_install_demo` method receives company IDs instead of a `res.company` recordset.

As a result, the following line crashes:

```python
companies.filtered(...)
```

with:

```text
AttributeError: 'int' object has no attribute 'filtered'
```

This PR ensures that the received company IDs are converted into a `res.company` recordset before being processed, allowing demo data to be loaded successfully from the Settings menu.

## Steps to Reproduce

1. Install `l10n_in` **without demo data**.
2. Navigate to **Settings**.
3. Click **Load Demo Data**.

## Current Behavior

Demo data installation fails with:

```text
AttributeError: 'int' object has no attribute 'filtered'
```

## Expected Behavior

Demo data should be installed successfully without raising any exception.

## Solution

Convert the received company IDs into a `res.company` recordset when the argument passed to `_install_demo` is not already a recordset.

Forward-Port-Of: odoo/odoo#270523

When a Time Off Type is created, it inherits the country of the current company. If there are leaves or allocations created from this Time Off Type and the company's country is then changed, various parts of Time Off will throw access errors as the leaves and allocations are still tied to the former country. The goal of this PR is to constrain
the company country from being changed unless there are no such leaves or allocations.

**Steps to Reproduce on Runbot:**
1. Ensure the current company has a `country` set, e.g. "My Company (San Fransisco)" has country set to "United States". 
2. Access Time Off as Mitchell Admin.
3. Create a new Time Off Type, for simplicity's sake without a need for allocation or approval, ex: "Gone Fishing". Note this Time Off Type will have the `country` set to the company country by default. 
4. Take "Gone Fishing" time off. 
5. Change or set blank the company's `country` value. 
6. Ensure the record rules cache is flushed.
7. Try to access Time Off. 

opw-6206359, opw-6140496

closes #263950

Forward-Port-Of: odoo/odoo#270270
Forward-Port-Of: odoo/odoo#263950

Steps to reproduce:
===================
1. Edit a job page.
2. Delete every `s_rating` block.
3. Save.

=> Validation Error: Document is empty.

Cause:
======
Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does
`html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving.

The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1])
added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path.

Solution:
=========
Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed.

[1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529

opw-6244892

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

Forward-Port-Of: odoo/odoo#270466
Forward-Port-Of: odoo/odoo#267397