Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

Forward-Port-Of: odoo/enterprise#124728
Forward-Port-Of: odoo/enterprise#124027

Steps to reproduce:
- install Timesheets
- create an employee for a user in company B
- switch to company A (where the user has no employee)
- the systray icon is hidden even though the user can
create timesheets in company B via the company selector

Current behavior:
the systray only checks the current company for a valid
employee, ignoring other selected companies.

Expected behavior:
the systray should be visible whenever the user can create
timesheets i.e. when they have an active employee in any
of the selected companies.

Issue:
the check used a stored boolean on `res.partner` that has no
company scope and becomes stale when an employee is archived
(the stored dependency does not re-fire). the timesheet
creation logic checks all selected companies for active
employees, but the systray did not mirror that.

Fix:
use `employee_ids` a `One2many` that checks all selected
companies and excludes archived employees, matching the
timesheet creation logic exactly.

task-6330539

Forward-Port-Of: odoo/enterprise#124761
Forward-Port-Of: odoo/enterprise#121730

Steps to reproduce:
---

Case 1:

1. Add a carousel at the top of the page.
2. Apply the parallax effect to all slides.
3. Reload the page and navigate to the second slide without scrolling.
4. Scroll slightly and observe the jump in background position.
5. Scroll back to the top and notice the changed background position.

Case 2:

1. Add a carousel to the page.
2. Apply the parallax effect to each slide.
3. Add text over the carousel and enable animation on appearance and on every time.
4. Slide between images and observe the bouncing effect.


https://github.com/user-attachments/assets/d11ee430-8b95-4903-b001-1b9ba8ee58cd

Why this change?
---

