Currently, an error occurs when the user receives a dropship order instead of delivering it directly to the customer. As a result, the sale order shows a negative delivered quantity.

## Steps to replicate:
- Install Sales, Inventory, and Purchase.
- Enable Dropshipping from Inventory settings.
- Create a test product with the Dropship route enabled and set a vendor for it in the Purchase tab.
- Create and confirm a quotation for a customer.
- Go to Purchase > `Deliver To:` and set it to `My Company: Receipts.`
- Confirm the Purchase Order and validate the receipt.
- Go back to the Sale Order.

## Observed Behavior:
The delivered quantity is -1, which is incorrect because the customer has not returned any products, nor has the user created a sale order line with a negative quantity (which would indicate a return).

## Root cause:
When computing the delivered quantity at [1], the function `_get_outgoing_incoming_moves` [2] is called to retrieve the incoming and outgoing stock moves associated with the sale order lines.

Inside this function, moves are filtered and categorized as incoming or outgoing. At [3], the condition is satisfied because the default value of `to_refund` is `True`, so the move is added to `incoming_move_ids`. Later, during the computation at [1], the code iterates through the incoming moves and subtracts their quantities from the delivered quantity.

Since the initial delivered quantity is 0, including such a move in `incoming_move_ids` causes the delivered quantity to become -1.


<h3> Why did this behavior not occur in lower versions?:</h3>

This issue was introduced by [commit], which added the functionality for users to return products that are not listed in the purchase order. As a result, their quantities appear as negative received quantities on the purchase order.

Before this change (in saas-18.2), the field `move.to_refund` had a default value of `False`. Because of this, the condition at [3] was not satisfied, and the move was not included in `incoming_move_ids`. Therefore, it was not subtracted when iterating through incoming moves, and the delivered quantity did not become negative.

Starting from 18.3, the default value of `to_refund` was changed to `True`. This causes the condition at [3] to be satisfied, the move to be included in `incoming_move_ids`, and its quantity to be subtracted during the computation, resulting in a delivered quantity of -1.

[1]-
https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L193-L209 
[2]-
https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L316-L353 
[3]-
https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L346-L351

## Solution:
We can make the condition stricter by ensuring that only incoming moves that are actual returns are counted as negative in the quantity delivered on a sale order. 

Specifically, if an incoming move has no corresponding originating return move and the customer has not created a sale order line with a negative quantity (which could also indicate a return), it should not be considered when calculating the delivered quantity.

[commit]:
https://github.com/odoo/odoo/pull/209110/changes/c1c86182e4b28e929bf56e79f57f33aaa13e67f1

opw-5933594

Forward-Port-Of: odoo/odoo#267531
Forward-Port-Of: odoo/odoo#252383

### Steps to reproduce:

- create a table (e.g. /table)
- type something in any cell and select that cell.
- apply formatting through toolbar (bold, italic, etc.)
- now select that single cell through mouse.
- observe that it is not selected

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

- The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected.

### Desired behavior after PR is merged:

- Cell selection was simplified using  areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected.

task-6207941

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

Forward-Port-Of: odoo/odoo#266208
Forward-Port-Of: odoo/odoo#263742

Steps to reproduce:
------------------------------------
1. Install `base_automation` and the Sales module
2. Create an automation rule for a sale order as follows: 
    * Trigger: State set to Sale order
    * Add a Create Activity action
    * Change User Type to Dynamic
    * Set User Field to Customer > Users
3. Create and confirm a sale order with Admin as the customer

Observation:
------------------------------------
The activity is created in Chatter, but it was not assigned to any user

Issue:
------------------------------------
The condition `self.activity_user_field_name in record` uses the `__contains__` check which only looks for direct fields on the record's model. A dotted path like 'partner_id.user_id' is not a field name on the record itself, so the check evaluated to `False`, skipping the user assignment entirely https://github.com/odoo/odoo/blob/2bafcebfaba01e46856d6eb2a440ede95b9c0a4a/addons/mail/models/ir_actions_server.py#L378-L379

