**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

Forward-Port-Of: odoo/odoo#246699
Forward-Port-Of: odoo/odoo#246084

**Problem:**
when there is multiple pages for the avco reports
the total value and quantity are not correctly computed

**Steps to reproduce:**
- create an avco storable product with a cost of 10
- create and validate 3 in moves for a quantiy of 1 each
- navigate to Inventory/ Stock and search your product
- click on the unit cost
- (see how the total quantity is 3 and total value is 30)
- change the view to display only the first 2 records
(write 1-2/4 on the top write)

**Current behavior:**
the total quantity is now 2 and total value 20

**Expected behavior:**
it should still be 3 and 30

**Cause of the issue:**
inside _compute_cumulative_fields, we start with a 
total_value and total_quantity of 0, then those variables 
are increased or decreased by each record in records
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L94-L104
but records is computed based on self which contains
the lines displayed on the view
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L91

**fix**
I need to add an if statement to avoid writing on the records
not displayed on the view because this causes an access_error

opw-5421925

Forward-Port-Of: odoo/odoo#244070

### Steps to reproduce:

- In the settings enable: Batch, Wave & Cluster transfers
- Inventory > Configuration > > Warehouse Management > Operation types
- Enable Auto-batches, Batch grouping by partner on Delivery orders
- Create and confirm a delivery for 2 units of a storable product that you do not have in stock.
- Change the quantity of the move to 1 unit
#### > The delivery is not auto-batched

### Expected behavior:

As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver.

### Cause of the issue:

The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow:
First at confirmation:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`.

opw-5441718

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

Forward-Port-Of: odoo/odoo#246164
Forward-Port-Of: odoo/odoo#245542

Steps to reproduce:
-------------------
1. Install sale_management with demo data
2. Create a new quotation/order and add a section and a subsection
3. Drag the subsection line above the section line
4. Confirm it and click on Preview

Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>

Error while rendering the template:
    AttributeError: 'NoneType' object has no attribute 'collapse_prices'
    Template: sale_subscription.subscription_portal_content
    Reference: 1713
    Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
    Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
    From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
          (1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
          (1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```

Cause:
------
Since current_section is None in this case, it leads to the
above traceback when trying to fetch the collapse_prices value.

Solution:
---------
Convert subsection lines without a parent_id into section lines
to prevent the traceback.

Related enterprise PR: https://github.com/odoo/enterprise/pull/103686


opw-5367739





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

Forward-Port-Of: odoo/odoo#241634

Steps to reproduce:
-------------------
1. Install sale_subscription with demo data.
2. Create a new subscription and add a Section and a Subsection.
3. Add a recurring product (Invoice_policy = 'order') and configure a recurring plan.
4. Confirm the subscription and click Preview.

Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>

