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

# How to reproduce
- Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number)
- Go to another page in edit mode
- Select a button
- In the "Enter URL, /page, or #anchor" input, write the url to your page (/3-14)
- Click on Apply

# The problem
Instead of a link to our page, the button has a link with a tel: protocol.

# Cause
When clicking on the Apply button, the `applyDeducedUrl()` function will be run.

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/link_popover.js#L294

That function will change the selected url with the URL deduced from `deduceURLfromText()` if any is found. In our case "/3-14" matches the `PHONE_REGEX` pattern so the url is prefixed with the tel: protocol.

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L71

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L34

That regex is a bit too permissive and allows our "/3-14" to be matched even though it starts with "/".
Side note : cases like "( )", "...", "--)" are also a match, which is not really an issue because they do not really represent anyting but it shows that the regex is not strict enough.

# Proposed solutin
We edit the regex to make it so it only matches strings that have atleast a digit and where the first character (after "+") is a digit or "("

opw-6047571

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

Forward-Port-Of: odoo/odoo#255877

Currently, an error occurs when user validates a picking.

**Steps to Reproduce:**

 - Install the `sale_management` and `sale_stock` modules.
 - Create a `sale order` without `any sale order lines` and `confirm` it.
 - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`.
 - In the `Additional tab`, select the `sale order (the one without order lines)`.
 - Now `validate` this delivery.

**Error:**
`ValueError: max() arg is an empty sequence`

This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error.

This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used.

[1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164

sentry-7089149997


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

Forward-Port-Of: odoo/odoo#254803
Forward-Port-Of: odoo/odoo#239030

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#257189
Forward-Port-Of: odoo/odoo#255530

[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#257210
Forward-Port-Of: odoo/odoo#176626

`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

# How to reproduce
- Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number)
- Go to another page in edit mode
- Select a button
- In the "Enter URL, /page, or #anchor" input, write the url to your page (/3-14)
- Click on Apply

# The problem
Instead of a link to our page, the button has a link with a tel: protocol.

# Cause
When clicking on the Apply button, the `applyDeducedUrl()` function will be run.

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/link_popover.js#L294

That function will change the selected url with the URL deduced from `deduceURLfromText()` if any is found. In our case "/3-14" matches the `PHONE_REGEX` pattern so the url is prefixed with the tel: protocol.

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L71

https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L34

That regex is a bit too permissive and allows our "/3-14" to be matched even though it starts with "/".
Side note : cases like "( )", "...", "--)" are also a match, which is not really an issue because they do not really represent anyting but it shows that the regex is not strict enough.

# Proposed solutin
We edit the regex to make it so it only matches strings that have atleast a digit and where the first character (after "+") is a digit or "("

opw-6047571

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

Forward-Port-Of: odoo/odoo#255877

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

In Chromium-based browsers, the mass_mailing theme selector attempts
to resize the mass_mailing iframe to match the size of the theme
selector wrapper. This allows the theme selector to take as much screen
space as possible while reducing unnecessary scrollbars.

However, the resizing may cause "scrollbar flickering" issues on
Chromium-based browsers, due to Chromium scrollbars taking up "physical"
width to the right of the scrollable elements. In some instances, a
scrollbar appearing causes the theme selector to scale down from the
lost width just enough that this scrollbar becomes no longer necessary,
causing the theme selector to be resized up, causing the scrollbar to
appear, which causes the theme selector to scale down...

Steps to reproduce:

- On a Chromium-based browser, try to create a new mass_mailing.
- Resize the window's height so that the bottom of the window almost
  touches the bottom of the form.

Fix:

The theme selector will no longer resize itself down if that resize were
to remove scrolling from the form, except in the following edge case:

If the difference between the ranges is larger than 20 pixels
(arbitrary value), we resize anyways, as it's a large enough difference
that it shouldn't trigger flickering.

This prevents occasional oversized empty areas under the theme selector
when a fullscreen window gets sized down

