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

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

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