Improve the performance of the website forum search.

Issue:

There is a significant performance issue with a large number of forum posts impacting odoo.com.
This is due to the use of the `<%` operator on the content field of forum posts. It occurs when using the javascript search which autocompletes results in a dropdown on the search bar.

To deactivate the search on the `content` column, displayDescription needs to be set to false. but this was not possible due to the data attribute which contains text. setting it to 'false' was still truthy and therefore enabled the fuzzy search in the content column.

Fix:

- fix a js bug to properly cast the value to a boolean - this was done for other data attributes at the same time.
- set the display_description value to false to disable search on the content field. This is aligned with the python post search settings defined in: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/website_forum/controllers/website_forum.py#L95

Forward-Port-Of: odoo/odoo#246581

Description of the issue/feature this PR addresses:

When `res.partner` is inherited together with a custom mixin that adds additional values to `vals` inside the `write()` method, the behavior depends on the inheritance order. If the mixin is inherited after `res.partner`, the values added by the mixin are not included in the data collected by `res.partner.write()` for later synchronization, which can lead to runtime errors.

Current behavior before PR:

If the inheritance order is:

```python
_inherit = ['res.partner', 'custom.mixin']
```

the custom mixin’s `write()` method is executed after `res.partner.write()`.
As a result, any values added by the mixin are missing from `pre_values_list`, which is built by `res.partner.write()` and later accessed by `_fields_sync()`, causing failures when those fields are expected to be present.

This issue does not occur when the inheritance order is:

```python
_inherit = ['custom.mixin', 'res.partner']
```

because the mixin modifies `vals` before `res.partner.write()` is executed.


Steps to reproduce:
1. Create a mixin model with a new field, then add this field into `vals` inside the `write()` method so it is included in the update flow.
```python
class CustomMixin(models.AbstractModel):
    _name = "custom.mixin"
    
    custom_field = fields.Char()
    
    def write(self, vals):
        vals['custom_field'] = "foo"
        return super().write(vals)
```
2. Inherit the mixin in `res.partner`
```python
class ResPartner(models.Model):
    _name = "res.partner"
    _inherit = ["res.partner", "custom.mixin"]
```
3. Update a `res.partner` record, an error will be raised
```bash
Traceback (most recent call last):
  ...
  File "/opt/odoo/code/projects/odoo/odoo/orm/fields.py", line 1845, in __set__
    records.write({self.name: write_value})
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/code/projects/odoo/odoo/addons/base/models/res_partner.py", line 907, in write
    updated = {fname: fvalue for fname, fvalue in vals.items() if partner[fname] != pre_values[fname]}
                                                                                    ~~~~~~~~~~^^^^^^^
KeyError: 'custom_field'
```

Desired behavior after PR is merged:

Values added to vals by a custom mixin during `write()` are consistently available to `res.partner` internal synchronization logic, regardless of the inheritance order.
`res.partner.write()` and `_fields_sync()` should behave correctly even when mixins extend vals and are inherited after `res.partner`.


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

Forward-Port-Of: odoo/odoo#246927

**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.

**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.

**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.

https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a

OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄 

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

Forward-Port-Of: odoo/odoo#245947
Forward-Port-Of: odoo/odoo#240369

In 17.0 up to master, website_meta_og_img for newly added cover image
should be a relative URL instead of an absolute URL since 27th september
2025 commit 4c5d9861e389534f9ca684b9faa1ce6289df5639.

In combination with:

- [1] python fix in 19.0: accept absolute URL in website_meta_og_img
- [2] upgrade script in saas-19.1: removes absolute URL that existed in
  19.0 when upgrading to saas-19.1

We wanted to removed the error that happened in 19.0 when configuring a
cover image (in Optimize SEO) and also using a custom domain

These fixes worked up to 19.0, but there is still a possible issue in
saas-19.1:

- open "Optimize SEO" wizard of a page
- click on save without changing the image
- set a domain on the website
- go to the page with the cover image

=> result an absolute URL is saved and we get a traceback error when
visiting on wrong domain.

Cause:

The 4c5d9861e389534f9ca684b9faa1ce6289df5639 was only getting relative
URL when an image was selected. This didn't work if we open and saved
the modal when there was no website_meta_og_img and the image was gotten
from the META og:image element.

In 19.0, since there was a python fix for existing errors [1] this case
was hidden and didn't cause an issue.

Fix:

Forward-port cdffe8ab905068a3947ea62562c7209d216b2b8d in upper versions.

A fix should also be done after to ensure we don't save absolute URL:
for example if the image we save matches the og:image in DOM, don't save
it.

[1]: cdffe8ab905068a3947ea62562c7209d216b2b8d
[2]: odoo/upgrade@5408746b110d660901645b9c7b9aa9cee7aaf235

opw-5867113
opw-5874045
opw-5874931
opw-5875254
opw-5884536
opw-5885941
opw-5887081
opw-5888627
opw-5889050
opw-5891942
opw-5897982
opw-5898621
opw-5898731
opw-5899722
opw-5900450
opw-5906008

