### Issue:

Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial.

### Concrete Issue 1:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Create and confirm a delivery for 5 units of P
4. Set the quantity of the move to 5 from the Form picking view > save
5. Create and set 2 lots: LOT1, LOT2 on the serial numbers field
6. Save
#### > The quantity of the move has been updated to 2, only the first lot is set and it has been for this quantity of 2

### Concrete Issues 2 and 3:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Update the onhand quantity of P:
    - 1 units of LOT001 in Shelf1
    - 2 units of LOT001 in Shelf2
    - 2 units of LOT002 in Stock
4. Create and confirm a delivery for 5 units of P
5. Remove LOT002 from the Serial numbers in the Form picking view > save
#### > The quantity of the move is updated to 1 (only the 1 unit of LOT001 from Shelf2 is kept)
5'. Remove LOT002 and put it back
#### > The quantity is updated from 5 to 2 if you save, only LOT001 is kept.

### Cause of the issue:

The `_onchange_lot_ids` and `_set_lot_ids` methods have been tailored to work appropriately only with `serial` tracking, updating the quantities considering a 1 to 1 quantity, lot matching:
https://github.com/odoo/odoo/blob/c9715982134220aa8fa525d0cf6a8d47eaeb6ed6/addons/stock/models/stock_move.py#L623-L645
However, for lot tracked product the situation is much more subtle to handle.

### Behavior after the fix:

Editing the `lot_ids` on tracked products should adapt the reservation following these rules:
- Existing move lines with a valid lot or lot name should be kept unchanged.
- Removing a lot should delete its related move lines and adjust the move quantity accordingly.
- Each newly assigned lot must be linked to at least one move line of the move.

If the move is expected to bypass reservation (e.g. receipts, final move of a production,...):
- Assignment should be performed, in priority, on an existing free move line.
- If no suitable free move line exists, a new move line should be created with the largest possible quantity that does not cause the total assigned quantity to exceed the move demand.
- If such a quantity cannot be assigned, the new move line should be created with a quantity of 1 in the product.uom_id.

If the move is expected to be reserved (e.g. internal transfer, deliveries,...):
- Each new lot should be assigned from an existing quants with the maximum available quantity to satisfy at best the remaining demand.
- If no available quantity can be assigned from existing quants, the lot should be assigned a minimum quantity of 1 in product.uom_id.

### Additional note on the fix:

Since move that do bypass reservation use a different detailed operation view relying on lot_names form move line rather than lot_id from existing quants it is important to set both the `lot_name` as well as the `lot_id` on move lines for the changes to be visible in the detailed operations view.

### Note:

The current fix populated records on which the `label_production_view_pdf` report was tested (by the test_report) highlighting a template error:
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/mrp/report/mrp_production_templates.xml#L187
The value provided to the t-field being something else than a field but rather an or close between two fields.


opw-6173914
opw-5881661

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

Forward-Port-Of: odoo/odoo#272253
Forward-Port-Of: odoo/odoo#263037

The previous memory profiler was causing a lot of performance issues.
This is because tracemalloc tracks the allocations that happens at the
python interpreter level by attaching to the cpython allocators. This
first meant each allocation that happens through python has to go
through a callstack while holding the GIL and preventing the thread and
other threads from operating. This callstack does multiple things,
first is walking the allocation back from the current frame up until
the specified frame depth at the start of collection. The other is
updating the internal object that keeps track of the allocations and
what cause them up until now which degrades the performance even more
when the allocator keeps running for a long time. Increasing the frame
depth also means the partitioning becomes even more fragmented in the
internal object and leads to higher memory usage. This in turns means
lower performance as well. The issue becomes more evident when the
overhead of tracemalloc blocks any execution even turning it off
because the gil cannot be released until the full allocation execution
happens.

Currently this would happen on long enough requests or a high enough
depth.

Two PRs were made to try to address this issue.

1- https://github.com/odoo/odoo/pull/251950 : This PR tries the
solution of having a lower frame depth but matching the frames based on
a window of frames so that we can reconstruct an approximation of the
flamegraph, for example: matching window of 2 frames
1 - > 2 - > 3 - > 4
2 - > 3 - > 4 - > 5
would mean that we would match frames 2 and 3 in both stack traces and
append the first frame to the second callstack which would look like
1 - > 2 - > 3 - > 4 - > 5
Neverthless this was deemed to have too big of an assumption in the
building heuristic.