Solution:
------------------------------------
Use `record.mapped()` as a fallback when the field name is not directly present on the record. `mapped()` natively supports dotted paths by traversing the relational chain (e.g. record -> partner_id -> user_id)

opw-6191715
Related Enterprise PR: https://github.com/odoo/enterprise/pull/118921

Forward-Port-Of: odoo/odoo#263530

Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
    * Trigger: On Creation
    * Action To Do: Execute AI Action
    * Add a server action tool with 'Create Next Activity' action
    * Set Activity User Type to Dynamic
    * Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user

Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths

Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed

Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module

opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530

Forward-Port-Of: odoo/enterprise#118921

Steps to reproduce
1. Create a company with Egypt localization, currency EGP
2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts
3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount
4. Switch the user language to Arabic
5. Open the Accounting dashboard

Issue
The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see
https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252

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

Forward-Port-Of: odoo/odoo#267582
Forward-Port-Of: odoo/odoo#266742

Several error are logged in the chatter when signing a payslip that includes an IMSS disability time off.

Steps to reproduce:
* Install l10n_mx_hr_payroll_account modules
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company
* Go to Employees and open Cesar Osbaldo Cruz Solorzano
* Click on "Time Off" smart button and create a new time off with "Disability due to illness (IMSS)" type for "02/01/2026"(Any date).
* Go to Payroll > Payslips > Payslips and create a new pay run
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and the Period '01/01/2026 -> 01/31/2026'
* Click on Continue, select Cesar and click on Select
* Open the payslip, click on "Validate" and "Ok"
* Mark as paid, open the "Journal Entry" from the smart button and click on "Post".
* Back to the payslip, and click on "Generate CFDI" button.
* An error is added to the chatter.

### Missing node to declare disabilities
Original message
```py
An error occurred while signing the CFDI document with the government:
Code : NOM111 Message : Error no clasificado. Extra Info : El nodo
"Incapacidades" se debera informar si se incluye en percepciones la
clave 014 "Subsidios por Incapacidad" o bien en deducciones la clave 006
"Descuento por incapacidad".
```

Translated message
```py
An error occurred while signing the CFDI document with the government:
Code: NOM111 Message: Unclassified error. Extra Info: The "Incapacidades"
(Disabilities) node must be reported if the perception key 014
"Subsidios por Incapacidad" (Disability Subsidies) is included, or if
the deduction key 006 "Descuento por incapacidad" (Disability Deduction)
is included.
```

Legal Context:
According to Mexican law, IMSS disabilities must be declared in a specific XML node.

There are two primary scenarios for reporting these amounts:
* Deduction (Type 006): The employer does not pay for these days, as the IMSS is responsible for the payment to the employee.
  This is the most common scenario.

* Perception (Type 014): The employer pays for these days as a superior benefit. For example, by law, the IMSS does not pay for the first 3 days of a disability due to illness, and employers are not obligated to cover them either. However, companies offering superior benefits may choose to pay these days as a "Disability Subsidy."

Solution:
The chosen approach is to configure the Deduction node.
For the `l10n_mx_regular_pay_imss_disabilities` rule, the `l10n_mx_concept` has been set to `l10n_mx_concept_d6` (D06 - Disability Deduction). This ensures the required node is added.

### Missing "ImporteMonetario" attribute
Original message
```
An error occurred while signing the CFDI document with the government:
Code : NOM95 Message : El atributo Deduccion:Importe no es igual a la
suma de los nodos Incapacidad:ImporteMonetario, ya que la clave
expresada en Nomina.Deducciones.Deduccion.TipoDeduccion es "006".
```

Translated message
```
An error occurred while signing the CFDI document with the government:
Code: NOM95 Message: The attribute "Deduccion:Importe" does not match
the sum of the "Incapacidad:ImporteMonetario" nodes, as the key
expressed in "Nomina.Deducciones.Deduccion.TipoDeduccion" is "006".
```