Error while rendering the template:
    AttributeError: 'NoneType' object has no attribute 'collapse_prices'
    Template: sale_subscription.subscription_portal_content
    Reference: 1713
    Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
    Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
    From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
          (1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
          (1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```

Cause:
------
`_get_invoiceable_lines` does not treat subsection lines as children of their parent section.
As a result, `lines_to_report` contains a subsection without its corresponding section,
leaving current_section set to None and causing the traceback when accessing current_section.collapse_prices.

Solution:
---------
Ensure subsection lines are appended together with their parent section
when an invoiceable line is encountered

Related community PR: https://github.com/odoo/odoo/pull/241634

opw-5367739

Forward-Port-Of: odoo/enterprise#103686

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Forward-Port-Of: odoo/odoo#244758
Forward-Port-Of: odoo/odoo#238989

Steps to reproduce:
===================
1- Drop the block tab snippet
2- Inside one of the tab panes, drop a Columns snippet.
3- Select background_color for one of the columns
4- Change tab style to tab

-> The background color of the inner column is overridden.

Cause:
======
When the "Tabs" snippet style is set, a `.card` class is added to its container (See [1])
A generic CSS rule, intended to style these tabs, was targeting any `.card` element with a `.card-body` child. (See [2])

However, the Columns snippet also uses a `.card > .card-body` structure (distinguished by a `data-vxml` attribute). This caused the overly broad tab-styling rule to incorrectly cascade and override the background color of the nested column.

Solution
========
The SCSS selector has been made more specific so that works if `card-body` class doesn't have any parent class with class `card` and has attribute `data-vxml`

[1]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/website/static/src/snippets/s_tabs/options.js#L149
[2]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/web/static/src/scss/bootstrap_review_frontend.scss#L55

opw-5394480

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

Forward-Port-Of: odoo/odoo#241118

Current behavior:
When a user selects multiple filters (attributes) that result in multiple pages of products, navigating to the second page causes some filters to be lost. Specifically, only the last selected attribute value is kept in the URL of the pager.

This happens because the `/shop` controller processes query parameters using a standard Python dictionary (**post). Since a dictionary cannot hold duplicate keys, an URL like `?attrib=1&attrib=2` is reduced to `{'attrib': '2'}`, losing all previous values.

Steps to reproduce:
1. Install `website_sale`.
2. Reduce "Products per Page" (e.g., to 4) to easily trigger pagination.
3. Go to the /shop page.
4. Select a first attribute (e.g., Color: White).
5. Select a second attribute (e.g., Size: M).
6. Ensure the result spans at least two pages.
7. Click on page "2".
8. Observation: The second attribute filter is lost, and the product list changes incorrectly.

Fix:
Ensure that `attribute_values` are stored as a list within the `url_args` passed to the pager. Since Odoo's `website.pager` uses `url_encode` internally, passing a list of values for a single key correctly generates repeated parameters in the resulting URL (e.g., `attrib=1&attrib=2`).

opw-4152637

Forward-Port-Of: odoo/odoo#245784
Forward-Port-Of: odoo/odoo#244941

Before this PR there was a contrast issue between disabled and active secondary buttons in the action dialog.
This was due to a customization where the `btn-secondary`'s default background color was lightened.

To fix this, we used the same lighter background color for disabled `.btn-secondary`, reduced the opacity of its text and desaturated tho whole button for whenever there is color such as the "reward" button. This way we can distinguish between the two states.

A border was added to `.btn-secondary` in order to make the button more visible in light-challenging situations (in broad daylight for example).

task-5186928

| Before | After |
| ------------- | ------------- |
| <img width="1002" height="647" alt="Screenshot 2025-11-06 at 13 17 27" src="https://github.com/user-attachments/assets/cc63d6e1-8587-427e-b5cd-de99e96df8c0" />|<img width="1004" height="645" alt="Screenshot 2025-11-06 at 12 58 07" src="https://github.com/user-attachments/assets/f199fd94-1223-4c6b-869b-e8d66d99bc82" /> |



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

Forward-Port-Of: odoo/odoo#232969

Before this commit, the channel member actions were hard to find:
- Click on Members panel.
- Click on Member to open popover card.
- Click on "..." in top-right corner of card.

This is hard because only this avatar card from this menu has the "..." button, and the actions are hidden in this menu. This is easy to miss since avatar cards in message list or other places don't have this "...", and since the actions are hidden there many people could easily miss these actions.

This commit improves the visibility of action by their showing as a "..." on the member item on hover in the "Members" panel. This works like the "..." button in the discuss left sidebar, where the button is shown on mouse-hover. Mobile view (small or mobile device) shows the button all the time next to member, making the discoverability of the action very clear.

Task-5871730

Before / After
<img width="589" height="385" alt="Screenshot 2026-01-23 at 14 45 17" src="https://github.com/user-attachments/assets/bca66975-13cd-423a-a43d-9eb2be03741a" />
<img width="249" height="270" alt="Screenshot 2026-01-26 at 11 56 09" src="https://github.com/user-attachments/assets/edfe34c9-6b4c-4394-b532-7f79f9653b4a" />


----

This PR also makes channel member actions available in guest items, so we can now "Remove Member" on guests too.

<img width="252" height="296" alt="Screenshot 2026-01-27 at 18 25 54" src="https://github.com/user-attachments/assets/ee4b1271-0529-4e96-bda1-e621d7592555" />

Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.

opw-5496999
opw-5401425

Forward-Port-Of: odoo/odoo#244052

_______________________________________
## Short functional explanation of the error
Let's say we have a products that has 2 suppliers. In the list of suppliers, the first one set has an expired date. If we generate a PO from an SO with the MTO route, the assigned supplier for this product will be the first one set in the list, therefore having an expired date.

## Reproduction Steps
1. Go to Inventory > Configuration > settings. Check the option Multi-Step routes.
2. Click on Configuration > routes and unarchive the Replenish On Order (MTO) route.
3. Create or use an already existing product. Go to the Inventory tab, and under Operations, check the routes Replenish on Order (MTO) and Buy.
4. Click on the Purchase tab. There, set a first vendor for which the end date is earlier than today. For the second one, set an end date for which the date is later than today.
5. Go to Sales and create a new quotation. Set a customer and add a line with the product you just set. Click confirm. A smart button 'Purchase' should appear. Click on it.

### Expected behavior
The assigned vendor of the PO should be the second vendor as it isn't expired yet.

### Unexpected behavior
The assigned vendor is the first vendor, expired.

## Origin of the issue
When generating a PO from an SO, the partner is the person ordering the product, not the vendor. Therefore, when this code is executed:

https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L62-L66

no corresponding supplier is found, as
```self._get_partner_id(procurement.values, rule)``` returns the customer
and not the vendor. This leads us to the fallback:
https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L68-L72
which doesn't take into account the end date of vendors.

__
opw-5030849

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#245313
Forward-Port-Of: odoo/odoo#225684

Description of the issue/feature this PR addresses:

Fixes timer not showing to participants of a live session after submitting an answer.

Current behavior before PR:

Steps to reproduce:

Create a Survey with two questions of any type.
Set some Question Time Limit on both.
Create Live Session for that Survey.
Access Live Session as a participant.
Start Survey as the host.
The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question.
Bug: timer for the second question does not appear to the participant.

Desired behavior after PR is merged:

Fix:
The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function.
Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function.
This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress`
and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'`
Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received.

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

Forward-Port-Of: odoo/odoo#246147
Forward-Port-Of: odoo/odoo#241086

Steps to reproduce:
===================
1- Drop the block tab snippet
2- Inside one of the tab panes, drop a Columns snippet.
3- Select background_color for one of the columns
4- Change tab style to tab

-> The background color of the inner column is overridden.

Cause:
======
When the "Tabs" snippet style is set, a `.card` class is added to its container (See [1])
A generic CSS rule, intended to style these tabs, was targeting any `.card` element with a `.card-body` child. (See [2])

However, the Columns snippet also uses a `.card > .card-body` structure (distinguished by a `data-vxml` attribute). This caused the overly broad tab-styling rule to incorrectly cascade and override the background color of the nested column.

Solution
========
The SCSS selector has been made more specific so that works if `card-body` class doesn't have any parent class with class `card` and has attribute `data-vxml`

[1]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/website/static/src/snippets/s_tabs/options.js#L149
[2]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/web/static/src/scss/bootstrap_review_frontend.scss#L55

opw-5394480

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

Forward-Port-Of: odoo/odoo#241118

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#105405
Forward-Port-Of: odoo/enterprise#100749

_
## Short functional explanation of the error
When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>"

## Reproduction Steps
1. Install the app l10n_ch_hr_payroll.
2. Make sure you use a Swiss company.
3. Go to Payroll and click on the Payslips tab > payslips.
4. Click on Pay Run. Select Switzerland: ELM salaries and click Continue.
5. Select an employee for which you'd like to generate the payslip.
6. Click on the employee row in the list view.
7. Click Compute sheet > Print.

## Expected behavior
A PDF with name "Salary Slip - <employee name> - <time period>" is generated.

## Unexpected Behavior
A PDF with name "new Payslip" is generated.

## Origin of the issue
When printing the slip with this flow, we don't call the method
```_compute_name()``` used to compute the name of the current slip.
Therefore, it stays at 'New Slip', which is the default name.
Henceforth, we have to call this method manually when printing the
slip.
_
opw-5253811

Forward-Port-Of: odoo/enterprise#103471

**Steps to reproduce:**
* Install the **Accounting** and **partner_commission** modules.
* Create a contact and set a **commission plan (e.g. 50%)** in the *Partner Assignment* tab.
* Create and confirm a customer invoice with multiple lines (e.g. 750, 750).
* Then go to **Dashboard → Transactions**, create a new transaction (e.g. 750) and reconcile it with the created invoice.
* Create a **credit note** from the invoice and confirm it.
* Open the contact and access **Purchase Orders** from the stat button.

**Observed behavior:**
* Only the commission line from the original invoice appears in the partner purchase order.
* No **negative commission line** is created for the credit note.

**Cause:**
* Credit notes reused the original commission linkage instead of generating a dedicated commission entry.
* This prevented commission reversal from being recorded for refunds.

**Fix:**
* Generate a **separate commission line** with a negative amount for each credit note.
* Assign a dedicated `commission_po_line_id` to credit notes.
* Copy only the `referrer_id` to credit notes, not the original commission line reference.

opw-5357773

Forward-Port-Of: odoo/enterprise#103328

Steps to reproduce:
-------------------
1. Install sale_subscription with demo data.
2. Create a new subscription and add a Section and a Subsection.
3. Add a recurring product (Invoice_policy = 'order') and configure a recurring plan.
4. Confirm the subscription and click Preview.

Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>

Error while rendering the template:
    AttributeError: 'NoneType' object has no attribute 'collapse_prices'
    Template: sale_subscription.subscription_portal_content
    Reference: 1713
    Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
    Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
    From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
          (1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
          (1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```

Cause:
------
`_get_invoiceable_lines` does not treat subsection lines as children of their parent section.
As a result, `lines_to_report` contains a subsection without its corresponding section,
leaving current_section set to None and causing the traceback when accessing current_section.collapse_prices.

Solution:
---------
Ensure subsection lines are appended together with their parent section
when an invoiceable line is encountered

Related community PR: https://github.com/odoo/odoo/pull/241634

opw-5367739

Forward-Port-Of: odoo/enterprise#103686

Sending a voice message without any text can trigger a WhatsApp API error because the empty HTML body is incorrectly treated as a valid text message.

### Reproduction Steps

1. Open the Discuss app.
2. Select a WhatsApp channel.
3. Record and send a voice message without typing any text in the composer.
4. Observe the message status.

Result: The status changes from "Sent" to "Failed" with the error `(#100) The parameter text['body'] is required`.

### Cause

The WhatsApp API does not support captions for audio files. Messages containing both audio and text are split into two separate WhatsApp messages: one for the audio file and one for the text body.

Whether the text message is created depends on whether the message body is considered non-empty. Since commit
odoo/odoo@f4dcc83adf552466ba7b05f09a4c651fe69f18ff , the composer’s default content is an empty HTML element. Although visually empty, this HTML is still a non-empty string at the data level. As a result, the system incorrectly determines that a text message is required and creates a secondary `whatsapp.message` record.

When processed, the empty HTML is converted to a plain text string (`""`). Sending this as a text message fails validation because WhatsApp requires a non-empty body for text messages.

### Fix

1. Update `DiscussChannel.message_post()` to use `tools.is_html_empty(body)` to detect semantically empty HTML. This prevents creating a separate text message for audio attachments when the composer content is effectively empty.
2. Update `WhatsappMessage._send_message()` to check the truthiness of the converted plaintext `body` rather than the raw HTML field before adding a caption. This prevents sending an empty `caption` parameter for attachments when the body is empty.

opw-5266805

**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
 - The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice is automatically created and amount_paid is also updated.
- At [1], the logic subtracts both the total invoice amount and amount_paid from the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is encountered again, it should be skipped to avoid double-counting.

[1]https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime

**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.

This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`

**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.

related PR: https://github.com/odoo/odoo/pull/205594

opw-5245367

**Steps to reproduce:**
- Go to the current user preferences
- Go to its signature field
- The current state should be something like:
```
--
Mitchell Admin
```
- Apply bold formatting on the text
- Save the changes
- Refresh
- Remove the bold formatting
- Press enter between the two lines (at the end of `--`)
- Save the changes
- Go to the Contact app
- Select any record
- Go to its chatter
- Click on `Send Message` and then the `Full Composer` expand button
- Send the mail
- In the chatter multiple `Read More` are added for the same signature

(I think it can appears in multiple operations,
this is just an example related to the `<strong>`
element becoming `<span>` on removal)

**Issue:**
Playing with the html editor on the signature field can break the `tag_quote` flow due to the added elements.

**Fix:**
Explicitly add `"data-o-mail-quote"` to the signature container which is added when opening the `fullComposer`.
It could also be an issue related to the html_editor but this seems cleaner to fix it here.

This issue was fixed in 19.0 in a similar way by adding a common div around the signature and adding the same attribute.

related: https://github.com/odoo/odoo/commit/6eb55c42158b08652c4c533bf56b5333c162bd3a

opw-5149505

Steps to reproduce:
-------------------------
1. Install Timesheets and Time Off.
2. Create an employee and create a Time Off in the past week, then approve it.
3. Open All Timesheets for that employee and observe the overtime indicator.
4. Enable a multi-company environment by creating another company.
5. Remove the `company_id` from the employee’s working schedule (40h/week).

Issue:
----------
The overtime indicator shows an incorrect value.
It displays 40h instead of the expected 32h.

Cause:
----------
Since there is no company defined on the working schedule, `self.company_id.id` becomes False.
The actual leave records are linked with the employee’s company, so the search results
in an empty recordset. As a result, the employee leave is ignored.

Solution:
--------------
Take the resource company into account when building the domain,
before falling back to the calendar company.

opw-5499737




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

#### [FIX] account_edi_ubl_cii: `DeliveryParty` export

Follow-up to commit 0b3c12670e5f606a36e7d94982656ed998d67322

In the aforementioned commit we added the `DeliveryParty` node under
the `Delivery` tag.

But there are 2 remaining issues with it.
- In BIS 3.0 the `DeliveryParty` tag has only one child `PartyName` (which is mandatory)
  https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-Delivery/cac-DeliveryParty/
  This was done for the version with the new helpers (`account_edi_ubl_cii.use_new_dict_to_xml_helpers`)
  but not the version without the helpers.
- For UBL 2.0 the `DeliveryParty` tag was added for the version
  without the new helpers but not the version with the helpers.

That is fixed in this commit.

#### [FIX] account_edi_ubl_cii: export intrastat commodity code

Currently we do not export the intrastat commodity code of products.
But a field for it is available after installing `account_intrastat`.

After this commit the intrastat code is exported in the tag
`cac:CommodityClassification/cbc:ItemClassificationCode[@listID="HS"]`.

#### [FIX] account_edi_ubl_cii: update AllowanceChargeReasonCode for EPD

Currently we are using the code `66` ("New outlet discount") as
`AllowanceChargeReasonCode` for early payment discounts.
After this commit we use `64` ("Special agreement") since it seems
more fitting / general.

#### [FIX] account_edi_ubl_cii: BEG test cases: minimal invoice

This commit adds a test corresponding to the test case "Testcase01" / "Minimal invoice"
from the business expert group.

https://efacture.belgium.be/fr/article/business-expert-group-ressources

#### [FIX] account_edi_ubl_cii: BEG test cases: multi-currency

This commit adds the following nodes to the BIS 3.0 XML in case
the document currency is different from the company currency.
- `cbc:TaxCurrencyCode`: gives the company currency (it is supposed to
  be the currency in which the taxes for the invoice will be paid)
- A second `cac:TaxTotal` node that only contains a `cbc:TaxAmount` node
  giving the total tax amount in company currency / the currency specified
  by `cbc:TaxCurrencyCode`.

See here:
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_vat_accounting_currency

Some local formats had this information already. The logic was removed
there. The  affected modules were:
- `l10n_anz_ubl_pint`
- `l10n_jp_ubl_pint`
- `l10n_my_ubl_pint`
- `l10n_ro_edi`

See also here:
- https://docs.peppol.eu/poac/aunz/pint-aunz/bis/#_tax_in_accounting_currency
- https://docs.peppol.eu/poac/my/pint-my/bis/#_tax_in_accounting_currency
- https://docs.peppol.eu/poac/sg/2024-Q2/pint-sg/bis/#_invoice_totals_in_gst_accounting_currency

This is in line with the following test cases from the business
expert group. They were added as tests in this commit
(https://efacture.belgium.be/fr/article/business-expert-group-ressources)
- "Testcase 10": "Invoice in USD and EUR vat"
- "Testcase 11": "Invoice in USD and EUR vat and 2021"kkjkkj

#### [FIX] account_edi_ubl_cii: PaymentMeansCode from payment method

Currently the `PaymentMeans/PaymentMeansCode` node is filled
w/o considering the "Preferred Payment Method Line" (`preferred_payment_method_line_id`)
set on the move.
We choose
- for invoices: 30 ('credit transfer') or ZZZ ('mutually
defined') depending on whether a bank account is set.
- for bills: 57 ('standing agreement')

After this commit we use the Code of the Payment Method of the
"Preferred Payment Method Line" to determine the the PaymentMeansCode

We also add the following Payment Methods so that the user has more choices.
- Credit Card
- Debit Card
- Bankgiro
- Standing Agreement
- SEPA Credit Transfer

#### [FIX] account_edi_ubl_cii: BEG test cases: cash discount

Consier a paid invoice for which we granted an early payment discount.
in case the XML is generated after the invoice is paid (discounted amount)
we do not account for that fact in the XML generation.

The total amounts in the `cac:LegalMonetaryTotal` node are not adjusted
- The `cbc:TaxExclusiveAmount` and `cbc:TaxInclusiveAmount` and
`cbc:PrepaidAmount` should reflect the reduced amounts
- This is i.e. problmeatic for the `cbc:PrepaidAmount`. It would show
  the total (unreduced) amount of the invoice; more than was actually paid.

In the XML for an unpaid invoice there are
The `cac:AllowanceCharge` node(s) representing the potential early payment discount and
`cac:AllowanceCharge` node(s) raising the total back to the unreduced amount.
In case the early payment discount was applied the latter node(s) can
/ should be removed.

This is in line with "Testcase06" from the business expert group.
(https://efacture.belgium.be/fr/article/business-expert-group-ressources)
The following examples were added as tests in this commit
- "Testcase05": "Cash Discount" (not paid yet)
- "Testcase06": "Discount with cash payment" (XML generated after paid
and epd applied)

#### [FIX] account_edi_ubl_cii: sale order discount as AllowanceCharge

Global discounts from sales orders are just displayed as invoice
lines on the inovice.
Currently they are treated the same as any other invoice lines for
the XML generation.

But they should be displayed as an `AllowanceCharge` instead.
After this commit that is the case.
The `AllowanceCharge` node has
- `AllowanceChargeReasonCode`: `95`
- `AllowanceChargeReason`: `Global discount`

To add a global discount follow theses steps
1. Ensure `sales` is installed
2. Go to Settings -> Sales -> Pricing section and enable "Discounts"
3. On a Quotation / Sale Order there should now be a "Discount"
   right above the widget displaying the total amounts.
   Click it.
4. Select "Global Discount" and a percentage.
5. A line using a special discount product is added.
6. Click "Create Invoice"
7. The same line is now on the invoice

#### references
task-4885680

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

### Steps to reproduce

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

### Root cause

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

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

### Fix

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

opw-5401789