--

10156c10b09dc502a40253d64e2505e817a520bf removed the overflow: hidden; property
away from the body.o_web_client element. As a result, the convert_inline
iframe is able to affect the total height of the page when its height
is higher than the page's height, resulting in the entire page
seeming to have additional padding at the bottom. This is especially
visible when convert_inline has been used at least once, as the iframe
will have a height of 1300px.

This commit adds overflow: hidden; and position: relative; styles to
the convert_inline component div, removing them from view while still
allowing the inlining process to proceed.

Steps to reproduce:
- Create a new mailing
- Select the Events theme
- Reduce window size to below ~1000 px
- Scroll down

task-6002993

## Issue:
When viewing purchase order lines, the system attempts to compute the unit
price for downpayment lines. This results in unintended behavior.

## Cause:
PR https://github.com/odoo/odoo/pull/236669 introduced the `price_unit_product_uom` field 
along with its compute method `_compute_price_unit_product_uom` to manage PO comparison.
Although the compute method correctly skips section and note lines, it does
not exclude downpayment lines. Downpayment lines are identified by the
`is_downpayment` field, which was introduced earlier in PR https://github.com/odoo/odoo/pull/176137.
As a result, the computation is incorrectly applied to downpayment lines.

## With this commit:
The UoM price computation is prevented for purchase order lines where
is_downpayment is set to True. Downpayment lines are now treated
similarly to section and note lines to prevent unintended price recalculations.

