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

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
---
- Create a normal parent task with one normal sub-task and one template sub-task.
- Open the parent task form view and observe the Sub-tasks stat button count and
notebook tab, check the subtask view as well.
- Create a template parent task with one normal sub-task and one template sub-task,
then repeat the same checks.

Issue
---
- Task templates are handled like regular subtasks in the subtask count, notebook, and
subtask view, without taking the parent task type into account.

Current Behaviour
---
- For a normal parent task, both the normal sub-task and the template sub-task are
counted and shown in the opened subtask view and notebook.
- For a template parent task, the same filtering is applied, even though template subtasks
should remain accessible in that context.

Expected Behaviour
---
- For a normal parent task, only real sub-tasks should be counted and shown in the subtask
view and notebook, and on the project kanban card.
- For a template parent task, template subtasks should remain available in the subtask
view and notebook according to the parent template context.
- In the project kanban card, tasks must not be counted when their parent task is a template,
 even if the child task itself is not a template.

Fix
---
- Apply template-aware filtering to subtask counting,project kanban task count and subtask view
 behavior, depending on whether the parent task is a normal task or a template task.

task-5966684

Forward-Port-Of: odoo/odoo#275901
Forward-Port-Of: odoo/odoo#252403

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

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

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.

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

Login uniqueness is enforced by a `UNIQUE (login)` constraint that Postgres compares byte for byte, so signing up with foo@example.com and then Foo@example.com produces two separate accounts pointing at the same real mailbox.
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/odoo/addons/base/models/res_users.py#L274

Even if the DB constraint did catch an exact-case duplicate and `_signup_create_user` re-raised it as a `SignupError`, the controller's friendly "already registered" branch only triggers when the duplicate lookup finds a row, and that lookup goes through `_get_login_domain` with an exact `=` operator. Case variants would fall into the generic "Could not create a new account" branch instead.
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/addons/auth_signup/controllers/main.py#L68-L75
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/odoo/addons/base/models/res_users.py#L749-L750

`_signup_create_user` now refuses creation when a user with the same email already exists, applying to both b2c free signup and token-based invitations. It raises `UserError` directly so the controller's `except UserError` surfaces the message without a redundant lookup. The check uses `_get_email_domain`, whose base implementation is switched from `=` to `=ilike` over a value escaped via `tools.escape_psql` so `%` and `_` are matched literally rather than as wildcards. Its only existing caller is `reset_password`, which already wants case-insensitive matching.

Steps to reproduce:
1. In Settings, set Customer Account to "Free sign up" and save.
2. Log out, then on the login page click "Don't have an account?".
3. Register with foo@example.com.
4. Log out again and click "Don't have an account?".
5. Register with Foo@example.com.

=> Two distinct user accounts are created for the same mailbox.

opw-6199441

Forward-Port-Of: odoo/odoo#273071
Forward-Port-Of: odoo/odoo#263864

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

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

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

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

**Steps to reproduce:**
1. Create a Sales Order.
2. Create a 50% down payment invoice.
3. Create a credit note for the down payment invoice.
4. Reset the credit note to Draft and cancel it.
5. Create the final invoice from the Sales Order.

**Issue:**
The final invoice is generated for 100% of the order amount, acting as if the down payment invoice does not exist.

**Expected behavior:**
The final invoice should only include the remaining 50% of the order amount because a valid 50% down payment invoice still exists.

**Why this happens:**
- The `price_unit` on the Sales Order's down payment line is manually updated during `action_post()` based on the sum of posted invoices minus posted credit notes.
- When the credit note is posted, `price_unit` drops to 0. However, when that credit note is subsequently reset to draft and cancelled, it triggers `button_cancel()` which only refreshed the line's display name and failed to recalculate `price_unit`. As a result, `price_unit` remained at 0 even though the credit note was no longer active, causing the final invoice to deduct nothing.

opw-6373578

Forward-Port-Of: odoo/odoo#277043
Forward-Port-Of: odoo/odoo#275684

Steps to reproduce
1. Set the user timezone to one with a positive UTC offset, e.g.
   Europe/Brussels.
2. Open Payroll > Work Entries in pivot view and apply the built-in
   "Current Month" filter.
3. Expand an employee row and group by Date > Day.

Expected: only days of the current month are visible (April 1..30 at
the time of writing).

Actual: the last day of the previous month (March 31) is included and
the last day of the current month (April 30) is missing — the whole
window is shifted one day earlier.