2- https://github.com/odoo/odoo/pull/253120: This PR was supposed to be
introducing memray as a profiler. Memray is the best tool for this
usecase. First because it attaches on the native system allocation
calls, and uses a file to append to on allocations. This solves both of
the issues that we had in the beginning but the issue with memray is
that it's an external tool that was deemed unnecessary to add.

The final solution is this PR:
The PR assumes a heuristic that in worker mode, a single worker handles
one thread which mean that the process memory can be fully attributed
to the request. The heuristic is also based that on a high enough
sampling rate, the delta can be fully attributed to the current frame.
This is a close enough approximation to know where to look but not what
is the actual memory usage by line.

Forward-Port-Of: odoo/odoo#273424
Forward-Port-Of: odoo/odoo#253604

**Steps to reproduce:**
* Install the **account_peppol** and **l10n_be** module.
* Switch to BE Company.
* Create and confirm a BE customer invoice.
* Open the "Send & Print" dialog.
* Activate Peppol (register as a Peppol participant) in developer mode and demo mode by clicking on `Why should you use it ?` on the banner in wizard.

**Observed behavior:**
* An Uncaught Promise OwlError trace is thrown on the screen: `TypeError: Cannot use 'in' operator to search for 'toString' in null`.
* The success notification indicating that Peppol was activated fails to appear.

**Cause:**
* Upon successful registration, the `peppol.registration` wizard triggers a client action to display a success notification via `display_notification`.
* The backend Python code explicitly passed `title=None` in the notification parameters, which is serialized to `null` in the JavaScript frontend.
* In previous versions (like 19.2), the `Notification` component's `title` prop validation was defined loosely as `{ type: [String, Boolean, { toString: Function }] }`. OWL did not strictly validate this shape, allowing `null` to pass through without error.
* In 19.3, the prop validation was updated to strictly enforce the object shape: `{ type: [String, Boolean, { type: Object, shape: { toString: Function } }] }`. Because JavaScript evaluates `typeof null` as `"object"`, the OWL validation schema now attempts to verify the shape by evaluating `'toString' in null`. Using the `in` operator on `null` is illegal in JavaScript and immediately crashes the application.

**Fix:**
* Replace `title=None` with `title=False` in the `_action_send_notification` method.
* This translates to `false` in the JavaScript frontend, which seamlessly satisfies the `Boolean` prop type validation for the OWL component and allows the notification to render safely without errors.

opw-6333224

Forward-Port-Of: odoo/odoo#272974

*: mrp_subcontracting_{dropshipping, purchase}

### Steps to reproduce:

- In the settings: Enable subcontracting, dropshipping
- Create a storable dropshipped product FP with a set vendor for 5$ and subcontracting BOM: 1 X COMP. Value this product in avco perpetual
- Set the component to resupply subcontractor and standard price to 2$
- Create and confirm a sale order for 1 unit fo FP
- Validate the resupply to the subcontractor and then the dropship
> The FP standard price shoul dhave been updated to 5$ + 2$ = 7$
- Create and post a bill from the PO for 10$ rather than 5
#### > The FP standard price should have been updated to 11$ rather than 12$

Cause of the issue:

Posting the bill will call the `_set_value` method to re-evaluate the product in terms of the newly recorded `account.move`: https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/stock_account/models/stock_move.py#L393-L395 Now, the issue is that due to our config, there are two relevant moves linked to the `order_line`: the final move of the subcontracted production (which `is_in`) and the dropship move going from the subcontractor to the customer. When it comes to the subcontracted move, it is appropriately valuated at 12$ by the `_get_value_from_account_move` because of this override which adds the components value via the extra cost since the move has a `production_id`:
https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/mrp_subcontracting_purchase/models/stock_move.py#L14-L38 However, the dropship move will not add this extra cost (as no override sets it to have the same value as the subcontracted production it comes from) so that this move is valuated at 10$. This explains why the value of the avco product is then updated to 11$ since (12 + 10) /2 = 11

Note that the issue is not reproducible in the case of regular subcontracting since in that case the receipt from `subcontractor` to `stock` is not valuated.