Steps to reproduce : [Video](https://drive.google.com/file/d/1JrMN8x-i86QjRfMnaeYu-Jac03iFoJs3/view?usp=drive_link)

OPW - 5930652

Forward-Port-Of: odoo/odoo#249989

Currently, an error occurs when user validates a picking.

**Steps to Reproduce:**

 - Install the `sale_management` and `sale_stock` modules.
 - Create a `sale order` without `any sale order lines` and `confirm` it.
 - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`.
 - In the `Additional tab`, select the `sale order (the one without order lines)`.
 - Now `validate` this delivery.

**Error:**
`ValueError: max() arg is an empty sequence`

This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error.

This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used.

[1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164

sentry-7089149997


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

Forward-Port-Of: odoo/odoo#254803
Forward-Port-Of: odoo/odoo#239030

[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#257210
Forward-Port-Of: odoo/odoo#176626

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

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

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

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

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

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

Related ticket: opw-6042367

Forward-Port-Of: odoo/odoo#254487

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

Steps to reproduce:

1. Go to the website editor (ensure developer mode is off)
2. Drag and drop a Map snippet onto the page
3. Click on the newly placed snippet and save it as a custom snippet
4. Enable developer mode and refresh the website editor
5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**.
6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above
7. Disable developer mode and refresh the website editor
8. Click one of the categories in the editor side panel to open the snippets browser
9. Click into the 'Custom' snippets category
10. Observe the error

Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case.

Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets.

opw-5933787

Forward-Port-Of: odoo/odoo#256847
Forward-Port-Of: odoo/odoo#250236

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:**
* Install *sale_management*, *sale_subscription*, and *stock* modules.
* Go to *Settings* and enable *Dropshipping*.
* Create two products:
  * One *normal dropship* product.
  * One *dropship + subscription* product.
* Create a *Quotation*.
  Add both products to the order.
* Confirm the quotation.

**Observed behavior:**
* A traceback occurs during confirmation:
   File '/home/odoo/workspace/odoo19/odoo/addons/purchase_stock/models/stock_rule.py', line 159, in _run_buy
    date_planned = po.date_planned or min(v['date_planned'] for v in po_line_values)
TypeError: can't compare datetime.datetime to datetime.date

**Cause:**
* In *_run_buy*, the system computes the earliest *date_planned* using:
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/purchase_stock/models/stock_rule.py#L159
* Subscription products set *date_planned* as *datetime.date*,
https://github.com/odoo/enterprise/blob/a88c64a224805d95b60a20c502428897655dba53/sale_subscription_stock/models/sale_order_line.py#L153
`current_period_start = self.order_id.last_invoice_date or
self.order_id.start_date or fields.Date.today()`
*  while normal products set *date_planned* as *datetime.datetime*.
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/sale_stock/models/sale_order_line.py#L286

before min() It call  `_prepare_purchase_order_line_from_procurement`,
the value is assigned directly from `values.get('date_planned')`, and conversion
with `fields.Datetime.to_datetime()` only happens conditionally:
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/purchase_stock/models/purchase_order_line.py#L347-L351
As a result, some values remain `date` while others are `datetime`,

* When both are present in *po_line_values*, Python cannot compare the
  two types, causing the crash.

**Fix:**

So by moving the `fields.Datetime.to_datetime()` cast to the initial
assignment of `res['date_planned']`, so it is always a `datetime`
regardless of the source, and removing the now-redundant cast inside
the `if` block.

---

opw-6034079

---

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

Steps to reproduce
1. Open Accounting > Customers > Invoices and create an invoice with deferred dates.
2. Open the invoice and click the Deferred Entries smart button.
3. In the grouped list view, click the Date column header to sort.
4. Nothing happens.

Issue
The [IMP] web: Grouped kanban/list in a single RPC (https://github.com/odoo-dev/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf) refactor
introduced a regression. _get_read_group_order() [1] iterated over the
provided aggregates list to build the ORDER BY clause. Fields with an
aggregator attribute that are not included in the aggregates list (e.g.
date fields, which getAggregateSpecifications() excludes) were silently
dropped from ORDER BY.

[1] https://github.com/odoo/odoo/blob/26c37c9c070107f8bd753cb8a6d8343384fdd7bf/addons/web/models/models.py#L496-L514

Solution
Add a fallback in _get_read_group_order() so that when fname is neither a
groupby field nor present in the provided aggregates list, the method checks
field.aggregator directly and appends `fname:aggregator direction` (e.g.
`date:min ASC`) to the ORDER BY string. The ORM's _read_group_orderby()
already accepts such specs in ORDER BY even without them being in SELECT.

opw-6044059

Forward-Port-Of: odoo/odoo#256592

Delayed translation (draft version from change of main language that
needs to be updated on each modified secondary language) on website
were added or disabled with:

- 2d08f97c0778469b409fca23f2be5f5a98ce3df8 (October 2023) in 17.0 added
  the delay translation feature
- 0e0a74f8c5fc9f45311e629a76608c6c986d635d (December 2023) in 17.0
  disabled the feature
- 03a85b13b2c46ef7174123d902e95d5103031c6c (September 2025) in 19.0
  enabled the feature again

Some website editor users may not expect the behavior (eg. changing a
background image, then needing to edit all secondary language so the
drafted change is saved).

For now we have not found a satisfying way to prevent delay translation
for simple use case that should not break translations: eg. removing a
snippet, changing attributes, ...

Because if we did special case, it would then become unexpected:

- will we need to update translations
- if there was a previous change that needed translation update, then we
  do a change that would not need translation update, what should we do

So this PR for now gives the option to create a ir.config_parameter:

- key: website.disable_delay_translations
- value: 1

That would disable the delay_translations feature for all websites if
the user doesn't want the feature.

opw-5187670
opw-5240423
opw-5250497
opw-5254832
opw-5344412
opw-5347408
opw-5419427
opw-5424761
opw-5481352
opw-5892371
opw-5931549

Steps to reproduce the bug:
- Unarchive the MTO route
- Create a storable product P1:
    - Route: MTO + Manufacture
    - BoM:
        - Component: 1 unit of X1

- Create a storable product X1:
    - Component: 1 unit of C1

- Create a manufacturing order for 1 unit of P1
- Confirm the MO -> A child MO is created

- Try to cancel the MO for P1

Problem:
A traceback is triggered:
IndexError: tuple index out of range

'origin_picking': moves.picking_id[0],

Explanation:
When the parent MO is cancelled, all the moves linked to this MO are
cancelled (finished moves and raw moves). While cancelling them, an
activity of type "cancel" is logged on the pickings linked to these
moves (if any), in order to warn the user that actions may be required
on those pickings.

However, we do not check whether the moves actually have a picking
linked before logging the activity. The code directly tries to access
the first picking linked to the move, which triggers the traceback when
there is none:
https://github.com/odoo/odoo/blob/796316c341c4346152ad9610c30679f47aaa2ff8/addons/mrp/models/stock_move.py#L442

When cancelling an MO, the method `_log_manufacture_exception` is already
called and logs an exception activity on the child MO.

Bug introduced by:
https://github.com/odoo/odoo/pull/254636/changes/7c68c3dbb29eaad4e09d59ef7c86bd525969caec

Steps to produce:
---
- Install `website_sale` module.
- From the settings, enable `Prevent Sale of Zero-priced Products`.
- Create a product with a sale price of `0` and publish it.
- From the website, open the product page and add the product to the wishlist.
- Open the wishlist page.
- Enable the editor and change the product design to Chips, Cards, or Grid.

Issue:
---
- The Contact Us button is displayed incorrectly in some product designs.

Root cause:
---
- At [1], in the wishlist template, only the Contact Us text is displayed without the icon and label structure used by the Add to Cart button.
- Because of this, when different product designs are applied, the layout becomes inconsistent and the button appears misaligned.

Solution:
---
- Apply the same structure used for the Add to Cart button by adding the icon and label wrapper to the Contact Us button to ensure consistent styling across all product designs.

Backport of [commit]

[1]https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/website_sale_wishlist/views/website_sale_wishlist_template.xml#L353-L359

[commit]: https://github.com/odoo/odoo/commit/c697217ed0e009bd368617f25b5773c5d6ce3c92

Before:
---
<img width="261" height="358" alt="image" src="https://github.com/user-attachments/assets/cf3fe6de-5a7c-4a22-a908-09b8c121cdf4" />

After:
---
<img width="263" height="334" alt="image" src="https://github.com/user-attachments/assets/d44c41b9-0b48-41d0-992b-a506ba4428b6" />


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

Steps to produce:
---
- Install `website_sale` module.
- Go to `website > shop`.
- Open the `Customizable Desk` product page.
- From the website editor, `enable the search bar` for the product page.
- Now search for `drawer`.

Issue:
---
- Searching from a product page always scopes results to the product's category, even when the user navigated directly to the product without selecting any category.

Root cause:
---
- The issue occurs because `_prepare_product_values()`[1] always assigns a category using the fallback `product.public_categ_ids[:1]` when no category is explicitly provided. As a result, the `keep` object is generated with `_get_shop_path(category)`[2], which produces a category-based shop URL. Since the search form action is defined as `keep(search=0)` [3] in the template, the generated search URL always includes `/shop/category/<slug>`, even when the user accessed the product page directly. This unintentionally scopes all searches to the product’s first public category instead of performing a global `/shop` search.

Solution:
---
- Separate the breadcrumb logic from the search context logic. Before automatically assigning a default category for breadcrumb display, store the originally requested category (which is None when navigating directly to a product).
- Use the auto-assigned category only for breadcrumb display.
- Use the originally requested category to build the keep QueryURL

[1]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L796-L799 
[2]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L806-L812
[3]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/views/templates.xml#L360-L372

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

[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 `/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

Scenario:

- add the dynamic Products snippet on top of page and save
- go to the website with browser address bar that change height when
  going when going down in the page (hide or change size of it that is
  changing the viewport size)
- scroll all the way up and down in the page

Result: there is some jump that happen when the browser interface change
size when scrolling down or up.

Cause:

When going down the page, the viewport size changes (because the address
bar gets bigger / smaller). This causes the dynamic snippet to be
re-rendered.

Since February 2026 commit 2e5bd409581ddaab28084c42ab51b50b494f4876 to
optimize performance, product blocks are only rendered when the are in
the viewport (may depends on browser) with "content-visibility: auto".

The combination of those two things, causes that if you scroll down, the
widget is re-rendeded in owl, but it is only rendered in the page once
you scroll in the viewport so the scroll jump up or down with the
products snippet being rendered (going from 0 to eg. 300px when
scrolling into viewport) or not being rendered (going from eg 300px to
0 when scrolling and the widget not being in viewport).

Fix: remove the "content-visibility: auto" when we are in the dynamic
"Products" snippet, it was intended for the shop view and not for the
case where product block can be re-rendered outside of viewport.

opw-6005340

Note: this is mainly happening on mobile browser (eg. safari on iOS) because of the viewport resize when scrolling, but this can somehow be reproduced on chrome desktop:

- scroll below a "Products" snippet, change browser window size manually

=> the should be a jump of the content up

- scroll up to go back to the product snippet

=> the content of product snippet should appear all at once when the 0 pixel heigh get in the viewport

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

**Problem:**
The cost is not correctly computed on sale order 
line when the product is dropshipped.

**Steps to reproduce:**
- enable "margins" and "dropshipping" settings
- create a tracked, fifo product with dropship route
- add a vendor in the purchase tab
- confirm a sale order for 1 unit
- set a unit price of 10 in the PO and confirm it
- validate the dropship picking
- come back to the sale order and unhide de cost column

**Current behavior:**
the cost is 0

**Expected behavior:**
the cost should be 10 based on the unit price of the PO

**Cause of the issue:**
To compute the purchase price, when there is valued moves 
linked to the sale order line and the product is fifo/avco, 
we call _get_price_unit() on the moves.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/sale_stock_margin/models/sale_order_line.py#L21
Which uses the value of the moves
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/stock_move.py#L237-L243
But for dropshipped move the value on the moves is always 0.
So the return value will be 0 and purchase price will be 0.

**fix:**
- The idea of the fix is to use _get_value() instead of the move 
value for dropship moves. 
This approach is already used in the code inside 
_run_average_batch()
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/product.py#L474-L475

- In case there is not only dropship moves we need to do 
a weighted average


opw-6051004

### Steps to reproduce:

- Create a kit product with 6 BoM lines (with a `cost_share` of `0.0%`)
- Create + confirm a purchase order for 1 unit of the kit product at 100
- Validate the delivery
#### > One stock moves is at 16.65 the others at 16.67

### Expected behavior:

The value of purchase order line should be equidistributed among
component moves to 16.67 and the associated rounding issue should be
handled at closing.

### Cause of the issue:

Kit products rely on the `cost_share` field of the `stock.move`'s to determine the cost distribution of a kit product  among its component:
https://github.com/odoo/odoo/blob/12d408855ba6cebfcf0636064f4d25d0c5eafd11/addons/purchase_stock/models/stock_move.py#L232-L235
https://github.com/odoo/odoo/blob/12d408855ba6cebfcf0636064f4d25d0c5eafd11/addons/purchase_mrp/models/stock_move.py#L25
However, as this field is rounded  to the second decimal:
https://github.com/odoo/odoo/blob/12d408855ba6cebfcf0636064f4d25d0c5eafd11/addons/mrp/models/stock_move.py#L56-L57
it leads to unavoidable `cost_share` rounding issue when equidistributed (for unset `mrp.bom.line`'s`cost_share`). A rounding issue that is propagated to the last move cost share to sum up to `100.0%`:
https://github.com/odoo/odoo/blob/12d408855ba6cebfcf0636064f4d25d0c5eafd11/addons/mrp/models/mrp_bom.py#L469-L474
https://github.com/odoo/odoo/blob/12d408855ba6cebfcf0636064f4d25d0c5eafd11/addons/purchase_mrp/models/mrp_bom.py#L26-L31
Now the issue is that this rounding issue is unavoidable and can be of the size of a relevant percentage which is propagated on the move value.

#### Additional note:

Re-enable the TestPurchaseMrpFlow test class which has been skipped for valuation fast merge: 08b62a4bbcc6f9a391b2cc00a621ef4c76100229


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

Forward-Port-Of: odoo/odoo#253451
Forward-Port-Of: odoo/odoo#252034

Moving a section around in sale order lines when there is a line that can be abandoned throws an error

Steps to reproduce:
1. Install Sales app
2. Go to Sales and create a new quotation
3. Add any product, then add a section: enter any name for the section and then immediately press Enter (it should create an empty product line)
4. Without leaving edit mode, drag and drop the section at the top of the sale order lines (the empty product line should still be there)
5. An error is thrown

The same issue can be reproduced by moving a section down:
3b. Add any product, then add a section: move it to the top of the order lines then enter any name for the section and immediately press Enter (it should create an empty product line)
4b. Without leaving edit mode, drag and drop the section just between the product line and the empty product line

Issue:
`sortDrop` calls `leaveEditMode` at
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/views/list/list_renderer.js#L2242 which removes order lines that can be abandoned
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/model/relational_model/static_list.js#L379-L381 This can remove records from the recordMap generated before calling `super.sortDrop` in
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L175-L182 so we end up calling `_handleQuantityAdjustment` with a recordMap that contains record ids that have been deleted, throwing an error when we try to access the deleted record

Solution:
Call `leaveEditMode` before computing recordMap in order to remove the records that can be abandoned. This prevents `this.props.list.records` from being different when we generate recordMap and when we call
`_handleQuantityAdjustment`.
We also need to set the record being moved as dirty. This prevents the record from being abandoned when `leaveEditMode` is called.

opw-6022538

Steps to reproduce:
-------------------------
1. Install the Time Off module.
2. Go to Time Off > Management > Allocations, create an allocation
   for an employee, and approve it.
3. Go to Reporting > Balance and apply the filter
   Department > Employee.
4. Change the employee’s department.
5. Create an allocation for the same employee and approve.
6. Apply the Department > Employee filter again.

Observed behaviour:
----------------------------
After a department change:
* Existing allocations keep the old department
* New allocations use the new department

As a result, duplicate employee entries appear in the report

Cause:
----------
It is using [allocation.department_id.](https://github.com/odoo/odoo/blob/4c91eb3b2469cd04718005162b4572e9e3d07e72/addons/hr_holidays/report/hr_leave_employee_type_report.py#L62)
Allocations store the department at creation time, which may differ
from the employee’s current department, causing an incorrect report filtering.

Solution:
------------
Fetch department_id from hr_employee instead of hr_leave_allocation in the
hr_leave_employee_type_report and hr_leave_report.

This ensures:
* Leave balances always follow the employee’s current department
* Correct aggregation when grouping by Department → Employee

**NOTE:**
Before this [commit](https://github.com/odoo-dev/odoo/commit/976e0f9a667f4573e73e33737425d370ec1e1452), the issue was resolved starting from version saas-18.4, as the balances were filtered using the employee's department (via `hr_version`).
https://github.com/odoo/odoo/blob/104a33f093ca583c91db9705f087c73d8464c173/addons/hr_holidays/report/hr_leave_employee_type_report.py#L65-L74
related commit: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759

Since `hr_version` is no longer used in the query, this issue needs to be addressed again and forward-ported to all versions up to master.

Before:
<img width="1238" height="857" alt="image" src="https://github.com/user-attachments/assets/15e1293b-dc50-4067-a12f-079c046c2074" />

After:
<img width="1247" height="824" alt="image" src="https://github.com/user-attachments/assets/feea32de-0d9c-4eef-9ae5-639f4658560c" />


opw-5220577




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