When the parallax effect is applied to carousel slides, only the first slide is initialized with the correct [parallaxHeight](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/parallax/parallax.js#L49). The remaining slides are initialized while hidden, resulting in a computed height of 0. When scrolling, the background height is recalculated with the correct value, producing a visible jump effect.

Additionally, when text or any animated content is added on top of the carousel (especially animations triggered on appearance or on every slide change), a [resize event](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/animation.js#L111) is triggered on each transition. This causes `updateBackgroundHeight()` to run again. Since hidden slides were initialized with height 0 and later receive their actual height, the recalculation produces a noticeable bouncing effect.

After this commit:
---

The parallax computation now relies on the parent element’s `getBoundingClientRect().height` when used inside a carousel. Since the carousel slide height is already defined and consistent, this ensures correct initialization even when the slide is not yet visible.


OPW: 5909351




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

Forward-Port-Of: odoo/odoo#250290

Steps to reproduce
---
1. Install a carrier that requires a positive package shipping weight (e.g. UPS) and enable Packages.
2. From the Barcode app, process a delivery and Put in Pack the products.
3. Validate the transfer.

Issue
---
Validation is refused because the package has no positive shipping weight, even though its computed weight is correct.

The package shipping weight is only set in `_post_put_in_pack_hook` from `context['weight']`, which is filled exclusively by the put in pack wizard. Flows that bypass the wizard, like the Barcode app, never provide that key, so the stored `shipping_weight` stays 0 while carriers reading it directly reject the delivery. The Barcode app suppresses the wizard through the `barcode_view` context, so its put in pack goes straight to the hook without any weight.

https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/stock_barcode/models/stock_move_line.py#L193-L196

This handling was centralized in this hook by 9a2ff6f4033e, so every wizard-bypassed pack leaves the field empty. Defaulting it to the package computed weight via `_get_weight` when the context did not provide one makes the stored value correct for any carrier, independently of the flow that created the package.

https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/stock_delivery/models/stock_move.py#L111-L115

opw-6297689

Forward-Port-Of: odoo/odoo#273876
Forward-Port-Of: odoo/odoo#272510

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#277131
Forward-Port-Of: odoo/odoo#269100

Steps to reproduce:
- Go to Website
- Upload an image in the company logo (navbar)
- Open the website editor and click on the logo
- Open the image info panel

Current behavior:

When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't.

Reason:

When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment.

The website logo is served through a dynamic link
(`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with.

As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes.

Fix:

When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo.

opw-6260496

Forward-Port-Of: odoo/odoo#277125
Forward-Port-Of: odoo/odoo#273542

### [FIX] web: fix mocked dates in tests

Dates are mocked in all unit tests by default; either to a default static
value, or to one defined in the test/suite. To do so, the `window.Date`
constructor is overridden to have the arguments auto-filled with the current
mock date paramters.

Before this commit, an additional offset was always added to the given
arguments to reflect:
- the time elapsed from the beginning of the test;
- any virtual offset added by a helper such as 'advanceTime'.

The issue is that the spec of the Date constructor wants that the returned date
object has to match all given arguments, and any omitted argument will be
defaulted to the current date/time. This was not the case in tests, as the
offset was always added, regardless of the given arguments.

With this commit: only the arguments that are NOT given and that have been
defaulted to current (mocked) date/time will be offset by the adequate value.
Furthermore: as these mocked parameters are meant to reflect UTC values, the
offset now also considers the *actual* browser offset to generate a local date
from the mock date parameters.

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

Forward-Port-Of: odoo/odoo#277041
Forward-Port-Of: odoo/odoo#275391

The `account_journal_type.bank` KPI (surfaced by the Databases app as `account_journal_type_bank`, tooltip "Draft entries in journal Bank") is meant to report journal entries in bank journals that still need attention: drafts, posted-but-unchecked entries, and posted bank entries that are not yet reconciled.

The "not yet reconciled" case was implemented as:

    ```LEFT JOIN account_bank_statement_line st_line
           ON move.statement_line_id = st_line.id
    AND (st_line.id IS NULL OR NOT st_line.is_reconciled)```

`st_line.id IS NULL` does not only match unreconciled bank transactions, it also matches any posted move booked directly in a bank journal that never originated from an imported bank statement line (manual entries, bank fees, opening balances, ...). Those moves have no `statement_line_id` by design and can never be reconciled, so they were counted as "pending" forever, permanently inflating the KPI for any database with such entries.

Only require an actual bank statement line before flagging it as unreconciled, matching the logic already used for the "to reconcile" count on the journal dashboard (account_journal_dashboard.py).

opw-6199785





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

Forward-Port-Of: odoo/odoo#275597

\* : html_editor

Commit [1]:

Steps to reproduce: replacing image stuck issue when deleted
1. Go to Website > Edit.
2. Add any picture snippet (e.g., Text-Image).
3. Click the 'Replace' button and upload an image.
4. Open the media dialog again and delete the uploaded image.
5. Click the 'Discard' button.
6. Try to save the changes.

Issue:
- The website gets stuck in the same position and does not allow saving.
- In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`.

Expected behaviour:
- Saving should be allowed with a default image, that is similar to other images.

This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck.

Commit [2]: resolve traceback when leaving edit mode via browser

Steps to reproduce:
1. Go to Website > Edit.
2. Open the snippet modal and select any snippet.
3. Press the 'Back' button in your browser.
4. A dialog will appear asking to discard changes; click 'OK'.
5. A traceback error occurs, and an empty space appears in the editor.

Issue:
- Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange.
- Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener.
- As a result, the editor is left in an unstable state, causing a traceback error.

Solution:
- This commit ensures the 'window' event executes before the browser event.
- It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser.

task-4570164

Forward-Port-Of: odoo/odoo#277089
Forward-Port-Of: odoo/odoo#199193

Steps to produce:
---
- Install the `Sales` module.
- Go to Invoicing > Configuration > Accounting > Taxes.
- Open the 0% Exports tax and set a value in the `Label on Invoices.` Field under the Advanced Options tab.
- Create a sale order with multiple sections, apply the 0% Exports tax to the order lines, and enable `Hide Composition` on one of the sections.
- Preview the sale order.

Issue:
---
- The tax displayed in a collapsed section summary differs from the tax shown on regular order lines for the same tax.

Root cause:
---
- At [1], `_get_grouped_section_summary()` only returns `tax_labels`, which are then used when rendering the collapsed section summary. As a result, the invoice label is displayed instead of the actual tax name.

Solution:
---
- Add `tax_names` to the values returned by `_get_grouped_section_summary()` and use them when rendering the collapsed section summary, ensuring consistent tax information across the preview.
- Also removed the unnecessary fallback in the return statement, as `res` is always populated.

[1]https://github.com/odoo/odoo/blob/be0bf1365e054521ece224f5e3a4b7cbce402315/addons/sale/models/sale_order_line.py#L1572-L1604

Before:
---
<img width="1068" height="156" alt="image" src="https://github.com/user-attachments/assets/8030c35e-5c73-4fed-9feb-c4729add7894" />

After:
---
<img width="1057" height="143" alt="image" src="https://github.com/user-attachments/assets/336030ed-68b2-4d14-b26f-ff391257d6d4" />

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

Forward-Port-Of: odoo/odoo#277414
Forward-Port-Of: odoo/odoo#270544

**Steps to reproduce:**
- Install the `accountant` and `sale_management` modules.
- Create and confirm a SO with a product whose `Invoicing Policy` is 
  set to `Ordered quantities`.
- Click `Create Invoices` > select `Regular invoice` > `Create Draft`. 
  (leave the invoice in the draft state).
- Navigate to Accounting > Review > Invoiced Not Delivered.
- Select the newly created invoice and click `Create Accrual Entries`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
At [1], `processed_qty` is initialized with `0`. If all the selected invoices are 
in the draft state, the code never enters the for loop, so `processed_qty` 
remains 0. Later, it attempts to divide the `amount` by `processed_qty`, 
causing an error.

**Fix:**
This commit prevents errors when creating accrual entries for draft invoices.

[1]:
https://github.com/odoo/odoo/blob/a7d285a833f5b1d47a11a1b8ec31e3730c1c854c/addons/account/wizard/accrued_orders.py#L258-L265

opw-6332652

Forward-Port-Of: odoo/odoo#273330

When sending an email to an invoice mail alias without valid
attachment, a custom bounce mail is sent to inform the customer
that it was bounced because of a missing attachment.

Currently, the bounce email from will default to the bounce alias
of the main company of the DB.

In a multi company setup, where each company might have their own
mail alias domain, this can be confusing for the receiving party
that didn't send the original email to the main company's alias domain.

## Proposed solution:
We call `_routing_create_bounce_email` with the right
company in the context, since the journal company
is already detected.
Additionally, in the context of the accounting code
calling the bounce private method, we pass an explicit value  for `reply_to`

## How to reproduce it:
1) Set up DB with two companies (companyA and companyB). Install account.
2) Set up two mail alias domains (companya.com and companyb.com)
3) Send an email to the invoice alias of companyB (e.g. invoices@companyb.com).
-> bounce email will have FROM as "notifications@companya.com" (the notifications alias
of companyA)

