*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607

Forward-Port-Of: odoo/enterprise#109612
Forward-Port-Of: odoo/enterprise#107438

When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views).

Steps to reproduce:
1. Create a bill of materials for a final product
2. Add a consumable component
3. Create an operation without steps
4. Add a by-product tracked by serial number
5. Specify that the by-product is produced in the operation above
6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves"
7. Create a manufacturing order for the BOM and confirm it
8. Open the Shop Floor view from the MO
9. Observe the extra line for the by-product in both overview and work center views

Root cause:
The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button.

Solution:
Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled.

Task-5431295

Forward-Port-Of: odoo/enterprise#109689
Forward-Port-Of: odoo/enterprise#103260

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#109510
Forward-Port-Of: odoo/enterprise#105969

When a workspace(folder) linked to a folder setting is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``documents_account`` module
- Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save >
- Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save
- Go to Documents > Click on Workspace A > Actions > Move to trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint
"documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting"
```

solution:
override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings,
preventing their deletion during the garbage collection.

sentry-7193540869

Forward-Port-Of: odoo/enterprise#109636
Forward-Port-Of: odoo/enterprise#104875

## Short functional explanation of the error
When a candidate is refused, an email isn't sent to their email address.

## Reproduction Steps
1. Open Mailhog in a separate tab.
2. Go to the Recruitment app and select any job position.
3. Click on new to create a new application. Enter an applicant name and an applicant email.
4. Check Mailhog: a job application has been sent to the applicant.
5. Go back on the Recruitment app and click on Refuse. In the wizard, make sure you toggle Send Email and click on Refuse.

### Expected behavior
In Mailhog, a refusal mail has been sent to the applicant.

### Unexpected behavior
Nothing is sent.

## Origin of the issue
When refusing a candidate, we create a notification in the chatter but an email isn't sent. This is due to the `incoming_email_to` field, which is checked here:

https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4040-L4053

but because this field is already retrieved here:
https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4025 the last condition will always be true, preventing the recipient's data to be added to the message, thus preventing the message to be sent correctly.

Note: as of 19.0, the field `outgoing_email_to` can be used to determine the recipient's email address.
Note: we remove `'body_is_html': True` because this field
is misused in this case: when set at true, the field is always
considered as HTML
__
opw-5980079

Forward-Port-Of: odoo/odoo#252036

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c7598b3a3e [REL] 19.1.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f59db40bd3 [FIX] Dynamic pivot: header alignment [Task: 5922279](https://www.odoo.com/odoo/2328/tasks/5922279)
https://github.com/odoo/o-spreadsheet/commit/1103dcbea7 [FIX] chart-panel: reset when changing panel [Task: 5926661](https://www.odoo.com/odoo/2328/tasks/5926661)

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>

**Steps to reproduce:**
- Create a combo, set the free and max to 3
- Create the product combo and set it's price to 50
- Go to PoS, order said combo and chose the same product 3 times
- The price is 49.98 instead of 50

**Problem:**
When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50.

**Why the fix:**
This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines.
In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. 

The solution would be to take the line's qty into account when computing how much we should subtract.
Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend.

The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. 
This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them.
As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered.

opw-4931215

Forward-Port-Of: odoo/odoo#247995
Forward-Port-Of: odoo/odoo#221189

## Issue:
Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees.

## Steps to reproduce:
1. Connect to Outlook and Sync for user A.
2. Create a recurring event from Outlook.
3. Connect into a user B with access to the event and edit all the events from the series.
4. Run the scheduled action to sync user A.
5. Many emails are going to be sent to the attendees from Outlook.

## Solution: 
With the current implementation, we are going to avoid editing for the users connected to Outlook, however any user with the access to that event in Odoo and that it has not synced with Outlook is going to be able to edit the event. To avoid this, we should check if the event is recurring and it has been created from Outlook, for this we are going to be looking for the event `microsoft_recurrence_master_id` which will be available only for the recurring events created from Outlook.

opw-4374503

Forward-Port-Of: odoo/odoo#252079
Forward-Port-Of: odoo/odoo#199663

Because a timeout in js only ensures to wait at least for that
amount of time while giving no upper bound to the actual awaited
time, it was possible for advanceTime(100) to actually wait for
more than 300ms when the runbot was slow enough. In that case,
since enough time has elapsed between the action and checking that
the toolbar hadn't opened yet, well it was actually already opened,
since we had waited too much, and the test failed non-deterministically.

This is actually a special case here. Usually we want to use `waitFor`
or `expectElementCount` with the toolbar since it's a popover and is
therefore affected by [1]. But we cannot use them to check if the
toolbar hasn't opened too early, lest we find ourselves with the same
problem than explained above. Using only advanceTime with a timeout of
100ms and a synchronous `expect` check ensures that, in the general
case when the runbot is fast, the test will fail in case of a regression,
since there would have been ample time to have multiple animation
frames during 100ms. The regression will only be hidden when the
runbot is very slow and no animation frame has happened during the
100ms timeout, which is an acceptable tradeoff.

The same issue appeared in another test so I fixed it as well.

Timeouts throughout this test file were excessive, with multiple uses
of `advanceTime(500)` while OPEN_TOOLBAR_DELAY is 300ms. This is because
the commit dates from before [1] and so it was hard to ensure that
enough time and animation frames had passed before we could check with
`expect`, which is synchronous. Now we are using `expectElementCount`,
which uses `waitFor` under the hood which has a proper mechanism to wait
for enough animation frames with an  additional internal delay. With
these, there is no more need for a manual timeout to exceed the value of
OPEN_TOOLBAR_DELAY. Note that this only applies to the cases where we
check that the toolbar should be displayed, since cases where it should
NOT be displayed before a certain timeout should NOT use those utils,
as explained above.

runbot-238562

[1]: https://github.com/odoo/odoo/commit/54da715df84789f9a1acc0cfc91be41dcdbab140

Co-authored-by: Sébastien Geelen <sge@odoo.com>

Forward-Port-Of: odoo/odoo#247551

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.


opw-4879481

Forward-Port-Of: odoo/odoo#252062
Forward-Port-Of: odoo/odoo#245741

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.

Forward-Port-Of: odoo/enterprise#109571
Forward-Port-Of: odoo/enterprise#105521

*:{sale_,}stock, mrp_subcontracting

### Sate of the art:

Since the refactoring of 19.0 removing the procurement groups and introducing stock references  2713876dbc70d3984e584a9037a2206dcda4e84a, the `partner_id` is not propagated in pull flows. While the following fix 3bd213c24536fa6d40a7d7a44d4c553947f82c84 addresses some of these propagation issues, it only propagates the partner in case of a move chain for mto moves generated by mto rule. The current PR addresses some of the mtso use cases such as the mtso multi-step pull delivery and the mtso resupply subcontractor on order.

## 1. mtso multi-step pull delivery

### Steps to reproduce:

- In the settings enable: Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in deliveries in 3 steps
- Inventory > Configuration > Warehouse Management > Routes
- Modify you 3 steps Delivery (pick, pack, ship) route:
    - Change the rules to be in pull Stock -> Pack -> Out -> Cust
    - Change the rules: Pack -> Out -> Cust to be in mtso and not mto
- Create and confirm a sale order for a partner A
- The pick, pack and ship should be created
#### > The delivery partner (contact) is only set on the ship

### Cause of the issue:

As the route has been modified to be handled by pull rules, it is generated from end to start by subsequent move confirmations. However, as, the pull rules Pack -> Out -> Cust are in mtso, the associated moves will be created with a `make_to_stock` `procure_method`.
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_rule.py#L304-L305
Hence, when a procurement is created because of the `mts_else_mto` rule in the `_action_confirm`, the procurement will not set any `move_dest_ids` nor `partner_id`:
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1549-L1552
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1688-L1690
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1699
In other words, the pick and pack moves will not be part of a move chain (with `move_dest_ids`), and the `partner_id` is not propagated.

While the move chain `move_dest_ids` propagation is indeed only intended for mto moves (created by mto rules) since the mtso refactoring: a72382063ee662010729d983fbf6fb6305b8adf2 the `partner_id` should be propagated for pull rule in `mts_else_mto` to avoid losing the delivery partner that used to be propagated by procurement groups which were removed in 19.0 by 2713876dbc70d3984e584a9037a2206dcda4e84a Since the associated fix: 3bd213c24536fa6d40a7d7a44d4c553947f82c84 the `partner_id` can now be propagated via the `procurement_values` but is currently only propagated in case of mto moves:
https://github.com/odoo/odoo/blob/5143840911e1f05be3f5f5c7fa786f05e4966312/addons/stock/models/stock_move.py#L1699

## 2. Resupply subcontractor on order

### Steps to reproduce:

- In the settings enable: Multi-Step Routes, Subcontracting
- Inventory > Configuration > Warehouse Management > Routes
- Set the rule of the "Resupply Subcontractor on order" route to mtso
- Create a subcontracting bom for a finished product (FP) with a storable
  component (comp) for subcontractor: Bob
- Create and confirm a PO for 1 unit of FP with Bob as vendor
#### > Bob is not set as delivery contact on the resupply delivery for comp

### Cause of the issue:

When the rule is in MTO, so is procure method of the move raw for comp in the subcontracted MO. As such, the procurement generated at its confirmation will provide a `move_dest_ids`:
https://github.com/odoo/odoo/blob/c2cb705c078015bff0bc673e83a205d7657918e0/addons/stock/models/stock_move.py#L1688-L1698
which allows to propagate the subcontractor once the procurement is run because of these lines:
https://github.com/odoo/odoo/blob/c2cb705c078015bff0bc673e83a205d7657918e0/addons/stock/models/stock_rule.py#L307
https://github.com/odoo/odoo/blob/37c787ed7ca129bbccd02a073b1e03729b22c2b8/addons/mrp_subcontracting/models/stock_rule.py#L15-L20
In the present case, since the rule is in mtso, the `procure_method` of the raw move will be mts and the `move_dest_ids` will not be propagated. So that `partner_id` is never set as the subcontractor.

### Note about the fix:

When the rule `procure_method` is `mts_else_mto`, at the time we enter override of the `_get_stock_move_values` of `mrp_subcontracting`:
https://github.com/odoo/odoo/blob/37c787ed7ca129bbccd02a073b1e03729b22c2b8/addons/mrp_subcontracting/models/stock_rule.py#L15-L20
the only reference to the subcontractor is the one contained in the `production_ids` of the `reference_ids` of the procurement values which does not look like a reliable link as:
- Multiple `reference_ids` could be set in the values of the procurement
- Multiple `productions_ids` could be linked to the `reference_ids`
- Without the link to the subcontracted move raw nothing indicates that we trigger the creation of a move destined for a subcontractor

By contrast, the current proposition rely on the move that should have been set as `move_dest_ids`in the mto flow and mitigate these uncertainties.

opw-5402407
opw-5883477

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

Forward-Port-Of: odoo/odoo#250307

Before this commit, when using the full composer and accidentally closing it with some content, the composer content was recovered on the basic composer and formatting was lost.

This happens because restore of content only works in the basic composer, and basic composer does not support rich HTML like the full composer.

This commit adds a new UX/UI to restore formatting when accidentally leaving the full composer:

When some content has been restored from full composer, opening the chatter composer momentarily disables everything but the full composer button, in addition to show a popover suggesting the user to decide to either continue with Full Composer and restore formatting, or restore content in the small composer without the formatting.

Most of the time people want to restore formatting from the full composer, but at the same time the full composer can be a frustrating experience that may incite to just continue with the more reliable small composer. This new popover support both use-cases.

Task-5910961

<img width="1219" height="175" alt="Screenshot 2026-02-26 at 17 28 06" src="https://github.com/user-attachments/assets/13d8e1ca-4186-445e-8422-a14c31f8570f" />

Forward-Port-Of: odoo/odoo#247245

Steps to reproduce the issue:
- Create a storable product P1 with the following BoM:
    - A component consumed in an operation.

- Create a MO to produce one unit of P1 and confirm it.
- Modify the BoM so that the component is no longer consumed in the operation.
- Update the BoM on the MO.
- Start and finish the operation.

Problem:
The MO cannot be closed because the component is not consumed.

The `manual_consumption` field on the stock move is set to True when the move is linked to a BoM line consumed in an operation. However, when the BoM is modified so that the component is no longer consumed in the operation, this field should be updated to False when the MO is updated from the BoM.

https://github.com/odoo/odoo/blob/1305c7262fff762c00159377a9ce1ca09d423625/addons/mrp/models/mrp_production.py#L1193

https://github.com/odoo/odoo/blob/1305c7262fff762c00159377a9ce1ca09d423625/addons/mrp/models/stock_move.py#L611-L612

opw-5993652

Forward-Port-Of: odoo/odoo#251796

[FIX] hr: fix job title search access error

Bug reproduction: Select marc demo -> employee app -> try to search something for job title -> Access error appears for no hr ones
Bug cause: Only users/managers can access to hr_version model and since marc demo has not, it receives this error.
Bug solution: I put store=True and compute_sudo for job_title and by that way everyone can search for job_title without access.

In the task [MOHF] showed another traceback about job title search. I fixed that in this commit as well.

Bug 2 reproduction: employee app -> try to search something for resume -> it will give error (there is no version_ids)
Bug 2 cause: There is no version_ids in the employee.public model, in the search version_ids.job_title is used but job_title can be used directly.
Bug 2 solution: I used job_title in the search instead of using version_ids.job_title.

task - 6000488

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

**Steps to reproduce:**
* Install `Accounting` module.
* Create an invoice with enough lines to span multiple pages.
* Print the invoice to PDF (or use the 'Print' action).

**Observed behavior:**
* On the second page (and subsequent pages), the invoice table rows overlap with the company header (logo, address).
* This regression was introduced in saas-19.1 after the flexible document layout refactoring (commit).

**Cause:**
* The invoice's main table (`o_main_table`) is wrapped in a `<div class='table-responsive-sm'>`.
* `table-responsive-sm` applies `overflow-x: auto` at narrow viewports, which creates a Block Formatting Context (BFC).
* In wkhtmltopdf's WebKit engine, a BFC container does not participate in normal page fragmentation. When the table spans multiple pages, the content bleeds into the next page without respecting the header spacing defined by `--margin-top` and `--header-spacing`.
* This causes the continued table rows (and any repeated `<thead>`) to render at the very top of the content area, overlapping with the page header.

**ref:**
https://github.com/odoo/odoo/commit/15697add5751181544fb61302ddb745a354a2935#diff-c85e75bc27fc841662ca0598c09a22670e0a0b4e5120815934c0a50999ff02bfR172
with this commit `table-responsive-sm` added to invoice pdf layout.

**Fix:**
* Add `overflow: visible` on the `table-responsive-sm` wrapper div to prevent the creation of a scroll container / BFC.
* This ensures wkhtmltopdf can properly fragment the table across pages and respect the header spacing on all pages.

**Before:**
<img width="874" height="250" alt="image" src="https://github.com/user-attachments/assets/2da0a82a-abc9-49d6-9788-c8e89283e4b2" />

**After:**
<img width="872" height="256" alt="image" src="https://github.com/user-attachments/assets/cd38b7e3-b2b6-4c03-a1d8-5ac31cad0925" />


opw-5949713

**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body

**Issue:**
Default table style used for the inline conversion of 
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.

This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.

Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0

**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.

Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).

Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.

opw-5218581

Forward-Port-Of: odoo/odoo#251863
Forward-Port-Of: odoo/odoo#242001

This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate).

Current behavior:
Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices.

New behavior:
The XML generation logic has been updated to follow the specific codification required for OSS operations:

1. Invoice Lines (`DettaglioLinee`):
   - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state).
   - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other).

2. Tax Summary (`DatiRiepilogo`):
   - The original foreign tax lines are excluded from the summary.
   - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories.

Implementation details:
- Added `_l10n_it_is_oss_tax` helper to identify OSS taxes.
- Modified `_l10n_it_edi_get_line_values` to split OSS lines.
- Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary.

task-4711509

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#252216
Forward-Port-Of: odoo/odoo#243740