Problem:
The "Incapacidades" node requires the "ImporteMonetario" attribute, which should represent the sum of the monetary value associated with the disabilities.

Solution:
Add the "ImporteMonetario" attribute and calculate its value using `l10n_mx_daily_salary`.

### Invalid "DiasIncapacidad" format
```py
An error occurred while signing the CFDI document with the government:
Code : 301 Message : XML mal formado Extra Info : Element
'{[http://www.sat.gob.mx/nomina12}Incapacidad](http://www.sat.gob.mx/nomina12%7DIncapacidad)', attribute
'DiasIncapacidad': '4.0' is not a valid value of the local atomic type.
```

Problem:
Altough the defaultdict where the values are sum up, `number_of_days` is
a float field, and when we get back the value, it is a float, adding for
example 4.0 instead of 4, which is not a valid value.

Solution:
Cast the value to int.

### Duplicate deduction on disabilities
```py
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Salary Slip - Cesar Osbaldo Cruz Solorzano - 05/01/2026 - 05/15/2026
- Salary rule: ISR (Income Tax) (ISR)
- Error: TypeError('cannot unpack non-iterable NoneType object') while
evaluating
"
def find_rates(x, rates):
    for low, high, fix, rate in rates:
        if low <= x <= high:
            return low, high, fix, rate

gross = categories['GROSS']
result = 0
if gross:
    isr_table = payslip._rule_parameter('l10n_mx_isr_tables')[version.schedule_pay]
    low, high, fix, rate = find_rates(gross, isr_table)
    result = -((gross - low) * rate + fix)

period_factor = payslip._rule_parameter('l10n_mx_schedule_table')[version.schedule_pay]
if period_factor >= 15:
    period_factor = (period_factor / 30) * (365 / 12)
min_wage = payslip._rule_parameter('l10n_mx_daily_min_wage') * period_factor

if gross <= min_wage:
    result_qty = 0.0
"
```

Problem:
The IMSS disability amount is being deducted twice:
1. During "Worked Days" calculation, the IMSS disability is already not considered because the work entries belong to the "Unpaid Work Entry Types" of "Mexico: Regular Pay" structure.
2. During "Salary Computation", the `IMSS_DISABLE` salary rule deducts another time because it is in the `TAXABLE_ALW` category, and this one is deducted in the `NET` rule.

When the disability covers more than half of the period (e.g., 20 days in a monthly schedule), the double deduction causes the NET to become negative. This prevents the ISR rule from finding a correct stage in the tax tables, leading to a traceback.

Example: For a monthly wage of 30,000.0 and 5 disability days:
- The total amount in "Worked Days" is 25,000.0 (disabilities already deducted).
- The IMSS_DISABLE rule calculates -5,000.0, and when the NET rule is calculated, the disabilities are deducted again. Total NET becomes 16,843.84 instead of the expected 20,834.85.

Solution:
Change the rule category to `INTERMEDIARY_COMPUTATION` and avoid the double deduction when the `NET` is calculated, as it is already considered in the "Worked Days".

### Incorrect values in the XML
The signing process completes without errors, but some amounts in the generated XML are incorrect.

Problem:
The introduction of the Deduction 006 (Disability) directly impacts the calculation of the SubTotal and Total attributes in the Comprobante node.
For a monthly payslip with a wage of 30,000.00 (daily salary of 1,000.00) and 5 disability days (work risk), the values are calculated incorrectly as follows:
Attribute            | Calculation                      | Actual Value | Correct Value
---------------------|----------------------------------|--------------|--------------
Comprobante:SubTotal | Sum of Perceptions (P01)         | 25000.00     | 30000.00 (1)
Comprobante:Total    | SubTotal - Total Deductions (2)  | 15803.74     | 20803.74

(1) Must include the 5,000.00 from disabilities to balance the deduction.
(2) Total Deductions = D06 (5,000.00) + ISR (3,451.65) + IMSS (744.61) = 9,196.26.

