Behavior before:
Opening the inventory valuation report on databases with 300k+ products
(storable) caused an out-of-memory (OOM) error, making the report completely
unusable at this scale.

Behavior after:
The inventory valuation report loads successfully and efficiently for 300k+
products without any memory errors or RAM spikes.

Root Cause:
In `_get_accounts_by_product()`, querying all storable products creates a massive
recordset. When iterating through this recordset, the call to `_get_product_accounts()`
accesses various relational and property fields (like categories and accounts).
Because standard ORM prefetching was active, accessing these relational fields on the
first loop iteration triggered a massive batch-fetch for all 300k+ products in the
recordset simultaneously. This cascading prefetch overloaded the environment cache
and caused an immediate OOM crash.

Fix:
Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`.
This disables the greedy batch-loading behavior across the entire recordset. The ORM
now fetches the required relational accounting fields surgically, record-by-record
inside the loop, maintaining a minimal memory footprint and preventing the crash.

Benchmark:

| Products Count | Memory Before  | Memory After | Time Before | Time After |
|------------------------|-------------------------|----------------------|------------------- |----------------|
| 300k+                  | Memory Error     | 1.1. GB             | 46.63 s           | 1.9 m         |
| 200k                    | Memory Error     | 566.4 MB         | 1.2 m              | 1 m            |
| 100k                    | 873.1 MB             | 286.8 MB         | 36.74 s            | 32.15 s      |
| 50k                      | 442.1 MB             | 145.6 MB         | 18.96 s            | 17.65 s      |

opw-5462037



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

Steps to produce:
---
- Install `Sales` module.
- Go to `Sales > Configuration > Sales Orders > Quotation Templates`.
- Create a new template and add a section.
- In the section name, add text with line breaks using `Shift + Enter`.
- Go to sale orders > Create new SO > Set quotation template created above.

Issue:
---
- Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one.

Root cause:
---
- At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2].

Solution:
---
- Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered.

[1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96
[2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86

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

Forward-Port-Of: odoo/odoo#256058

Problem:
In RTL websites, the table row menu is not placed correctly.

Cause:
The `inlineStartOffset` calculation in `table_menu` depends on the
`direction` parameter, which was not passed during the editor
initialization.

Solution:
Ensure the `direction` parameter is properly passed during editor
initialization so the `inlineStartOffset` is computed correctly in
RTL layouts.

Before:
<img width="1091" height="682" alt="image" src="https://github.com/user-attachments/assets/964903b2-d33b-48aa-86c2-632cc5adac9a" />
After:
<img width="1093" height="658" alt="image" src="https://github.com/user-attachments/assets/846fd39c-1114-408d-a1f4-75b27218b9b0" />


Steps to reproduce:
- Change website language to Arabic.
- Add a text block and insert a table inside.
- Hover over the first table row.
- Observe the row menu is misplaced.

opw-6049260

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

Forward-Port-Of: odoo/odoo#256045

# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
	- Inactive Accounts
	- Account: 101401 (the code of the record)

 # The problem
 The record that we searched for is not shown

 # Cause
The domain for  the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147

And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159

This is correct and the search should return what we wanted, but the code's search is overriden by:

https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384

And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored

This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`

# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search

opw-6059404

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

Forward-Port-Of: odoo/odoo#256939
Forward-Port-Of: odoo/odoo#256060

How to reproduce :
- Create a product
- Create an attribute with a value set to "free text"
- Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name
- Put Dropship as the route for the product to create a PO on a SO confirmation
- Create a SO with that product
- Confirm the SO and go to the PO
- Change the vendor in the SO

The problem :
The Vendor Code and/or Vendor Name does not change correctly in the product description

Why :
The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user.

This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions.

It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method.

The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change.

opw-5888233

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

Forward-Port-Of: odoo/odoo#256665
Forward-Port-Of: odoo/odoo#247330

The AVCO audit report currently recalculates the AVCO value on outgoing moves. Based on the logic in `run_average_batch()`, it should instead use the AVCO value computed on the last ingoing move to recalculate the
`added_value`.                                                         

On the other hand, the `added_value` should not be recomputed from the AVCO value on ingoing moves.