opw-6318035

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

Forward-Port-Of: odoo/odoo#273137
Forward-Port-Of: odoo/odoo#272813

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

Issue:
----------------------------------------
The overtime calculation ignores attendances overlapping midnight when creating an attendance on the day they overlap.

Steps to reproduce:
----------------------------------------
- Have the standard 8 hours per day working schedule
- Use the default overtime ruleset:
    - Quantity, per day, more than the contract
    - Have no rule on weeks
- Create an attendance of 8+ hours overlapping midnight on a day:
    - From 10pm to 10am (2h + 10h = 12h)
- Create another attendance on the day the first ended:
    - From 2pm to 6pm (4h)
- The first attendance has 2h of overtime:
    - 0h from the first worked day (from 10pm to midnight = 2 < 8)
    - 2h on the next day (10h worked from midnight to 10am)
- The second attendance have 0h of overtime even though it should be 4h
    - We only considered this attendance in the calculation, ignoring the 10h worked in the morning

Cause:
----------------------------------------
In `_update_overtime()` we create a domain to include all useful attendances in the calculation. As all rules are based on days, the domain will use the date of the attendance to get overlapping attendances. But the date of the attendance is the date of its `check_in` ([src](https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/hr_attendance/models/hr_attendance.py#L91)). So when creating the second attendance, the domain only fetches attendance with their `date` on the same date as the `check_in` of the second one. This excludes the first one even though it overlaps on the same day.

Solution:
----------------------------------------
Don't use `date` but `check_in` and `check_out` in the domain to really get all attendances overlapping a day with an updated attendance.

As this domain was used on both `hr.attendance` and `hr.attendance.overtime.line`, we adapt it so it uses the correct fields (`time_start` and `time_stop`) from the overtime lines.

opw-6253777

Forward-Port-Of: odoo/odoo#272447

### Steps to reproduce:

- In the settings enable: Packages
- On the operation type `Delivery Order` set "Set Package Type"
- Create and confirm a delivery for 1 unit of a product P + reserve it
- Got to the barcode app to process the delivery
- Scan your product and click "put in pack"
#### > The put in pack wizard allowing you to set a package type on the new package does not pop up.

### Cause of the issue:

As a general rule of thumb the wizard is suppose to be displayed when the option is enabled and when a package/package type is not already provided to the call:
https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_package.py#L332-L341 https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_move_line.py#L1236-L1238 However an override was added to the barcode module so that the wizard is never displayed when the action is launched from the barcode app: https://github.com/odoo/enterprise/blob/673d449f38cd3eff27c44270c8f7edf91d0ecd02/stock_barcode/models/stock_move_line.py#L193-L196

The idea behind this override was that you could provide the package type id via scans and hence that is was not necessary. However, if you click directly on the put in pack button, the wizard still make sense and should therefore be displayed under the same conditions.

opw-6325092

Forward-Port-Of: odoo/enterprise#122308

### Summary

When `dev_mode` includes `reload`, `ThreadedServer`'s FSWatcher reacts to a file change by sending the process a `SIGHUP` to trigger a phoenix restart. `signal_handler` turns `SIGHUP` into `KeyboardInterrupt`, which `ThreadedServer.run()`'s wait-loop catches. The catch is too narrow — a reload `SIGHUP` can kill the process through **three** windows that all sit outside the wait-loop's `try/except`, so the exception escapes `run()`/`main()`. Under Docker's default `restart: no`, PID 1 dies and the container stays down.

### The three windows

1. **Teardown duplicate (exit 130).** One file change can emit several FS events; the FSWatcher's `if not odoo.phoenix:` dedup races across threads and fires more than one `SIGHUP`. The first begins the phoenix teardown; the second lands during `stop()` / `watcher.stop()` / `_reexec()` and `KeyboardInterrupt` escapes.
2. **Exec-gap (exit 129).** `os.execve()` resets caught signal handlers to their default disposition (`SIGHUP` terminates) but preserves `SIG_IGN`; a `SIGHUP` arriving after the exec but before the re-exec'd process re-installs its handler kills the process outright.
3. **Startup (exit 130).** In the re-exec'd process, a `SIGHUP` anywhere in the startup section that precedes the wait-loop — `start()`, `preload_registries()` **and** `cron_spawn()` — escapes `run()`.

### Reproducer (deterministic)

Boot a `ThreadedServer` (`--workers 0`) on any initialised db, then signal PID 1 a few times in quick succession:

```bash
docker exec <container> sh -c 'i=0; while [ $i -lt 8 ]; do kill -HUP 1; sleep 0.1; i=$((i+1)); done'
```

Unpatched the process exits 130 or 129. Patched it stays up after one clean phoenix reload. Verified live on 17.0 and 18.0: stock `server.py` dies; the patched `server.py` survives sustained bursts (20/20 across repeated reload cycles on each version); `SIGINT`/`SIGTERM` still exit 0.

### Fix

Minimal, in `signal_handler` + `run()` + `_reexec()`; `SIGINT`/`SIGTERM` untouched; one new instance attribute, no new module globals:

- **Teardown duplicate:** ignore a `SIGHUP` once `quit_signals_received` is set (a restart/shutdown is already pending; the re-exec reloads fresh code).
- **Startup:** a per-instance `in_preload` flag marks the entire startup section (`start()` + `preload_registries()` + `cron_spawn()`); a `SIGHUP` there sets the phoenix flag + counter and returns instead of raising, so the wait-loop exits right after startup and runs the normal restart.
- **Exec-gap:** `signal.signal(signal.SIGHUP, signal.SIG_IGN)` just before `os.execve` so a `SIGHUP` in the gap is dropped rather than terminating the process.

### Related

- #21209 (merged) — introduced the phoenix flag; did not guard these windows.
- #206898 (merged), #207930 (open) — PreforkServer reload.

### CLA

Covered by Codeforward B.V.'s corporate CLA; #269240 adds me to its contributor list (pending merge).

Forward-Port-Of: odoo/odoo#269247

## Current behavior:
In the Project's app, switch to Gantt chart's view, when changing the deadline of a single task by shrinking its right edge, the server throws `ValueError: max() iterable argument`` is empty when calling end_date = max(candidates.mapped(stop_date_field_name)).

## Steps to reproduce:
1. In version 19.0 and above, install Project app
2. Create a project and only 1 single task
3. Switch to Gantt chart view
4. Try changing the deadline of a task by dragging its right edge
5. Observe that extending the task's deadline by dragging to the right works fine, but shrinking the deadline by dragging to the left will cause server to throw RPC_ERROR: Odoo Server Error and ValueError: max() iterable argument is empty.

## Cause of the issue:
- A task with NO successors will cause candidates gathered via dependency_inverted_field_name to be empty.
- The empty candidates recordset then get called by max(candidates.mapped(stop_date_field_name)), which is the reason causing error message ValueError: max() iterable argument is empty.

opw-6283566

Forward-Port-Of: odoo/enterprise#120375

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

Issue:
Replacing an icon removes style classes applied to the original icon,
such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`.

This issue was introduced by [commit], which stopped preserving
image-specific classes when replacing an image with an icon. This
behavior is appropriate in the backend editor, where icons do not
support these styling options. However, the same logic also affected the
website builder, where icons support the same styling options as images.
As a result, these classes were unnecessarily removed when replacing an
icon.

Steps to reproduce:
1. Add an icon with style classes such as `rounded`, `rounded-circle`,
   `shadow`, or `img-thumbnail`.
2. Replace the icon.
3. Notice that the style classes are removed from the new icon.

Fix:
Preserve these style classes when replacing icons in the website
builder, allowing the newly selected icon to retain the existing visual
styling.

[commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab
task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832)

Forward-Port-Of: odoo/odoo#265496

### Steps to reproduce:

- In the settings Enable: Multi-steps Routes, Packages
- Put your warehouse in delivery in 2-steps
- On the Pick operation type in the barcode tab disable: "Allow extra products"
- Create two storable products P1 and P2
- On P2 > On hand > Update Quantity > New
- Create a new line in WH/Output with a package POOK for 1 unit
- Create a new internal transfer for 1 unit of P1 using the pick operation type so that the picking goes WH/Stock -> WH/Output
- Set the quantity of the move to 1 unit and go to the barcode app
- Open the Pick > Scan WH-STOCK > Scan P1 > Scan POOK
#### > An error is raised: This package contains extra products and extra products are not allowed on this operation.
#### Expected behavior:
The package should be set as result package.

### Cause of the issue:

In the `_processPackage`, a check that is done to ensure that the package scan will not add extraproduct to the picking if this operation is not allowed:
https://github.com/odoo/enterprise/blob/5e4c8ecb0c644e21755570ed59cd8f6e9f618c8a/stock_barcode/static/src/models/barcode_picking_model.js#L2024-L2035
Unfortunately, this check is done just before a possible usage of the package as package dest. And, in that case, since we do not try to add any product to the picking the check is irrelevant anyway.

opw-6303969

Forward-Port-Of: odoo/enterprise#121789

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

Forward-Port-Of: odoo/enterprise#116022

## Issue
In the attendance view of an employee, a recap of the current extra hours is displayed, showing four values:
1. Total Extra Hours Worked
2. Total Compensable Extra Hours
3. Time Off Taken from Extra Hours
4. Remaining Extra Hours

Each of the above values can be negative but the last one, which can seem odd as it appears to be calculated from the other values.

<img width="299" height="168" alt="6293174-before" src="https://github.com/user-attachments/assets/4377e2fd-f5f2-41a4-a82b-6f2598378499" />

## Steps to reproduce
1. Install *HR Attendance Holidays* (`hr_holidays_attendance`)
2. In Settings, toggle *Absence Management* and *Display Extra Hours*
3. For an employee E:
    - In the Payroll tab, set the Working Hours to the *Standard 40 hours/week* schedule
    - In the Settings tab, set the Overtime Ruleset to the *Default Ruleset*, and toggle the *Give back as time off* action for the *Employee Schedule Rule* rule
4. Create an attendance for employee E:
    - Any day where they are expected to work 8 hours
    - From 10am to 5pm (6 hours with lunch)
5. In the Employees app, go to employee E and click the *Monthly Hours* smart button
6. __In the *Balance* recap above the list of attendances, the *Remaining Extra Hours* row shows 00:00, which seems wrong compared to the other fields above (*Total Extra Hours Worked* and *Total Compensable Extra Hours*) which appear negative.__

## Cause
The `unspent_overtime` (*Remaining Extra Hours* in the balance recap) is computed by adding positive values, making it strictly positive.

https://github.com/odoo/odoo/blob/30c9e8c5b1e34b94c8aab8681e2c051a3b70f013/addons/hr_holidays_attendance/models/hr_employee.py#L62-L65

This was added by https://github.com/odoo/odoo/commit/2144bcfba1ac53c82fc7f2870a72bb13abee97e4, with no justification on why this value needs to be positive.

## Impact on "Time Off taken from Extra Hours"
Before this change, after following the above steps, a value of `-2:00` would be displayed in the *Time Off Taken from Extra Hours* row. This is no longer the case after this fix, since the `'unspent_compensable_overtime'` (*Remaining Extra Hours*) value is used to compute that row:

https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/hr_holidays_attendance/static/src/views/extra_hours_list_view.js#L39-L42

Instead, a value of `00:00` is shown. Before, we were substracting 0 hour of `unspent_compensable_overtime` to the -2 hours of `compensable_overtime`, now we are subectracting -2 hours of `unspent_compensable_overtime` to the same -2 hours of `compensable_overtime`. This is a side effect that was ignored, as it seems to make at least as much sense as showing `-2:00`.

<img width="321" height="179" alt="6293174-after" src="https://github.com/user-attachments/assets/907d5fb8-0c36-4b2e-bca7-1cec41baf22b" />


opw-6293174

Forward-Port-Of: odoo/odoo#273402
Forward-Port-Of: odoo/odoo#271272

### Commit 1:

[FIX] website: prevent CSRF error by blocking duplicate form submission

Before this commit: Clicking the logout button from the website
preview triggered two simultaneous logout requests:

1. The browser performed the default form submission with a valid
   `csrf_token`, destroying the session afterward.
2. During the same click event, `setupClickListener()` intercepted
   the click using `closest('[action]')`, found the parent
   `/web/session/logout` form, and triggered a second POST request
   using `odoo.csrf_token`.

Since the session was already destroyed by the first request, the
second request resulted in a "CSRF validation failed" error.

This commit prevents the default form submission before triggering
the manual POST request, ensuring that only one request is sent.

Runbot-940403

--------------------------------------------------------------------------------------------------------------------------------

### Commit 2:

[FIX] website: enable free sign up setting in test_auth_forms_warning

Steps to reproduce:
1. Install any website related module (e.g. `website`, `website_event`).
2. Keep the default configuration and do not manually enable
   'Free sign up' in Settings.
3. Run `test_auth_forms_warning`.

Before this commit: The test did not programmatically enable the
'Free sign up' setting. As a result, it failed unless a developer
manually navigated to the setting and enabled it beforehand.

After this commit: This commit explicitly enables the "Free sign up"
configuration during test execution, allowing public access to the
`/web/signup` page and ensuring the test passes without any manual
setup.

runbot-940394

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

Forward-Port-Of: odoo/odoo#272020

*: mrp_subcontracting_{dropshipping, purchase}

### Steps to reproduce:

- In the settings: Enable subcontracting, dropshipping
- Create a storable dropshipped product FP with a set vendor for 5$ and subcontracting BOM: 1 X COMP. Value this product in avco perpetual
- Set the component to resupply subcontractor and standard price to 2$
- Create and confirm a sale order for 1 unit fo FP
- Validate the resupply to the subcontractor and then the dropship
> The FP standard price shoul dhave been updated to 5$ + 2$ = 7$
- Create and post a bill from the PO for 10$ rather than 5
#### > The FP standard price should have been updated to 11$ rather than 12$

Cause of the issue:

Posting the bill will call the `_set_value` method to re-evaluate the product in terms of the newly recorded `account.move`: https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/stock_account/models/stock_move.py#L393-L395 Now, the issue is that due to our config, there are two relevant moves linked to the `order_line`: the final move of the subcontracted production (which `is_in`) and the dropship move going from the subcontractor to the customer. When it comes to the subcontracted move, it is appropriately valuated at 12$ by the `_get_value_from_account_move` because of this override which adds the components value via the extra cost since the move has a `production_id`:
https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/mrp_subcontracting_purchase/models/stock_move.py#L14-L38 However, the dropship move will not add this extra cost (as no override sets it to have the same value as the subcontracted production it comes from) so that this move is valuated at 10$. This explains why the value of the avco product is then updated to 11$ since (12 + 10) /2 = 11

Note that the issue is not reproducible in the case of regular subcontracting since in that case the receipt from `subcontractor` to `stock` is not valuated.

opw-6318035

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

Forward-Port-Of: odoo/odoo#273137
Forward-Port-Of: odoo/odoo#272813

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

### Description of the issue this PR addresses

Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with:

```
psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist
```

### Current behavior before PR

To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`.

Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation.

### Desired behavior after PR is merged

`_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged.

### Steps to reproduce

1. Have several companies using different currencies.
2. Select more than one of them in the company switcher.
3. Open **Accounting > Reporting > Partner Ledger**.
4. Click **Send by email** → the wizard crashes on opening.

A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`.

The function _compute_made_sequence_gap is designed to determine if an updated move created a sequence gap. This is currently done with several performance issues.

Firstly, the search domain simply uses a min/max sequence number of the updated moves. However, we only ever need the sequence number that comes before each changed move.

Example:
Let's say we updated 3 moves.
Move A: sequence_number = 27
Move B: sequence_number = 235
Move C: sequence_number = 100342

The search domain then becomes:
('sequence_number', '>=', min(moves.mapped('sequence_number')) - 1),
('sequence_number', '<=', max(moves.mapped('sequence_number')) - 1),

('sequence_number', '>=', 26),
('sequence_number', '<=', 100341),

The search domain can now return up to 100315 moves! Since we then loop over each updated move (Move A,B,C) and check if the previous sequence number exists, we are never using 100312 of the records from the search.

Instead, we can compute what sequence numbers we are looking for ahead of time, and specifically search for those.

We can also convert this to a search_read to retrieve only sequence_number.

|  | Two Moves 35,000 apart | 1000 sequential moves |
| --------- | ------ | ------ | 
| Queries Before |129 | 4,300|
| Queries After | 24|4,291|
| Time Before |0.90 seconds |2.92 seconds|
| Time After | 0.11 seconds|2.69 seconds|

opw-6330731