Scenario:

- add a RTL language to website (eg. arabic)
- go to the website and add a highlight to part of a line
- switch to RTL language

Result: the highlight is not at the correct X position.

This commit fixes the issue for most browser by changing in RTL that:

- the SVG is positionned from the right so the SVG right matches
  the boundary rect right

- mirroring the SVG so when the 1x1 pixel is scaled, it is scaled toward
  the left and it matches the left boundary rect

This is not always working (mostly for safari) because the positionning
of position:absolute SVG inside highlighted position:relative SPAN is
behavior differently in RTL (an even behave differently in case of mixed
RTL / LTR strings in dir:rtl blocks).

This is reproduced in this code:
https://gist.github.com/nle-odoo/21fea59d338b55b3e2a337cf360ef878

So to fix that issue, after inserting a SVG element in RTL in DOM, we
correct the X position by the current error from what we intended.

opw-5049432
opw-5344412
opw-5867908

## PR NOTE:

### 1) For the part:

```diff
-    const firstRect = highlightEl.getClientRects()[0];
+    const rtl = window.getComputedStyle(highlightEl).direction === "rtl";
+    let firstRect;
+    if (rtl) { // Take the first top right element instead of top left
+        firstRect = [...highlightEl.getClientRects()].sort((a, b) => a.top - b.top || (b.left + b.width) - (a.left + a.width))[0];
+    } else {
+        firstRect = highlightEl.getClientRects()[0];
+    }
+
  ...
-        const spanOffsetX = firstRect.x - containerRect.x;
         const spanOffsetY = firstRect.y - containerRect.y;
-        svg.style.left = `${(rects.x - containerRect.x - spanOffsetX) * scale}px`;
         svg.style.top = `${(rects.y - containerRect.y - spanOffsetY) * scale}px`;
         svg.style.bottom = `0px`;
-        svg.style.right = `0px`;
+        if (rtl) { // Position from the right instead of left and mirror the SVG
+            const spanOffsetX = containerRect.x + containerRect.width - firstRect.x - firstRect.width;
+            svg.style.left = `0px`;
+            svg.style.right = `${(containerRect.x + containerRect.width - rects.x - rects.width - spanOffsetX) * scale}px`;
+            svg.style.transform = 'scale(-1, 1)';
+        } else {
+            const spanOffsetX = firstRect.x - containerRect.x;
+            svg.style.left = `${(rects.x - containerRect.x - spanOffsetX) * scale}px`;
+            svg.style.right = `0px`;
+        }
```

I don't understand why the other SVG are positioned relative to the first one(but the original code did that and making it but with the logic of RTL instead of LTR seems to be the only way to make it work).

Note that in saas-18.3 the logic seemed to be a lot more simple, but there was a "display: inline-block;" on the highlight item which simplified the logic a lot (you can just have 100% width to match the item highlighted), but would make (LTR in RTL content, or RTL in LTR content) "`<highlight>hello</highlight> world`" appear in RTL as "`world <highlight>hello</highlight>`".

Forward-Port-Of: odoo/odoo#226359

#### Description of the issue this PR addresses:

`focusEditable`:
- The previous focusEditable logic failed in the website because `this.editable` is `contenteditable="false"` and there is often a non-editable ancestor near the selection.
- As a result, the editor did not receive focus, and focusing the wrong element caused the cursor to collapse or move unexpectedly.

`Toolbar not remains open`:
- The toolbar closed when focus leaves iframe but not getting reopen when focus returns.

### Desired behavior after PR is merged:
- The focusEditable focuses the nearest element with `contenteditable="true"` and then restores the cursor when the selection lies inside a non-editable region.
- We dispatch `selection_enter_handlers` when focus returns to the iframe document.
- This reopens the toolbar when the selection is not collapsed.

task-5261404

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

Forward-Port-Of: odoo/odoo#244970
Forward-Port-Of: odoo/odoo#237953

Steps to reproduce [18.2+]:

1. Add a dynamic snippet to a website page (e.g., Events).

2. Unpublish all event records.

3. The snippet first appears with a visible header, which then
disappears.

[A]- Starting from [1], the `o_dynamic_empty` class was introduced to
handle the dynamic snippets visibility, and an upgrade script (see [3])
set this class by default on them.

Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in
the XML template, while on the JS side, the class used to toggle snippet
visibility was `o_dynamic_snippet_empty`. This class was also added to
snippets on destroy (before saving).

[B]- As a result, a dynamic snippet may end up with:

- `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but
edited snippets.
- `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0.
- `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created
in 18.0.

Remark: the `s_dynamic_empty` class was introduced by mistake and does
not have any associated CSS

Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the
interaction flow became inconsistent (starting from 18.2): snippets were
initially visible, then hidden if no content was found... which caused
the flickering behavior described above.

And because of [B], old snippets with the `o_dynamic_empty` class
will be visible by default in 18.0.

This commit restores the intended (and original) behavior:

- A dynamic snippet should be invisible by default,

- Then the interaction decides (based on actual content) whether the
snippet should be displayed.

[1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878
[2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b
[3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906

opw-5354523

Forward-Port-Of: odoo/odoo#240807
Forward-Port-Of: odoo/odoo#238305

### Issue:
The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export

### Cause:
This PR add some required fields:
https://github.com/odoo/enterprise/pull/93357
However, for file validation, the following parent fields are mandatory if certain child fields are present:
```
- Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197
- Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198
- Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199
- Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200
- Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162
```
164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171

### Note:
This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785
It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict

### Steps to reproduce:
- Install `l10n_lu_reports` and switch to LU company
- Open the Tax Report `Annual VAT Declaration`
- Export the XML
- Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing

opw-5119920

Forward-Port-Of: odoo/enterprise#106457
Forward-Port-Of: odoo/enterprise#105143

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930

Forward-Port-Of: odoo/enterprise#106364
Forward-Port-Of: odoo/enterprise#103705

Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input.

**Steps to Reproduce:**
1. Install the hr_payroll_sale_commission module.
2. Create a user and link to an employee. Set a contract for the employee.
3. Create two commission plans for the same user:
   - Use the same Payslip Input in both plans.
   - Set the Target Frequency to "Monthly" for both.
4. Generate a payslip for the employee.

Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing)

**Error:**
`ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)`

**Cause:**
When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion.

**Fix:**
This commit ensures the currency conversion is applied per commission and prevents the singleton error.

sentry-7187854690

Forward-Port-Of: odoo/enterprise#106124
Forward-Port-Of: odoo/enterprise#104464

Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.

### Steps to reproduce

1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
   - Expected: The message is blocked.
   - Actual: The message is sent successfully.

### Root cause

The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.

1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.

### Fix

Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.

opw-5401789

Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556

**Issue**
When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities.

**Steps to reproduce**
- Create a product with a BOM using a component with qty 6.
- Create an MO producing qty 1.
- Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed).
- Click “+1”.
- Edit the component qty from 6 to 3.
- Exit the operation.
- Re-enter the operation.
-> The component shows 3/3 instead of 3/3 and 0/3.

**Cause**
On exit, `_onExit`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489
calls `post_barcode_process()`, which triggers `split_uncompleted_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16
correctly creating a `stock.move.line` with qty 3.

However, `_truncate_overreserved_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40
then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49

This happens because the newly created move line is initialized with `reserved_uom_qty = 0`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256
leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6.

opw-5166763

Forward-Port-Of: odoo/enterprise#104199
Forward-Port-Of: odoo/enterprise#100314

The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured.

https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151

Steps To Reproduce:
1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped".
2. Go to Accounting Dashboard and create a new Miscellaneous Operation.
3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries).
4. Try to post the entry.
5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..."

The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types.

Commit that caused the issue:
https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b

Ticket [link](https://www.odoo.com/odoo/project.task/5486114)
opw-5486114

Forward-Port-Of: odoo/enterprise#104476

…eductions

Currently, if users modify the MX Payroll structure in order to have no deductions in the final payroll, CFDI validation for the payroll entry will fail.

Steps to reproduce:
- Set up Payroll Structure "Mexico: Regular Pay" with Salary Rules:
  - Used subsidy:
    - Code: SUBSIDY
    - Category: Allowance
    - CFDI Concept: (O02) Employment Subsidy (Effectively Delivered to the Worker)
  - Deduction:
    - Code: DEDUCTION
    - Category: Deduction
    - CFDI Concept: (D04) Others
  - Net Salary:
    - Code: NET
    - Category: Net
    - CFDI Concept: (P01) Salaries, Wages, Stripes, and Day Labor
    - Formula: `result = payslip.paid_amount`
- In Payroll > Payslips, Click 'New Off-Cycle'
- Select employee, compute sheet, create draft journal entry and post it
- Back to the payslip, mark as paid and generate CFDI

Issue:
CFDI Validation will fail with error
`Code : 301 Message : Error en complemento Nómina. [Error #NOM38] El atributo Nomina.TotalDeducciones, no debe existir. Folio: 0002. Serie: SLR/2025/12.`
It occurs because, according to the official specs [1] attribute `TotalDeducciones` should not be reported in case there are no deductions

[1] http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/GuiallenadoNomina311221.pdf

opw-5348789

Forward-Port-Of: odoo/enterprise#104311

For old databases that were created before 16.0, existing sign request might not have a communication company set.

Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:

```
Traceback:
  ...
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
    context = self.get_document_qweb_context(request_id, token)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
    date_format = posix_to_ldml(lang.date_format, locale=locale)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
    for c in fmt:
TypeError: 'bool' object is not iterable
```

This commit fallback to the create user's company to determine the date language when there is not communication company set.

no-task (from feedback pad)

Forward-Port-Of: odoo/enterprise#87526