Source of those changes: [245141](https://github.com/odoo/odoo/pull/245141)

Steps to reproduce the issue:
1. Create a new product. Do not assign it to a category yet.
2. Set the cost (standard_price) to 10$ on the product form.
3. Add 10 units to inventory.
4. Sell and deliver 5 units to a customer.
5. Purchase 10 units at 25$/ea and validate the receipt.
6. Sell and deliver 5 units to a customer.
7. Assign the product to category with AVCO cost method.
8. Go to the AVCO justification report:
    - The added value on the purchase is incorrect: 200$ instead of 250$.
    - On the last delivery: the added value is -125$ and the AVCO increases from 20$ to 25$.

Ticket: opw-5921104

Forward-Port-Of: odoo/odoo#252239

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#257050
Forward-Port-Of: odoo/odoo#242216

Currently an error is generated when the user tries to save a report with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow  `view.arch` to be empty. As a result, this error is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available.

[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

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#256009
Forward-Port-Of: odoo/odoo#255316

Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC

-> Nothing happens.

Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains  no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.

When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.

Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases

opw-5891054

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

Forward-Port-Of: odoo/odoo#254284
Forward-Port-Of: odoo/odoo#250050

Behavior before:
Opening the inventory valuation report on databases with 300k+ products
(storable) caused an out-of-memory (OOM) error, making the report completely
unusable at this scale.

Behavior after:
The inventory valuation report loads successfully and efficiently for 300k+
products without any memory errors or RAM spikes.

Root Cause:
In `_get_accounts_by_product()`, querying all storable products creates a massive
recordset. When iterating through this recordset, the call to `_get_product_accounts()`
accesses various relational and property fields (like categories and accounts).
Because standard ORM prefetching was active, accessing these relational fields on the
first loop iteration triggered a massive batch-fetch for all 300k+ products in the
recordset simultaneously. This cascading prefetch overloaded the environment cache
and caused an immediate OOM crash.

Fix:
Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`.
This disables the greedy batch-loading behavior across the entire recordset. The ORM
now fetches the required relational accounting fields surgically, record-by-record
inside the loop, maintaining a minimal memory footprint and preventing the crash.

Benchmark:

| Products Count | Memory Before  | Memory After | Time Before | Time After |
|------------------------|-------------------------|----------------------|------------------- |----------------|
| 300k+                  | Memory Error     | 1.1. GB             | 46.63 s           | 1.9 m         |
| 200k                    | Memory Error     | 566.4 MB         | 1.2 m              | 1 m            |
| 100k                    | 873.1 MB             | 286.8 MB         | 36.74 s            | 32.15 s      |
| 50k                      | 442.1 MB             | 145.6 MB         | 18.96 s            | 17.65 s      |

opw-5462037



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

Steps to produce:
---
- Install `Sales` module.
- Go to `Sales > Configuration > Sales Orders > Quotation Templates`.
- Create a new template and add a section.
- In the section name, add text with line breaks using `Shift + Enter`.
- Go to sale orders > Create new SO > Set quotation template created above.

Issue:
---
- Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one.

Root cause:
---
- At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2].

Solution:
---
- Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered.

[1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96
[2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86

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

Forward-Port-Of: odoo/odoo#256058

**Step to reproduce:**
- install "l10n_es_edi_verifactu_pos"
- setup "ePOS printer" for a pos
- open pos and settle a order below 400$
- notice we get l10n_es_edi_verifactu_qr_code in our receipt
- click on "Print receipt"
- repeat above steps for one more order

**Observation:**
- when we print the second order receipt, the QR still points to 1 order invoice

**Issue:**
- [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355
) was trimming query strings when generating cache keys. URLs like:
`  http://localhost:9000/report/barcode/?barcode_type=QR&value=... `
were reduced to:
`  http://localhost:9000/report/barcode/`

- As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders.

**Solution:**
Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly.

opw-5455807


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

Forward-Port-Of: odoo/odoo#251139

Problem:
In RTL websites, the table row menu is not placed correctly.

Cause:
The `inlineStartOffset` calculation in `table_menu` depends on the
`direction` parameter, which was not passed during the editor
initialization.

Solution:
Ensure the `direction` parameter is properly passed during editor
initialization so the `inlineStartOffset` is computed correctly in
RTL layouts.

Before:
<img width="1091" height="682" alt="image" src="https://github.com/user-attachments/assets/964903b2-d33b-48aa-86c2-632cc5adac9a" />
After:
<img width="1093" height="658" alt="image" src="https://github.com/user-attachments/assets/846fd39c-1114-408d-a1f4-75b27218b9b0" />


Steps to reproduce:
- Change website language to Arabic.
- Add a text block and insert a table inside.
- Hover over the first table row.
- Observe the row menu is misplaced.

opw-6049260

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

Forward-Port-Of: odoo/odoo#256045

How to reproduce :
- Create a product
- Create an attribute with a value set to "free text"
- Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name
- Put Dropship as the route for the product to create a PO on a SO confirmation
- Create a SO with that product
- Confirm the SO and go to the PO
- Change the vendor in the SO

The problem :
The Vendor Code and/or Vendor Name does not change correctly in the product description

Why :
The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user.

This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions.

It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method.

The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change.

opw-5888233

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

Forward-Port-Of: odoo/odoo#256665
Forward-Port-Of: odoo/odoo#247330

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#257050
Forward-Port-Of: odoo/odoo#242216

`has_published_products` was previously computed recursively. For recursive fields, the ORM disables prefetch optimizations.

In 3ffca1961cb1671e7028dd4dceca82d2e74a2e21, the computation switched to `_read_group` to avoid loading all published products into cache and prevent memory issues. However, this introduced an N+1 pattern when evaluating:
```python
categories.filtered(lambda categ: categ.has_published_products)
```

As a result, query count became dependent on the number of active categories, which broke SQL performance tests when demo data were installed.

This commit updates the computation again to avoid recursion and restore ORM prefetch optimizations, making the number of queries independent of the number of active categories.

This commit also removes redundant checks already enforced by ORM `ir.rule`. For example, the following pattern evaluates `has_published_products` three times: once in the user domain, once in the access rule domain added by `search`, and once in the filter.
    
```python
domain = [("has_published_products", "=", True)]
categs = self.env["product.public.category"].search(domain)
categs.filtered("has_published_products")
```

runbot-234948

Forward-Port-Of: odoo/odoo#256664
Forward-Port-Of: odoo/odoo#256415

**Steps to reproduce:**
- Install Mail Marketing app
- Change user language to a RTL language (such as Arabic)
- Create a marketing campaign with RTL content
- Send it
- Mail received changes from RTL to LTR

**Issue:**
Conversion doesn't take into account the current
language direction anymore when creating the inline
styling. This keeps the mails in the default format ('ltr').

Previously the inline conversion was using the `/portal/static/src/scss/portal.scss`
to set the html body text direction using the `rtlcss` library:
```css
 // Frontend general
body {
    // Set frontend direction that will be flipped with
    // rtlcss for right-to-left text direction.
    direction: ltr;
}
```
It was used during the inline conversion in a `CSSStyleRule`
after loading the doc sheets, and added with the `.o_layout` selector:
```js
if (selector === "body") {
    // The top element of a mailing has the class
    // 'o_layout'. Give it the body's styles so they can
    // trickle down.
    cssRules.push({
        selector: ".o_layout",
        rawRule: subRule,
        specificity: 1,
    });
}
```
But recent refactor reworked the styling assets used by
this process, which removed this behavior.

**Fix:**
Keep style `direction` (instead of `dir` attribute) like
before, to avoid compatibility issues in mail engines.
This is done by reapplying the body rule on the
mass_mailing iframe styling, but it could also be manually
added to the fragment itself using the editor current config
or localization.

related: https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86

opw-5982854

Forward-Port-Of: odoo/odoo#255628

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

Steps to produce:
---
- Install `Sales` module.
- Go to `Sales > Configuration > Sales Orders > Quotation Templates`.
- Create a new template and add a section.
- In the section name, add text with line breaks using `Shift + Enter`.
- Go to sale orders > Create new SO > Set quotation template created above.

Issue:
---
- Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one.

Root cause:
---
- At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2].

Solution:
---
- Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered.

[1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96
[2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86

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

Forward-Port-Of: odoo/odoo#256058

[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

When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue.
Steps To Reproduce:
1. Create an appointment.
2. Go to the "Options" tab, and click on "Allow Guests".
3. Go to the web page for the appointment, select the data and time.
4. Now, on the details page, go to any other language than the default, and click on edit/translate.
5. The issue occurs.

The issue occurs when the regex tries to match the placeholder where the guests are added, which is enabled by the allow_guests. It contains strings  with newline characters. The regex fails to take into consideration for these newlines and breaks causing the issue to appear.

To fix the issue, we'll use regex to account for the new lines.
Also the fix adapts [this commit](https://github.com/odoo/odoo/commit/bc30d2592d4a7913eddf30bac8be2d94b6c22ad4) to work with the [website refactoring](https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2)

opw-5412775

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

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

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

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

Steps to produce:
---
- Install `Sales` module.
- Go to `Sales > Configuration > Sales Orders > Quotation Templates`.
- Create a new template and add a section.
- In the section name, add text with line breaks using `Shift + Enter`.
- Go to sale orders > Create new SO > Set quotation template created above.

Issue:
---
- Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one.

Root cause:
---
- At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2].

Solution:
---
- Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered.

[1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96
[2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86

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

Forward-Port-Of: odoo/odoo#256058

Steps to reproduce:
1. Enable "Display Extra Hours" in Attendance settings.
2. Assign an overtime ruleset to an employee.
3. Ensure the employee does not have the "Officer: Manage attendances" group.
4. Create an attendance that generates extra hours for this employee.
5. Log in as the employee and open the Employees app to view Extra Hours.

Issue:
An Access Error is raised because `get_overtime_data_by_employee` in
`hr_holidays_attendance/models/hr_employee.py` performs a `_read_group`
on `hr.attendance.overtime.line`. In 19.0, the only ACL for this model
grants access to `group_hr_attendance_officer`:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/hr_attendance/security/ir.model.access.csv#L1-L11

Users with `group_hr_attendance_own_reader` (implied by `base.group_user`,
i.e. all internal users) have no read access to `hr.attendance.overtime.line`.

In later versions, this was already fixed by adding a read-only ACL for
`group_hr_attendance_own_reader` on this model:
https://github.com/odoo/odoo/blob/ad4a2ec11fea2058445e4003099af3a5caa1ef22/addons/hr_attendance/security/ir.model.access.csv#L13

This is why forward-ports are not needed.

Solution:
Add the missing `access_hr_attendance_overtime_line_own_reader` ACL to
grant read-only access to `group_hr_attendance_own_reader` on
`hr.attendance.overtime.line`, matching the approach used in later versions.
This is preferred over using `.sudo()` as it properly grants the intended
access right rather than bypassing security checks entirely.

opw-6055081

Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.

Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template"  and click on 'Search More'
7. Observe available templates

Issue:
-------
1. Archived email templates are displayed in the Email Template field.
2. If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template

Cause:
----------
1. After the [refactoring of Many2oneField](https://github.com/odoo-dev/odoo/commit/3670f78be767396f322ff3ebf068af5c2f547b36) to use dynamicInfo.context,
now ensures that global context keys propagate to relational fields. 

The archive_applicant method opens the refuse wizard with **'active_test': False**
in the context to allow refusing archived applicants. As a result, this context is now
applied when fetching the email templates, causing archived records to be included in
the search results.
https://github.com/odoo/odoo/blob/7966fae0c1fd7cfb6023efc0c274b8b395bf862f/addons/web/static/src/views/fields/relational_utils.js#L313-L321

2. Moreover, the `_compute_send_mail` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L29-L33


Solution:
-----------
- Pass `context="{'active_test': True}"` to the `template_id` field to ensure
archived templates are excluded by default, while still allowing users
to manually search for them if needed.
- Update `_compute_send_mail` to ensure only active templates are
  automatically assigned.


**NOTE:**
Issue 1 only exists till saas-18.4. From saas-18.4, email templates are fetched using [search_read](https://github.com/odoo/odoo/blob/90db6b197edb93814d980345af01c56c2b6e553e/addons/mail/static/src/core/web/mail_composer_template_selector.js#L33-L46) without passing
the context. Additionally, [search_read removes 'active_test'](https://github.com/odoo/odoo/blob/90db6b197edb93814d980345af01c56c2b6e553e/odoo/orm/models.py#L5780-L5785)
before formatting the result, so archived records are not included.

opw-5974244




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

This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate.

Summary:

When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error.

This commit improves the error handling in `mail.render.mixin` and `mail.template` by:

- mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing).
- Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates.

OPW-5980295


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

### Steps to reproduce:
	- Create an accrual plan of one level to give 20 days at the start of the year
	- Create an allocation with different mode than 'By Employee'
	- Set the accrual plan for the allocation and date from 1st Jan
	- Notice the Allocation number of days doesn't get automatically calculated

### Cause:
This is happening because when trying to process the accrual plan we won't have any records in the field employee_id

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893

And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'.

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270

### Fix:
If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null

P.S. In the forward port we will have to introduce another fix for the multi allocation wizard

opw-5888023