The Total is currently undercalculated because the 5,000.00 is being
deducted from the SubTotal that already had those 5,000.00 excluded.

Solution:
Since the `SubTotal` is derived from Perceptions, and the "(P01)
Salaries, Wages, Stripes, and Day Labor" amount is driven by the
`GROSS_WITHOUT_HOLIDAY` rule, the disability amount must be added. This
balances the Deduction 006, ensuring `SubTotal` is correct.

### Absenteeism and Disabilities
By law, the calculation of IMSS contributions depends on these two types of unpaid days:
* Disabilities: Refers to medical leave issued by the Institute (IMSS).
* Absenteeism: Refers to unjustified leave; apply for periods of fewer than 8 days.

Source: [Artículo 31](https://www.imss.gob.mx/sites/all/statics/pdf/leyes/LSS.pdf)
Translated text:
Article 31. When wages are not paid due to the employee's absence from work, but the employment relationship persists, the monthly contribution shall be adjusted according to the following rules:

I. If the employee's absences are for periods of fewer than eight consecutive or non-consecutive days, contributions shall be calculated and paid for such periods only for the sickness and maternity insurance...
If the employee's absences are for periods of eight consecutive days or more, the employer shall be released from the payment of employer-employee contributions...

IV. In the case of absences covered by medical disabilities issued by the Institute, it shall not be mandatory to cover the employer-employee contributions, except regarding the retirement branch.

The following table summarizes the contribution requirements based on the type of absence:
Insurance Branch (RAMA)         | Section I (Absenteeism) | Section IV (Disability)
--------------------------------|-------------------------|------------------------
Sickness and Maternity          | Paid                    | Not Paid
Disability and Life             | Not Paid                | Not Paid
Severance and Old Age           | Not Paid                | Not Paid
Work Risk                       | Not Paid                | Not Paid
Daycare and Social Benefits     | Not Paid                | Not Paid
INFONAVIT                       | Not Paid                | Paid
Retirement                      | Not Paid                | Paid

The type of unpaid day to be considered depends on the specific insurance branch being calculated within the employer-employee contributions.

### Add test for cfdi with disabilities.

target: 19.0
task-6066160

Forward-Port-Of: odoo/enterprise#116819

Problem
------------------
When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce:
1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day)
2. From the allocations view -> New Group Allocation
3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off
4. Go to the newly created allocation The allocation amount is 0.

Reason
----------------------
When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed.

Solution
------------------
Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations.

task-4938695

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#267305
Forward-Port-Of: odoo/odoo#265783

Problem:
When the selection is inside a `contenteditable="true"` element that is not the root editable, focusing away does not trigger a save.

Cause:
When the DOM contains a nested contenteditable structure like:

```html
<div class="odoo-editor-editable" contenteditable="true">
  abc
  <div contenteditable="false">
    ac
    <div contenteditable="true">a</div>
  </div>
</div>
```

With the selection inside the inner `contenteditable="true"`, the `blur` event is not triggered on `.odoo-editor-editable` when focusing away, because the active element is the inner div and `blur` does not bubble.

Solution:
Replace the `blur` listener with `focusout`, which bubbles from the inner `contenteditable="true"` up to `.odoo-editor-editable`, allowing `onBlur` to be called correctly.

Steps to reproduce:
- Open Project > Task.
- Add a `/column` block in the description.
- Focus inside any column and write some text.
- Click away to change tab.
- Reopen the description tab.
- The latest changes inside the columns were not saved.

opw-6227922

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

Forward-Port-Of: odoo/odoo#266367

__

## Short functional explanation of the error
When confirming a Purchase Order holding lines with an analytic distribution that has been manually added, and creating a vendor bill out of this PO using the Auto-Complete field. When we change the account of that line, the line loses the manually added Analytic Distribution.