Example headers before:
```
Reply-To: "YourCompany" <catchall@companya.com>
To: customer@example.com
Date: Thu, 02 Jul 2026 11:18:49 -0000
Return-Path: bounce@companya.com
From: "MAILER-DAEMON" <bounce@companya.com>
```
After fix:
```
Reply-To: info@companyb.com
To: customer@example.com
Date: Thu, 02 Jul 2026 11:16:19 -0000
Return-Path: bounce@companyb.com
From: "MAILER-DAEMON" <notifications@companyb.com>
```

opw-6342778

Forward-Port-Of: odoo/odoo#273671

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d32e61b118 [REL] 19.4.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a2ed1a6c65 [FIX] scorecardPanel: mismatch baseline/keyValue [Task: 6380393](https://www.odoo.com/odoo/2328/tasks/6380393)
https://github.com/odoo/o-spreadsheet/commit/5a0ce53863 [FIX] TableComputedStylePlugin: skip table style for invalid pivot [Task: 6306263](https://www.odoo.com/odoo/2328/tasks/6306263)
https://github.com/odoo/o-spreadsheet/commit/2a17559c32 [FIX] squisher: adapted ranges that become cells [Task: 6390727](https://www.odoo.com/odoo/2328/tasks/6390727)
https://github.com/odoo/o-spreadsheet/commit/ca1b96ded1 [FIX] documentation: Adapt doc/example to owl3 [Task: 6384935](https://www.odoo.com/odoo/2328/tasks/6384935)
https://github.com/odoo/o-spreadsheet/commit/5f36bffc85 [FIX] components: replace `props/plugin` with `useProps/usePlugin` [Task: 6384935](https://www.odoo.com/odoo/2328/tasks/6384935)
https://github.com/odoo/o-spreadsheet/commit/9ba5f1954c [IMP] package: update to owl alpha 43 [Task: 6384935](https://www.odoo.com/odoo/2328/tasks/6384935)
https://github.com/odoo/o-spreadsheet/commit/17a7db83ab [FIX] default: clear empty keys in cell style [Task: 6366056](https://www.odoo.com/odoo/2328/tasks/6366056)
https://github.com/odoo/o-spreadsheet/commit/c6c38b110c [FIX] default: fix 1st edit issue [Task: 6366056](https://www.odoo.com/odoo/2328/tasks/6366056)
https://github.com/odoo/o-spreadsheet/commit/413fc40344 [IMP] default_clipboard: enlarge content in instead of multiple [Task: 6366056](https://www.odoo.com/odoo/2328/tasks/6366056)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Before this commit, when logging in as Demo user with a direct chat, logging out + logging in with Mitchell Admin would crash with the following error:

```
TypeError: can't access property "imStatusUI", this.channel.correspondent is undefined
```

This happens because this attempts to restore the direct chat in chat window. Normally this shouldn't happen thanks to being unable to fetch inaccessible channels, however Mitchell Admin is the admin of DB thus can fetch the channel data. The crash comes from computation of `correspondent` that is `undefined` because it can't determine a correspondent from the Point of view of Mitchell Admin, and the template isn't defensive against missing a `correspondent` in a direct chat.

One solution could have been to support opening of direct chat, but this implies fixing a lot of complex issues, such as:

- Mitchell Admin can't use composer because this attempts to add a member but there's a contraint for direct chat to have at most 2 members
- This direct chat looks like a group chat without a name, we can guess this is a direct chat only because of broken avatar and the start message in message list stating this is a direct chat
- Several other actions show weird behavior, like "Invite People" ignoring people in the chat

This commit fixes the issue by ignoring the restore of chat in chat hub for direct chats that current user is not a member.

Forward-Port-Of: odoo/odoo#277199

Translatable rows that are identified by a stable key rather than by
their text (e.g. selection option labels in ir.model.fields.selection,
and other module-reflected metadata written through upsert_en()) can
have their English source text changed by a module upgrade while
keeping the same key. For example product.template's selection value
'consu' went from meaning "Consumable" to meaning "Goods" between 17.0
and 18.0, without the stored value itself changing.

In that situation, upsert_en() always refreshes the 'en_US' entry from
the current code, so English is never wrong. But every other language
keeps whatever value it had, since upsert_en() blindly merges the new
'en_US' entry into the existing jsonb without checking whether the
previous 'en_US' value actually changed. When the module's .po file is
later reloaded, TranslationImporter.save() finds a non-empty value
already there for each language and, by design, does not overwrite it
unless explicitly asked to (`overwrite`) on a record that isn't
`noupdate`. That protection is correct when the English text hasn't
changed (it keeps manual translation customizations across upgrades),
but here it ends up protecting a translation of a source string that
no longer exists.

As a result, a value whose meaning changes across versions keeps
showing its old label in every language except English, forever,
unless someone forces a translation overwrite.

Fix this in upsert_en() itself: when the incoming 'en_US' value
differs from the one currently stored, drop every other language
already stored for that row instead of merging into it. Those
translations were made for a source string that no longer exists, so
there is nothing worth protecting. Once dropped, they are simply
missing from the jsonb, so TranslationImporter.save() naturally lets
the freshly (re)loaded translations in on its next run, without needing
to know anything about source drift, and `overwrite`/`noupdate` keep
their exact original meaning for every other case.

Task-6333080


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

Forward-Port-Of: odoo/odoo#277491
Forward-Port-Of: odoo/odoo#275080