Issue
The relative-date DSL added in
https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f
operates on a tz-aware datetime starting from `now` when no explicit
anchor is given. With the filter at
https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/addons/hr_work_entry/views/hr_work_entry_views.xml#L190-L192,
`=1d` resets the clock to 00:00 and the day to the 1st in the user's
timezone, evaluating to `2026-04-01 00:00:00+02:00` for Brussels.
`parse_date` then normalizes that to UTC-naive `2026-03-31 22:00:00`
(see https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/tools/date_utils.py#L196-L199).
When the ORM compares this to the `fields.Date` column `date` it
truncates via `datetime.date()` (see
https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/orm/fields_temporal.py#L138-L158),
yielding `2026-03-31`. The effective domain becomes
`[2026-03-31, 2026-04-30)` instead of `[2026-04-01, 2026-05-01)`,
which is why March 31 leaks in and April 30 disappears.

Solution
Anchor the filter to `today` instead of the implicit `now`. The DSL
documents `today` as a starting point that yields a `date` value (see
https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/tools/date_utils.py#L108-L144),
so `today =1d` resolves to the first of the month as a calendar date
end-to-end and never goes through the tz-aware datetime → UTC-naive
roundtrip that was silently shifting the window.

opw-6123753

Forward-Port-Of: odoo/odoo#260727

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

**Issue 1:**

Steps to reproduce:
- Install the `l10n_ar` module.
- Go to Customers and create a new customer with the country set to Argentina.
- Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`.

**Error:**
`ValueError: invalid literal for int() with base 10: '1234567890a'`

**Issue 2:**
- Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`.
- Set `Identification Number` to `1234567890a`.

**Observation:**
All non-digit characters are stripped, and the identification number is 
silently changed to `1234567890`.

**Expected behaviour:**
Any Identification Type other than CUIT (80), CUIL (86), and DNI (96)
should be kept unchanged without stripping alphabetic characters.

**Root Cause:**
At [1], `_get_id_number_sanitize` sanitizes identification numbers
based on the selected Identification Type.

- For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes 
  separators (e.g., spaces and dashes). If the identification number
  contains alphabetic characters, they are preserved and called `int()` 
  on the resulting value, raising a `ValueError`.
- For all other identification types, valid alphanumeric values are
  unintentionally modified by stripping non-digit characters.

**Fix:**
This commit validates identification numbers before sanitization for
`CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric
identification numbers are converted. For all other identification
types, it preserves alphanumeric characters by removing only
non-alphanumeric separators.

[1]:
https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136

Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729

opw-6333998

Forward-Port-Of: odoo/odoo#272651

Steps to reproduce:
==================
1. Add a Donation snippet on a page
2. Click "Donate Now"
3. Switch the website language on the payment page

=> Configured amounts/descriptions disappear

Cause:
======
The donation snippet posts its configuration (prefilled amounts, display options, descriptions) in the request body. If the user switches the website language on the payment page, it triggers a page reload via a GET request which drops the original form body (this also applies to a simple page refresh). As a result, the kwargs were empty and the page fell back to the default free-amount input, losing the configured options.

Solution:
=========
Implement Post/Redirect/Get: on POST, redirect to /donation/pay with the options in the query string so any later GET (language switch, refresh, iframe src reload) re-renders a fully configured page without losing data.

Alternative Solution:
=====================
We could also store the options in the session, but the current solution is much simpler and avoids session pollution.

opw-6282391

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

Forward-Port-Of: odoo/odoo#271460

Replaced two `useLayoutEffect` calls in `useInputHook` with OWL3 native APIs (`useListener`, `onMounted`, `onPatched`), since `useLayoutEffect` is deprecated in OWL3. The caller `GridCell` was updated to use `signal.ref()` instead of the compat `useRef`.

The first effect attached `input`/`change`/`keydown` listeners to `inputRef.el` — a textbook `useListener` case. However, the compat `useRef` from `@web/owl2/utils` silently untracks the underlying signal on `.el` access, so `useListener(() => inputRef.el, ...)` never re-ran after mount and no listeners were attached. The fix passes the signal ref directly (`useListener(inputRef, ...)`) and upgrades the caller to use `signal.ref()` passed explicitly to the hook. The second effect (bare `useLayoutEffect` re-syncing the DOM value on every render) maps directly to `onMounted` + `onPatched`.

The `useLayoutEffect` refactored in this PR had test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- `@web_grid/grid_view/grid_view_desktop/editing a value`
- `@web_grid/grid_view/grid_view_desktop/Edition navigate with tab/shift+tab and enter key`
- `@web_grid/grid_cells/float_time_grid_cell/FloatTimeGridCell in grid view`
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624595/build/116553684

Issue:
In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This occurs regardless of the active company or the company associated with the record the attachment is linked to.

Steps to reproduce:
In a multi-company setup, activate only Company B. Open any chatter and attach a file.
Navigate to Settings > Technical > Data Structure > Attachments.

Current behaviour:
The created attachment has its company_id set to the user's default company, rather than the currently active company, or the company of the record, even when the record has a company_id field. This behavior introduces inconsistencies in data visibility, particularly when attachments appear to belong to a company different from the one associated with the related business record.

Behaviour After Fix:
If the related record (i.e., the model the attachment is linked to) contains a company_id field, its value will be used as the attachment's company_id otherwise, the attachment's company_id will be set to the currently active company's id.

This logic ensures proper alignment between attachments and their related business records and also maintaining consistency in multi-company scenarios.

task-4563173


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

Steps to reproduce:
- Go to the Website app and enter Edit mode.
- Drop an 'Embed Code' snippet onto the page.
- Paste an external embed code (e.g., an Instagram iframe or YouTube video).
- Change the alignment of the snippet to 'Center' or 'Right' using the editor options. Observation: The embedded content remains left-aligned regardless of the alignment option selected.

Cause:
Embedded elements (like iframes or injected scripts) do not inherently respect the parent's 'text-align' properties, and standard auto-margins fail if the injected element behaves as an inline block without a defined width.

Solution:
Update '000.scss' to apply Flexbox properties to the '.s_embed_code_embedded' wrapper. By using 'align-items' (center, flex-start, flex-end) corresponding to the parent snippet's alignment classes, the embedded content is forced to respect the chosen UI alignment. Additionally, apply 'max-width: 100%' to child elements to ensure responsiveness and prevent overflow.

opw-5429966