## Reproduction Steps
1. Go to Accounting. Click on the tab Configuration; under the Analytic Accounting section, click on Analytic Distribution Models.
2. Create an Analytic Distribution Model for a product.
3. Go to Purchase. Create a new PO, set a Vendor and select the product you created the Analytic Distribution Model for. On the right side of the form, click on the view menu and check Analytic Distribution to make it appear.
4. Click on the Analytic Distribution of the product and add a new one; for example, select Administrative in the Departments section.
5. Confirm order.
6. Go to Accounting and click on the Vendors tab > Bills. Create a new bill, and in the field Auto-Complete, select the PO you just created.
7. Change the account of the line.

### Expected behavior
Only the account should be changed on the line.

### Unexpected behavior
The manually added Analytic Distribution has disappeared.

## Origin of the issue
When we change the `account_id` field, the compute method `_compute_analytic_distribution` is triggered. This method retrieves the related distributions of the line:
https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/account/models/account_move_line.py#L1154 which, in the context of Purchase, calls this method: https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/purchase/models/account_invoice.py#L540-L545 We retrieve the distribution of the related line using `self.purchase_line_id.analytic_distribution`. However, this code isn't triggered when the move line has an analytic distribution, even though the related line `purchase_line_id` might have one! Therefore, we need to execute that code whether or not our move line has an analytic distribution.
Note: the same behavior is to avoid when creating invoices for
quotations.
__
opw-6062466

Forward-Port-Of: odoo/odoo#267274
Forward-Port-Of: odoo/odoo#258380

Steps to reproduce:
- Activate Anglo-Saxon accounting
- Create a product with track inventory and an automated inventory valuation product category
- Define MTO on the product
- Add this product to an Analytic Distribution Model (i.e. Legal)

- Create a SO for this product
- Create and confirm the PO related to it, the Analytic account is set on the PO.
- Confirm the reception of the product
- This creates a Stock valuation layer with the Analytic account
- Confirm the SO
- Confirm the delivery of the product
- This creates a Stock valuation layer with the Analytic account too
- Create the Invoice

Issue:
Missing analytic account on the 110300 Stock Interim (Delivered) creating unabalanced analytic accounting

Other:
test_report_invoice_items_anglo_saxon_automatic_valuation
introduced in this PR https://github.com/odoo/odoo/pull/205777
checks that in a project's analytic report, the values based
on cogs lines are displayed in the cost section.
With this fix, both cogs lines will have an analytic account
so their impact on the project analytic report will even out.
This made the test fail.
To keep the benefit of this test, we simulate that the user manually
removes the analytic account on some of the cogs lines
(those targetting stock interim received).


opw-6060567

Forward-Port-Of: odoo/odoo#266617
Forward-Port-Of: odoo/odoo#261798

Issue:
Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobilira CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button).

opw-5432421

Forward-Port-Of: odoo/enterprise#108355

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Navigate to Invoicing > Vendors > Bills.
- Create a new vendor bill.
- Observe that `GT Document Type` includes `NABN - Nota de Pago Electrónica` option.
- `Confirm` the bill.
- Click `Credit Note`, add a reason, and click `Reverse`.
- Observe the available options in the `GT Document Type` field.

**Observation:**
The `NABN - Nota de Pago Electrónica` option is not available for 
vendor credit notes (`in_refund`), even though `NABN` is a GT-specific 
credit note document type.

**Root Cause:**
At [1], `NABN` is added for vendor bills (`in_invoice`, `in_receipt`) 
instead of vendor credit notes (`in_refund`).

**Fix:**
This commit ensures users can correctly select `NABN - Nota de Pago Electrónica` 
on GT vendor credit notes.

[1]:
https://github.com/odoo/enterprise/blob/c7fa8c9c6f6830f5702fab4f6efaf3ac33f7fe72/l10n_gt_edi/models/account_move.py#L159-L160

opw-6252256

Forward-Port-Of: odoo/enterprise#118711

**Description of the issue this PR addresses:**
----------------------------------------------
Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation.

**Current behavior before PR:**
----------------------------------------------
- Visitors can type @ in the livechat composer and trigger partner mention suggestions.
- The suggestions only include the visitor themselves or odoobot.

**Desired behavior after PR is merged:**
----------------------------------------------
- The @ delimiter is disabled for visitors in livechat threads.
- Partner mention suggestions are no longer triggered for visitors.
- Internal users (operators) can still use @ mentions normally.

Task-5119068

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

Forward-Port-Of: odoo/odoo#267566
Forward-Port-Of: odoo/odoo#253551

When a user installs only the Invoicing app and creates a new purchase journal, no default_account_id is set on the journal. The Invoicing app does not expose account configuration, so the user cannot fix this manually. As a result, importing a Peppol XML invoice through that journal fails with a database constraint error because the generated account.move.line has a null account_id.

https://github.com/odoo/odoo/blob/16245530f0e3e9be21c8b96baaecd3a679420cac/addons/account/models/account_journal.py#L776-L805 This already auto-creates accounts for bank/cash journals, but does nothing for sale/purchase journals.

Steps to reproduce:
- Install the Invoicing app (no full Accounting)
- Create a new purchase journal with type 'purchase'
- Go to Vendors -> Bills and Upload a Peppol XML file
- Error importing attachment as invoice (decoder=_import_invoice_ubl_cii)

Ticket [link](https://www.odoo.com/odoo/action-4043/6014363)
opw-6014363

Forward-Port-Of: odoo/odoo#267552
Forward-Port-Of: odoo/odoo#252859

**Steps to Reproduce:**

1. Configure the website default language different from the user’s current language.
2. Go to Website → Site → Pages.
3. Duplicate an existing page.
4. Edit the duplicated page and save the changes.
5. Duplicate the edited page again.
6. Observe that the newly duplicated page is generated from the original page content instead of the updated duplicated page.

**Issue:**

When duplicating a website page, the website default language was not passed in the context. As a result, the duplication was performed using the active user language.

The root cause is that `copy()` does not simply duplicate the existing `arch_db` translation dictionary. Instead, it copies the field value in the current language and then rebuilds all translations through `copy_translations()`.

This behavior becomes problematic when `delayed translations` are involved. After a page is modified in a non-default language, the latest changes may be stored in a delayed translation entry (`_{lang}`) while the regular translation value remains unchanged. During the copy process, these delayed translation entries are intentionally discarded because they are considered temporary data and are not treated as valid language translations.

As a result, when the page is duplicated from a non-default language, `copy()` rebuilds the translations using an outdated translation value instead of the most recent content stored in the delayed translation. The newly
duplicated page therefore does not accurately reflect the current state of the source page.

**Solution:**

The fix enables `check_translation=True` during page duplication so that the copy operation uses the latest translation state, including delayed translations when available. This ensures duplicated pages are generated
from the most recent version of the source page and keeps translated content consistent across languages.

**opw-5914281**

Forward-Port-Of: odoo/odoo#264656

When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`.

`classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds.

Steps to reproduce:
1. Open Email Marketing and create a new mailing using the Welcome Message template
2. Select a content block, open Customize, set the background to the 5th theme color
3. Save the mailing
4. Open the Website editor and change the 5th primary color to a different value
5. Reopen the saved mailing in the backend

=> the block's rendered background follows the new website color instead of the one picked at design time

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

Forward-Port-Of: odoo/odoo#267570
Forward-Port-Of: odoo/odoo#253934

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#118449
Forward-Port-Of: odoo/enterprise#113227

Before this commit:
---

- Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name.
- If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44).
- However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`.
- As a result, nothing was shown when `summary` was empty, even though `display_name` was set.



Steps to reproduce:
---

- Create an activity in chatter
- Remove the default summary if set.
- Observer the title.

https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045


After this commit:
---

- Added `display_name` to `_to_store` along with `summary`.
- Chatter activity now correctly falls back to `display_name`.
- Users can now see the correct activity label in chatter.




OPW: 6212976



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

Forward-Port-Of: odoo/odoo#266706