Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:

    UncaughtPromiseError > RequestPendingError
    REGISTER request already in progress, waiting for final response
        at Registerer.register (sip.js)
        at Registerer.register (registerer.js)
        at UserAgent.attemptReconnection (user_agent_service.js)

When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.

On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.

This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.

The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.

Forward-Port-Of: odoo/enterprise#120487
Forward-Port-Of: odoo/enterprise#119701

**Issue**
Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application.

**Steps to reproduce**
- Activate by-product in the settings
- Create a product with an empty BOM (final product)
- Create another product tracked by serial number (by-product)
- Create and confirm a MO for the final product with 1 unit of the by-product
- Go to Miscellaneaous -> operation Type -> shopfloor
- Activate the option "Pre fill lot/serial numbers in shop floor"
- Return to the MO and open the shopfloor view
- Click on the '+' button next to the by-product and assign a serial number
- Try to close the production
-> A user error is raised stating that the by-product requires a serial number.

**Cause**
When the by-product is added manually on the MO, a stock move is created with an initial move line that does not contain any serial number.

Later, when assigning a serial number from the shopfloor view: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L121-L122 a new move line containing the serial number is created: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L116-L119 However, the original empty move line is not removed (the issue): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L124-L125 Because `self.picking_type_prefill_shop_floor_lots` is True, but `self.byproduct_id` is an empty recordset since: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1304-L1311 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1279 Indeed, `byproduct_id` is only populated from BOM-defined by-products. As a result, while confirming the production, there is 2 sml and among them, the original one without SN, which triggers the error:
https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L590 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L634-L635 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L658-L659 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L661-L669

opw-6223158

Forward-Port-Of: odoo/enterprise#120493
Forward-Port-Of: odoo/enterprise#118792

In the current code, for each slot, and for each "available"
resource, we check if the resource is available on the slot,
based on availability values. Then, we check the remaining
capacity of that resource. Also, linked resources information
is added when computing the original resource remaining capacity.
If many linked resources exist, this will be done several times
and is not useful.

This commit makes that loop disappear. We now check all resources
at once in terms of availability, and linked resources that could
be selected (in the appointment resources, in the slot resources
(if any restricted resource)) at the same time. Then, the total
capacity is the sum of the resource remaining capacity and the
ones of available linked resources.

Therefore, _slot_availability_is_resource_available is renamed to
_slot_available_resources, as it now takes more than one resource
and returns all resources among 'resources' that are valid on
the slot, based on the availability_values, slot restrictions and
booking lines.

A noticeable difference is mainly seen when using many resources
(and linked resources). For instance, a restaurant with a lot of
small tables will have their slot availability check much shorter.

BENCHMARK, LOCAL (time only, as number of requests does not change)
Only appointment installed

For a restaurant with
- 10 tables of 2
- 5 tables of 2 linked, 2 times
- 10 tables of 4
- 2 table of 2
- time then auto assign

On loading /appointment/id:
~ 3.1s -> ~ 1.6s
On selecting any number of people (1 to 10):
[2s, 2.5s] -> [0.6s, 0.8s]

Task-4144524

Forward-Port-Of: odoo/enterprise#121212
Forward-Port-Of: odoo/enterprise#107711

A personal outgoing mail server is an `ir.mail_server` that belongs to one user. The
system only lets that user send through it. Mass mailings do not always respect this,
which can cause a few problems:

1. Admins cannot duplicate a personal server. The copy keeps the same owner, and the rule that says one user can own only one server stops the save.
2. In *Email Marketing > Settings*, the "Dedicated Server" picker offers every server, even personal ones. If an admin picks a personal one, all campaigns get stuck. The cron job runs as Odoobot, the personal server rejects it, and the mailing stays in the queue.
3. When no dedicated server is set, the fallback selection can still land on a personal server (for example because its `from_filter` matches the sender). The cron sends through it and gets rejected.


One commit per problem:

1. **mail**: duplicating a personal server now produces a copy with no owner.
2. **mass_mailing**: the picker in the settings hides personal servers. Setting an owner on a server that is already used for mass mailing now raises a clear error that names the campaign blocking the change.
3. **mass_mailing**: personal servers are skipped when the fallback selection runs, so only shared servers are considered.

opw-6086077

Forward-Port-Of: odoo/odoo#271115
Forward-Port-Of: odoo/odoo#261537

## Steps to reproduce

- Create an attribute A, of type always, with 2 values, one should have an extra price
- Create an attribute B, of type never, with 2 values
- Create a product that has both those attributes
- Create a combo with that product with both values for A
- Go to the PoS and order that combo with the value that has an extra price for A
- The extra price is added

## Why the fix:

For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo.

As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page.

It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always".

The variants are then considered as different products, as they should in this case.

If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it.

We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 

We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same.

opw-6262431

Forward-Port-Of: odoo/odoo#270894
Forward-Port-Of: odoo/odoo#268567

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#120873
Forward-Port-Of: odoo/enterprise#115446

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

Forward-Port-Of: odoo/odoo#270768
Forward-Port-Of: odoo/odoo#265582

## [IMP] databases: SSO smooth connection and setup

The aim of this commit is to allow databases_user to be directly connected to
any remote SaaS database to which they have access.
When they click the "connect" button, they will bypass the login screen and be
authenticated automatically.

To achieve this, when a user tries to connect to an accessible SaaS database, we
quickly write their `oauth_uid` to that remote database right before the
connection is initiated.

Before this commit:
A user that was created in the remote db using the create user feature from the
databases module wouldn't get automatically authenticated through the Odoo
OAuth SSO feature.

After this commit:
Users attempting to connect to a SaaS database will be directly connected if the
settings was activated.

task-id: 6071808

## TODO:
- [x] check if we always have oauth_uid for saas db
- [x] think about making the oauth module autoinstall (make a bridge module? or overkill?)
    - We can avoid that and have everything work in place directly, avoiding an inheritance nightmare at installation time. 
- [x] handle cases where it isn't there on both the remote db and the managing one
- [x] write some tests to ensure the code is free from traceback
- [x] add a feature allowing to:
    - [x] add it to all server on which the user has access
    - [x] add it to a specific server (may require the db list view on `res.users`
    - [x] remove the previous and do everything when the user click on "connect"
- [x] would be better to put the code in a new module with auto install => people get auto-install + no "hacky" code.
    - The "hacky" code is not so hacky and with that we can directly advertise the installation of `auth_oauth` in an action
    - [x] add a config in the settings

Forward-Port-Of: odoo/enterprise#112369

## Steps to reproduce

- Create an attribute A, of type always, with 2 values, one should have an extra price
- Create an attribute B, of type never, with 2 values
- Create a product that has both those attributes
- Create a combo with that product with both values for A
- Go to the PoS and order that combo with the value that has an extra price for A
- The extra price is added

## Why the fix:

For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo.

As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page.

It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always".

The variants are then considered as different products, as they should in this case.

If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it.

We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 

We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same.

opw-6262431

Forward-Port-Of: odoo/odoo#270894
Forward-Port-Of: odoo/odoo#268567

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#120873
Forward-Port-Of: odoo/enterprise#115446

**Steps to reproduce:**
- make sure your main company (company 1)
has dollars as its main currency
- create second company (company 2) and a 
warehouse in this second company
- set euro has the main currency in the company 2

From company 1:
-  set an exchange rate 
of 1$ = 0.5 eur on the euro currency
- create a storable product with a cost of 10$
and an on-hand quantity of 1

From company 2: 
- set the cost to 10 eur and set an on-hand
quantity of 1

with both company selected and company 1 
as the main company selected: 
- open the stock view and look for your product

**Current behavior:**
the total value is 20$

**Expected behavior:**
with conversion rate, it should be 
30$

**Cause of the issue:**
when computing the total value 
we do not apply a conversion rate from 
the value of the company to the main 
company selected
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/stock_account/models/product.py#L273

opw-6280108

Forward-Port-Of: odoo/odoo#270575

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe

Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
    - opA: no blocker
    - opB: blocked by opA
    - opC: blocked by opA
    - opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan

Problem:
opA was scheduled after opB, violating the dependency.

`_plan_workorders` starts planning from the "leaf" workorders (those
with no dependents). Given the structure above, the initial set is
[opB, opD]. Processing opB first correctly plans opA then opB. But
processing opD triggers a recursive chain opD→opC→opA which calls
`action_unplan(opA)` and replans it from scratch. By then, opB already
occupies the workcenter slot that opA originally held, so opA ends up
scheduled after opB.

Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.

opw-6299179

## [IMP] databases: SSO smooth connection and setup

The aim of this commit is to allow databases_user to be directly connected to
any remote SaaS database to which they have access.
When they click the "connect" button, they will bypass the login screen and be
authenticated automatically.

To achieve this, when a user tries to connect to an accessible SaaS database, we
quickly write their `oauth_uid` to that remote database right before the
connection is initiated.

Before this commit:
A user that was created in the remote db using the create user feature from the
databases module wouldn't get automatically authenticated through the Odoo
OAuth SSO feature.

After this commit:
Users attempting to connect to a SaaS database will be directly connected if the
settings was activated.

task-id: 6071808

## TODO:
- [x] check if we always have oauth_uid for saas db
- [x] think about making the oauth module autoinstall (make a bridge module? or overkill?)
    - We can avoid that and have everything work in place directly, avoiding an inheritance nightmare at installation time. 
- [x] handle cases where it isn't there on both the remote db and the managing one
- [x] write some tests to ensure the code is free from traceback
- [x] add a feature allowing to:
    - [x] add it to all server on which the user has access
    - [x] add it to a specific server (may require the db list view on `res.users`
    - [x] remove the previous and do everything when the user click on "connect"
- [x] would be better to put the code in a new module with auto install => people get auto-install + no "hacky" code.
    - The "hacky" code is not so hacky and with that we can directly advertise the installation of `auth_oauth` in an action
    - [x] add a config in the settings

Forward-Port-Of: odoo/enterprise#112369

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101

Forward-Port-Of: odoo/odoo#271264
Forward-Port-Of: odoo/odoo#268504

**Problem:**
When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete.

**Cause:**
The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records.

**Solution:**
Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone).

**Performance Stats:**
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|100         |3.1s       |393           |0.8s      |117          |
|1,000       |22.3s      |2,090         |1.5s      |183          |
|10,000      |Timeout    |N/A           |6.7s      |541          |

opw-6087422

Forward-Port-Of: odoo/odoo#269876
Forward-Port-Of: odoo/odoo#263953

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423
During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576
Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

Community: https://github.com/odoo/odoo/pull/271017

opw-6275658

Forward-Port-Of: odoo/enterprise#121135

Implements the NSSO elderly-worker reduction for Brussels (codes
  7320) and Wallonia (8320/8321/8322), including the Wallonia
  2023 reform and the 2026-04-01 hire-date sub-rule.

  Adds:
  * A monthly salary rule producing an estimation of the quarterly G1
    reduction prorated on the current slip, for payslip visibility.
  * Dated hr.rule.parameter records holding the per-region bracket tables
    (age_min, age_max, dmfa_code, G), the quarterly wage caps, and the
    βg breakpoints.
  * DMFAOccupationDeductionElderly in hr_dmfa.py: P = G × µ × βg per
    matching bracket per occupation, with µ from declared service hours
    and βg from the worker-level µ_global.
  * Tests covering region/age/hire-date branching, the wage cap, part-time
    µ rounding, and payslip-vs-DMFA parity.

Payslip estimation takes shortcuts that make it informational only: it
sums all worked-days hours instead of filtering DMFA service codes,
extrapolates one month × 3 instead of aggregating the real quarter,
uses the slip's own µ as µ_global, ignores multi-occupation aggregation,
checks the wage cap on ONSS_BASE × 3 instead of the proper ss_quarter,
 and prorates the quarterly result flatly across months.

Shared bracket / βg / age helpers live on hr.payslip rather than in
hr_dmfa.py because the salary rule needs them at slip computation time
  (before any DMFA export exists)

task - 6131498

This commit introduces a comprehensive management system for the 273S report, enhancing its lifecycle, data integrity, and user experience.

It's important to note that filing a 237S report can involve one of the following declarations:

1. Initial declaration
2. Modification declaration
3. Cancellation declaration

**After contacting the Service Public Federal (SPF) Finances, we have clarified that only Initial declarations are used in practice, and that modification and cancellation declarations are not used.**

**Initial Declarations are used to modify reports that have already been declared**

Ideally, a maximum of 12 Initial declarations should be used, but since modifications can also happen, a system is implemented to report the payslips of the year using the minimal amount of declared and corrected reports possible throughout the year by reporting each payslip that's not included in any ready/done report that exists in the period starting from the beginning of the year until the end of the month of the report.

**Lifecycle & Structure**

* 273S reports are now persistent documents with a clear lifecycle (Draft, Ready, Done, Cancelled) rather than transient pop-ups.

* In the draft state, all fields are editable except Year and Month in the type `correction` since they are inherited from the original report. The original report is a required field for the correction type. Payslips are auto-populated if any of the fields (Year, Month, Original, Type) are updated. Populating a report differs based on its type; if it's an original declaration, then the report is populated by all payslips that are in a ready/done state that were issued starting from the current year and until the end of the declared month; if it's a correction report, then it's populated with payslips that aren't in a **finalised report**. **A finalised report is a report that is in a ready/done state and not one of its parent correction reports. Once the report has payslips in it, a button appears to generate the PDF (for the user) and XML (to be submitted) files.**

* Once generated, the report moves to the Ready state, allowing users to review the data before final submission. In this state, all fields become non-editable except for the Reference field, which should be used to add the reference of the declaration received from the government after submission. The report can be set back to draft if any changes are needed. If a report that needs to be corrected was set to draft, it will no longer be considered in the first warning type since its `is_correction_needed` will be set to False.

* Done state is the next state after Ready, which is achieved by the action `Mark as done` and requires the Reference field to be filled. Since the Reference field is important for the traceability of the declaration report, it's set to be tracked in the chatter. Done state and Ready state are alike except for the fact that Done state is for reports that are already declared to the government and have the reference of the declaration while Ready state is for reports that are generated but not yet declared to the government that's why a `Set to draft` action is allowed for Ready state and the Done state cannot be reached without filling the Reference field. The action `Correct` is shown for Done reports to allow creating a new correction report with the same period and payslips as the original report.

* Cancelled state is the last state in the lifecycle and can be reached from any of the previous states. Once a report is cancelled, it cannot be set back to any other state, and all its data becomes non-editable except the Reference field.

**UI & Proactive Warnings**

* Two warnings are also added to the dashboard to alert the user when some reports are outdated and need to be corrected, or when some payslips are missing from the declaration of the previous year.

* For the first warning, a report is considered outdated when one of its payslips has been cancelled after the report was generated.

* For the second warning, a payslip is considered missing from last year's declaration when it belongs to the previous year and is not included in any ready/done report of the previous year. Missing payslips will be declared in December's Initial Declaration report of the previous year or a correction report if December's report is already declared. The warning for missing payslips of only one previous year is shown.

Task: 5473528

This commit refines the design of the call debrief transcription layout. It also adds an active state to the timeline markers.

task-6119464

Requires:
- https://github.com/odoo/odoo/pull/271103

---

| Header | Header |
|--------|--------|
| <img width="955" height="440" alt="Screenshot 2026-06-19 at 16 38 12" src="https://github.com/user-attachments/assets/114819c7-8bec-4a65-af13-9f834e692053" /> | <img width="947" height="820" alt="Screenshot 2026-06-19 at 16 39 24" src="https://github.com/user-attachments/assets/62374140-6819-4557-8181-6fd36b006cc5" /> |
| <img width="960" height="247" alt="Screenshot 2026-06-19 at 16 38 28" src="https://github.com/user-attachments/assets/b25368c8-b545-4fc7-8211-907faed28926" /> | <img width="954" height="368" alt="Screenshot 2026-06-19 at 16 39 45" src="https://github.com/user-attachments/assets/1836c801-c383-43cb-aa11-ef2ec3e496cb" /> |
| <img width="955" height="449" alt="Screenshot 2026-06-19 at 16 38 49" src="https://github.com/user-attachments/assets/983dd118-a3dd-4055-8af4-703217047e8b" /> | <img width="957" height="614" alt="Screenshot 2026-06-19 at 16 40 08" src="https://github.com/user-attachments/assets/5b22f3e4-9af7-4ce9-b3fd-b997964c5794" /> |

The Wage Types action record salary rules belonging to the CHMONTHLYELM payroll structure.

During the payroll refactoring, salary rules were changed to support multiple payroll structures. in the 19.4  version here c2f18f3

Where struct_id M20 field is changes to [M2m](https://github.com/odoo/upgrade/pull/10294/changes#diff-541246af074f8ac598b0a274ef9861f5fe974e6ded22e906c3d35adecb284e8cR51) struct_ids 

Opening Payroll > Configuration > Company > Wage Types will cause the issue as the action has not updated which Failes the [ci/upgrade_enterprise](https://runbot.odoo.com/runbot/batch/2598248/build/115031148)

Steps to reproduce.
- Create a database on saas-19.3.
- Install l10n_ch_hr_payroll.
- Upgrade the database to master.
- Open Payroll > Configuration > Company > Wage Types.
- Error raise error(message % (*args, self.field_expr, self.operator, self.value)) ValueError: Invalid field hr.salary.rule.struct_id in condition
 ('struct_id.code', '=', 'CHMONTHLYELM')

The issue will directly reproduce in the runbot maste too installed the l10n_ch_hr_payroll module and access the wage type.
```
Adding menu ('l10n_ch_hr_payroll.menu_l10n_ch_wage_types', 1598, 'Payroll > Configuration > Company > Wage Types', 2337) to the failing menus
Traceback (most recent call last):
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L964)", line 964, in __get_field
    field = model._fields[field_name]
            ~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'struct_id'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L346)", line 346, in crawl_menu
    self.mock_action(action_vals)
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L377)", line 377, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L537)", line 537, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L675)", line 675, in mock_view_list
    return self.mock_view_tree(model, view, fields_list, domain, group_by)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L688)", line 688, in mock_view_tree
    self.mock_web_search_read(model, view, [domain], fields_list)
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L722)", line 722, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/models.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/models.py#L5187)", line 5187, in search_read
    records = self.search_fetch(domain or [], fields, offset=offset, limit=limit, order=order)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/models.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/models.py#L1462)", line 1462, in search_fetch
    query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/models.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/models.py#L4773)", line 4773, in _search
    domain = domain.optimize_full(self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L472)", line 472, in optimize_full
    return self._optimize(model, OptimizationLevel.FULL)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L486)", line 486, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L670)", line 670, in _optimize_step
    children = self._flatten(child._optimize(model, level) for child in self.children)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L628)", line 628, in _flatten
    for child in children:
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L670)", line 670, in <genexpr>
    children = self._flatten(child._optimize(model, level) for child in self.children)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L486)", line 486, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L988)", line 988, in _optimize_step
    field, property_name = self.__get_field(model)
                           ^^^^^^^^^^^^^^^^^^^^^^^
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L966)", line 966, in __get_field
    self._raise("Invalid field %s.%s", model._name, field_name)
  File "[/data/build/odoo/odoo/orm/domains.py](https://github.com/odoo/odoo/blob/2fb276668c824d6fe759a7c51f9ef10677532508/odoo/orm/domains.py#L951)", line 951, in _raise
    raise error(message % (*args, self.field_expr, self.operator, self.value))
ValueError: Invalid field hr.salary.rule.struct_id in condition ('struct_id.code', '=', 'CHMONTHLYELM')
2026-06-22 12:02:29	[ERROR](https://github.com/odoo/upgrade-util/blob/f3431df77099e3df9299b9d6fb1ea001796c176c/src/testing.py#L483)	
FAIL: TestCrawler.test_check
Traceback (most recent call last):
  File "[/data/build/upgrade-util/src/testing.py](https://github.com/odoo/upgrade-util/blob/f3431df77099e3df9299b9d6fb1ea001796c176c/src/testing.py#L483)", line 483, in test_check
    self.check(value)
  File "[/data/build/upgrade/migrations/base/tests/test_mock_crawl.py](https://github.com/odoo/upgrade/blob/07bec6a1031093cf001642f8df21e40421cce3be/migrations/base/tests/test_mock_crawl.py#L230)", line 230, in check
    self.assertFalse(diff, msg)
AssertionError: [('l10n_ch_hr_payroll.menu_l10n_ch_wage_types', 1598, 'Payroll > Configuration > Company > Wage Types', 2337)] is not false : At least one menu or view working before upgrade is not working after upgrade.
```
Soln:- Update the action with the correct field.

ref :- https://runbot.odoo.com/runbot/batch/2598248/build/115031148

**Problem:**
On a rental order, the sales order / quotation PDF no longer shows the pickup and return dates. The line description only displays the rental duration (e.g. "2 Days"), so the actual dates are missing from the printout.

**Steps to reproduce:**
1. Create a rental order with a rentable product and pickup/return dates
2. Print the order (Print > Quotation / Order)
3. Observe the PDF shows only the duration, with no pickup/return dates

**Current behavior:**
Neither the rental dates (removed from the description) nor any pickup/return field appear on the PDF.

**Expected behavior:**
The pickup and return dates are shown on the rental order PDF.

**Cause of the issue:**
The rental line description was intentionally reduced to only the duration (`_get_rental_duration_description`), the actual dates being meant to appear as dedicated Pickup/Return fields. This was added to the customer portal (`sale_rental_portal_details` inherits `sale.sale_order_portal_content`) but the equivalent was never added to the `sale.report_saleorder_document` PDF report, so the dates disappeared from the printout.

**Fix:**
Inherit the sale order report to render the order-level pickup and return dates for rental orders, mirroring the existing portal presentation so the PDF and the portal stay consistent.

opw-6268640

Forward-Port-Of: odoo/enterprise#119736

**Steps to reproduce:**
* Install the **l10n_cl_edi** module.
* Go to **Accounting → Configuration → CAFs**, create a new CAF, and upload a valid CAF [XML](https://www.odoo.com/mail/message/1097235975) file.
* Create a new **Purchase Journal** with **Use Documents** enabled.
* Create a vendor bill using this journal.
* Set the **Document Type** to **46 - Liquidación-Factura Electrónica**.
* Confirm the vendor bill.

**Observed behavior:**
* The Send button is not visible on the confirmed vendor bill despite the DTE being generated and `l10n_cl_dte_status` being set to `not_sent`.

**Cause:**
* `_compute_display_send_button` in `account` only returns `True` for sale documents (`is_sale_document()`), so the "Send" button — which opens the Send & Print dialog containing the "Send to SII" option — was never shown on vendor bills.
* `_get_move_constraints` in `account.move.send` unconditionally adds a `not_sale_document` constraint for non-sale documents, blocking the Send & Print dialog from processing vendor bills even if the button were visible.
* The cron's `cron_run_sii_workflow` only processes moves with `l10n_cl_dte_status = 'ask_for_status'`, skipping moves still in `not_sent` state.

**Fix:**
* Override `_compute_display_send_button` in `l10n_cl_edi` to also show the "Send" button on posted moves with `l10n_cl_dte_status == 'not_sent'`, matching the pattern used by `l10n_br_edi`.
* Override `_get_move_constraints` in `l10n_cl_edi` to remove the `not_sale_document` constraint for Chilean purchase documents with `not_sent` status, matching the pattern used by `l10n_br_edi`.

**REF**
 During this [refactor](https://github.com/odoo/enterprise/pull/103427/changes/f5617ecf7584cf019897408df94b002622f48d9d), these two methods were inadvertently missed and were not overridden 

opw-6300571

Forward-Port-Of: odoo/enterprise#121233
Forward-Port-Of: odoo/enterprise#120818

The '/my/counters' route is hit a lot of times on big databases like odoo.com

One thing it does is a `self.env['documents.document].search_count([])`

With this commit, we use a subquery for the folder access instead of the current LEFT JOIN.
This ok since the number of folders is typically small compared to regular documents and the query is fast since it can use the index on 'type'

Before as portal user
------

2x Seq Scan

```
 Aggregate  (cost=1900290.73..1900290.74 rows=1 width=8) (actual time=282.271..282.276 rows=1 loops=1)
   Buffers: shared hit=66629
   ->  Hash Left Join  (cost=41649.94..1900044.55 rows=98472 width=0) (actual time=184.202..282.267 rows=3 loops=1)
         Hash Cond: (documents_document.folder_id = documents_document__folder_id.id)
         Filter: ((hashed SubPlan 2) OR ((documents_document.owner_id = 6) AND ((documents_document.shortcut_document_id IS NULL) OR (documents_document.shortcut_document_owner_id = 6))) OR (((documents_document.access_via_link)::text = ANY ('{edit,view}'::text[])) AND (documents_document.folder_id IS NOT NULL) AND ((hashed SubPlan 4) OR ((documents_document__folder_id.owner_id = 6) AND ((documents_document__folder_id.shortcut_document_id IS NULL) OR (documents_document__folder_id.shortcut_document_owner_id = 6)))) AND (documents_document.is_access_via_link_hidden IS NOT TRUE)))
         Rows Removed by Filter: 28085
         Buffers: shared hit=66629
         ->  Seq Scan on documents_document  (cost=0.00..1857903.54 rows=187073 width=26) (actual time=0.022..109.288 rows=28088 loops=1)
               Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 6) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 6))) OR (((access_via_link)::text = ANY ('{edit,view}'::text[])) AND (folder_id IS NOT NULL) AND (is_access_via_link_hidden IS NOT TRUE))))
               Rows Removed by Filter: 342576
               Buffers: shared hit=33313
               SubPlan 2
                 ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.008..0.009 rows=0 loops=2)
                       Buffers: shared hit=6
                       ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.008..0.008 rows=0 loops=2)
                             Index Cond: (partner_id = 7)
                             Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:16:38'::timestamp without time zone))
                             Buffers: shared hit=6
                       ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (never executed)
                             Index Cond: (id = documents_access.document_id)
                             Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
         ->  Hash  (cost=37016.64..37016.64 rows=370664 width=16) (actual time=164.521..164.521 rows=370664 loops=1)
               Buckets: 524288  Batches: 1  Memory Usage: 17824kB
               Buffers: shared hit=33310
               ->  Seq Scan on documents_document documents_document__folder_id  (cost=0.00..37016.64 rows=370664 width=16) (actual time=0.005..100.491 rows=370664 loops=1)
                     Buffers: shared hit=33310
         SubPlan 4
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.003..0.003 rows=0 loops=1)
                 Buffers: shared hit=3
                 ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.002..0.003 rows=0 loops=1)
                       Index Cond: (partner_id = 7)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:16:38'::timestamp without time zone))
                       Buffers: shared hit=3
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (never executed)
                       Index Cond: (id = documents_access_1.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
 Planning:
   Buffers: shared hit=69
 Planning Time: 1.708 ms
 Execution Time: 282.344 ms
```

After  as portal user
-----

Only 1x Seq Scan
```
Aggregate  (cost=2004948.33..2004948.34 rows=1 width=8) (actual time=116.161..116.165 rows=1 loops=1)
   Buffers: shared hit=37942
   ->  Seq Scan on documents_document  (cost=145660.16..2004490.36 rows=183187 width=0) (actual time=24.635..116.155 rows=3 loops=1)
         Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 6) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 6))) OR (((access_via_link)::text = ANY ('{edit,view}'::text[])) AND (hashed SubPlan 5) AND (is_access_via_link_hidden IS NOT TRUE))))
         Rows Removed by Filter: 370661
         Buffers: shared hit=37942
         SubPlan 2
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.008..0.009 rows=0 loops=1)
                 Buffers: shared hit=3
                 ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.008..0.008 rows=0 loops=1)
                       Index Cond: (partner_id = 7)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:15:10'::timestamp without time zone))
                       Buffers: shared hit=3
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (never executed)
                       Index Cond: (id = documents_access.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
         SubPlan 5
           ->  Index Scan using documents_document__type_index on documents_document documents_document_1  (cost=0.42..145625.73 rows=13772 width=4) (actual time=11.688..11.689 rows=0 loops=1)
                 Index Cond: ((type)::text = 'folder'::text)
                 Filter: ((hashed SubPlan 4) OR ((owner_id = 6) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 6))))
                 Rows Removed by Filter: 28198
                 Buffers: shared hit=4629
                 SubPlan 4
                   ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.002..0.002 rows=0 loops=1)
                         Buffers: shared hit=3
                         ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.001..0.002 rows=0 loops=1)
                               Index Cond: (partner_id = 7)
                               Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:15:10'::timestamp without time zone))
                               Buffers: shared hit=3
                         ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (never executed)
                               Index Cond: (id = documents_access_1.document_id)
                               Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
 Planning:
   Buffers: shared hit=56
 Planning Time: 1.544 ms
 Execution Time: 116.216 ms
```

Before as internal user
--------
```
Aggregate  (cost=1902165.43..1902165.44 rows=1 width=8) (actual time=332.919..332.925 rows=1 loops=1)
   Buffers: shared hit=69223 read=370
   ->  Hash Left Join  (cost=41649.94..1901908.04 rows=102955 width=0) (actual time=176.179..332.325 rows=10040 loops=1)
         Hash Cond: (documents_document.folder_id = documents_document__folder_id.id)
         Filter: ((hashed SubPlan 2) OR ((documents_document.owner_id = 1054906) AND ((documents_document.shortcut_document_id IS NULL) OR (documents_document.shortcut_document_owner_id = 1054906))) OR (((documents_document.access_internal)::text = ANY ('{view,edit}'::text[])) AND ((documents_document.company_id = 1) OR (documents_document.company_id IS NULL))) OR (((documents_document.access_via_link)::text = ANY ('{view,edit}'::text[])) AND (documents_document.folder_id IS NOT NULL) AND ((hashed SubPlan 4) OR ((documents_document__folder_id.owner_id = 1054906) AND ((documents_document__folder_id.shortcut_document_id IS NULL) OR (documents_document__folder_id.shortcut_document_owner_id = 1054906))) OR (((documents_document__folder_id.access_internal)::text = ANY ('{view,edit}'::text[])) AND ((documents_document__folder_id.company_id = 1) OR (documents_document__folder_id.company_id IS NULL)))) AND (documents_document.is_access_via_link_hidden IS NOT TRUE)))
         Rows Removed by Filter: 27228
         Buffers: shared hit=69223 read=370
         ->  Seq Scan on documents_document  (cost=0.00..1859756.86 rows=190950 width=35) (actual time=15.029..155.718 rows=37268 loops=1)
               Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 1054906) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 1054906))) OR (((access_internal)::text = ANY ('{view,edit}'::text[])) AND ((company_id = 1) OR (company_id IS NULL))) OR (((access_via_link)::text = ANY ('{view,edit}'::text[])) AND (folder_id IS NOT NULL) AND (is_access_via_link_hidden IS NOT TRUE))))
               Rows Removed by Filter: 333396
               Buffers: shared hit=33931 read=370
               SubPlan 2
                 ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.155..7.920 rows=148 loops=2)
                       Buffers: shared hit=1612 read=370
                       ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.110..3.448 rows=200 loops=2)
                             Index Cond: (partner_id = 1800102)
                             Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:17:29'::timestamp without time zone))
                             Buffers: shared hit=192 read=190
                       ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (actual time=0.022..0.022 rows=1 loops=400)
                             Index Cond: (id = documents_access.document_id)
                             Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
                             Rows Removed by Filter: 0
                             Buffers: shared hit=1420 read=180
         ->  Hash  (cost=37016.64..37016.64 rows=370664 width=25) (actual time=157.822..157.823 rows=370664 loops=1)
               Buckets: 524288  Batches: 1  Memory Usage: 21336kB
               Buffers: shared hit=33310
               ->  Seq Scan on documents_document documents_document__folder_id  (cost=0.00..37016.64 rows=370664 width=25) (actual time=0.005..96.730 rows=370664 loops=1)
                     Buffers: shared hit=33310
         SubPlan 4
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.019..0.372 rows=148 loops=1)
                 Buffers: shared hit=991
                 ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.005..0.078 rows=200 loops=1)
                       Index Cond: (partner_id = 1800102)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:17:29'::timestamp without time zone))
                       Buffers: shared hit=191
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (actual time=0.001..0.001 rows=1 loops=200)
                       Index Cond: (id = documents_access_1.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
                       Rows Removed by Filter: 0
                       Buffers: shared hit=800
 Planning:
   Buffers: shared hit=69 read=8
 Planning Time: 2.116 ms
 Execution Time: 333.013 ms
```

After as internal user
--------
```
Aggregate  (cost=2006950.17..2006950.18 rows=1 width=8) (actual time=157.117..157.121 rows=1 loops=1)
   Buffers: shared hit=39918
   ->  Seq Scan on documents_document  (cost=145798.74..2006482.26 rows=187165 width=0) (actual time=16.595..156.590 rows=10040 loops=1)
         Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 1054906) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 1054906))) OR (((access_internal)::text = ANY ('{view,edit}'::text[])) AND ((company_id = 1) OR (company_id IS NULL))) OR (((access_via_link)::text = ANY ('{view,edit}'::text[])) AND (hashed SubPlan 5) AND (is_access_via_link_hidden IS NOT TRUE))))
         Rows Removed by Filter: 360624
         Buffers: shared hit=39918
         SubPlan 2
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.019..1.016 rows=148 loops=1)
                 Buffers: shared hit=991
                 ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.012..0.262 rows=200 loops=1)
                       Index Cond: (partner_id = 1800102)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:16:29'::timestamp without time zone))
                       Buffers: shared hit=191
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (actual time=0.004..0.004 rows=1 loops=200)
                       Index Cond: (id = documents_access.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
                       Rows Removed by Filter: 0
                       Buffers: shared hit=800
         SubPlan 5
           ->  Index Scan using documents_document__type_index on documents_document documents_document_1  (cost=0.42..145763.43 rows=14124 width=4) (actual time=0.429..14.916 rows=4625 loops=1)
                 Index Cond: ((type)::text = 'folder'::text)
                 Filter: ((hashed SubPlan 4) OR ((owner_id = 1054906) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 1054906))) OR (((access_internal)::text = ANY ('{view,edit}'::text[])) AND ((company_id = 1) OR (company_id IS NULL))))
                 Rows Removed by Filter: 23573
                 Buffers: shared hit=5617
                 SubPlan 4
                   ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.007..0.390 rows=148 loops=1)
                         Buffers: shared hit=991
                         ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.003..0.074 rows=200 loops=1)
                               Index Cond: (partner_id = 1800102)
                               Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:16:29'::timestamp without time zone))
                               Buffers: shared hit=191
                         ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (actual time=0.001..0.001 rows=1 loops=200)
                               Index Cond: (id = documents_access_1.document_id)
                               Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
                               Rows Removed by Filter: 0
                               Buffers: shared hit=800
 Planning:
   Buffers: shared hit=56
 Planning Time: 1.569 ms
 Execution Time: 157.171 ms
```

portal user
before https://explain.dalibo.com/plan/e1e755fg7bb26a21
after https://explain.dalibo.com/plan/hb5fa1d201ff164g

internal user with few documents access
before https://explain.dalibo.com/plan/f753bf2aa244dg63
after https://explain.dalibo.com/plan/538dg5ecb120ch84

internal user with *lots* of documents access
before https://explain.dalibo.com/plan/cf76h84537f7ge4a
after https://explain.dalibo.com/plan/45317a5e3168c5bc

Forward-Port-Of: odoo/enterprise#120991

**Issue**
Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application.

**Steps to reproduce**
- Activate by-product in the settings
- Create a product with an empty BOM (final product)
- Create another product tracked by serial number (by-product)
- Create and confirm a MO for the final product with 1 unit of the by-product
- Go to Miscellaneaous -> operation Type -> shopfloor
- Activate the option "Pre fill lot/serial numbers in shop floor"
- Return to the MO and open the shopfloor view
- Click on the '+' button next to the by-product and assign a serial number
- Try to close the production
-> A user error is raised stating that the by-product requires a serial number.

**Cause**
When the by-product is added manually on the MO, a stock move is created with an initial move line that does not contain any serial number.

Later, when assigning a serial number from the shopfloor view: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L121-L122 a new move line containing the serial number is created: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L116-L119 However, the original empty move line is not removed (the issue): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L124-L125 Because `self.picking_type_prefill_shop_floor_lots` is True, but `self.byproduct_id` is an empty recordset since: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1304-L1311 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1279 Indeed, `byproduct_id` is only populated from BOM-defined by-products. As a result, while confirming the production, there is 2 sml and among them, the original one without SN, which triggers the error:
https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L590 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L634-L635 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L658-L659 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L661-L669

opw-6223158

Forward-Port-Of: odoo/enterprise#120493
Forward-Port-Of: odoo/enterprise#118792

Steps to reproduce:
1. Make sure you have an employee with a contract
2. Create 2 payslips for this employee
3. Change any field of the employee (ex: job position)
4. Go to one of the payslips created before
5. Click on the "Manage Payslips" link appearing because of the change of data

Problem:
When the data of an employee has been modified and past payslip are affected, the popup currently states 0 payslip has been affected. When clicking the "Correct" button, the correct amount briefly shows before we are sent to the payslip page where only one payslip gets corrected.

Source of the problem:
- The `employee_id` field was missing from the wizard form view. Since it was not referenced anywhere in the view, the web client did not include it in the initial payload / default_get calls. As a result, the wizard was initialized without `employee_id`, causing the payslip computation to use an empty employee and return a count of 0.
- The window action did not explicitly call the intended wizard form view. Odoo therefore selected an unintended inherited view (salary increase wizard) due to view resolution rules (inheritance and priority ordering). This inherited view specifically replaces the description and the correction choice with nothing, which explains why it didn't show before.

Fix:
- Add an invisible `employee_id` field in the form view to ensure it is included in the initial form payload and properly initialized from context defaults.
- Explicitly specify the correct view in the `views` parameter of the window action to prevent fallback to an inherited or unintended view.
- Add an explicit priority on the salary increase wizard view to avoid ambiguous view selection in the future.

Task-6304311

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#120873
Forward-Port-Of: odoo/enterprise#115446

When creating a payslip for an employee in the Belgian localization with
an hourly wage and an attendance-based work entry source contract, a
traceback occurs if there is an attendance with overtime.

This happens because the overridden `_preprocess_work_hours_data_split_half`
method in `l10n_be_hr_payroll_attendance` attempts to unpack `work_entries`
assuming it is a list of triplets, but it is passed as a `defaultdict`
with composite keys instead. This data structure mismatch results in a
`ValueError: not enough values to unpack (expected 3, got 2)`.

Even if updated to handle the `defaultdict` structure, `_preprocess_work_hours_data_split_half` would improperly delete the overtime line hours without adding them back elsewhere (the code responsible for adding them back seems to have been removed). Since this function serves no purpose anymore, we omit the call to it. However, because `saas-19.2` is a stable version
Task Id: 6253707

Forward-Port-Of: odoo/enterprise#119177
Forward-Port-Of: odoo/enterprise#118676

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120866
Forward-Port-Of: odoo/enterprise#120051

When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db.

**Steps to reproduce**

* In settings activate:
  - Lots & Serial Numbers
  - Units of Measure & Packagings
  - Storage Locations
  - Barcode Scanner : GS1 nomenclature
* Create a Product tracked by lot with
  - barcode: 00001234567895
* Add on hand quantity:
  - 100 kg in lot : 10002002303-4
  - 100 kg in lot : 11002002303-4
* Go to barcode>Operation>Internal Transfer>New
* Scan 02000012345678951010002002303-4#3100000100 meaning:
  - 02 following 14 characters are the product barcode
  - 10 following characters are the lot number
  - "#" separator
  - 3100: means the units are kilograms, 
  - 00100 means 100 units. 

-> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot)

**Observation**

When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717

- First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14
- Check if the data is in the cache, if not, set it to retrieve after
- Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search:
https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 
-> Since our barcode start with a 10, it will erase it, which lead to a miss in the search.


It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298

opw-6207120

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

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#120592
Forward-Port-Of: odoo/enterprise#118031

Currently, requests from the PoS UI are sent without any timeout, which can lead to indefinite waiting when the system is connected to a network but lacks internet access.

Examples:
- `sync_from_ui` can take more than 2 minutes to fail.
- Font CDN requests during receipt printing can take over 4 minutes to fail.
- In some cases, this causes receipt printing failure as well, even after several minutes (4-5 min) of delay.

This commit introduces a timeout for PoS UI requests to prevent such delays and improve responsiveness.

Additionally, font declarations are extracted from `web` into `point_of_sale`, and only the required fonts are included. This avoids unnecessary requests to missing CDN resources.

Additionally, this PR backports the following commits required to support this fix:
- https://github.com/odoo/odoo/pull/215130
- https://github.com/odoo/odoo/pull/220954
  Ensures the system continuously checks network connectivity and resumes synchronization once the connection is restored.
- https://github.com/odoo/odoo/pull/225743
  Prevents receipt printing from being blocked by logo loading issues and ensures the logo is displayed gracefully in such scenarios.

Task-6053404

| Font CDN request delay (~ 4 min)                   | `sync_from_ui` long request (> 2 min)            |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- |
| <img width="400" src="https://github.com/user-attachments/assets/8ea8b3e4-7ffe-44bf-a4d0-7975f43a8f68" /> | <img width="400" src="https://github.com/user-attachments/assets/5f899cab-b022-4ed2-aa82-12e54ea34ea7" /> |

### Issue:
When invoicing a sale order for a kit, components tracked by quantity that are archived are excluded from the Cost of Goods Sold (COGS) calculation

As a result, the journal items for "Expenses" and "Stock Interim (Delivered)" are undervalued on the invoice, creating a mismatch with the inventory valuation which correctly includes the archived components' costs Odoo natively allows the delivery and usage of
archived components when they are part of a BoM

### Cause:
The Bill of Materials (BoM) explosion correctly bypasses the active check using `with_context(active_test=False)`
However, during the invoice posting, `_stock_account_get_anglo_saxon_price_unit()` filters the kit's components using a standard `search()`, but without disabling the active test
Consequently, archived components tracked by quantity are ignored when computing the final anglo-saxon price unit

### To reproduce the issue:
- Install `account_accountant`, `sale_management` and `mrp`
- Create a product category PC (Inventory Valuation: Automated)
- Create 3 Products:
  - Kit (Tracked: Quantity, Product Category: PC)
  - Kit_Comp01 (Tracked: Quantity, Product Category: PC, Cost: 10$)
  - Kit_Comp02  (Tracked: Quantity, Product Category: PC, Cost: 20$)
- Set Kit_Comp01 and Kit_Comp02 on hand's quantity to 1
- Create a Bill of Materials (Product: Kit, Type: Kit, Components: 1x Kit_Comp01, 1x Kit_Comp02)
- Archive Kit_Comp02
- Create and Confirm a Sale Order for 1x Kit
- Process the related delivery
- Create and Post the Invoice
- Check the Journal Items tab Before the fix, the lines `Expenses` and `Stock Interim (Delivered)` are 10$ instead of 30$

opw-6204621

**Problem:**
partial quantities in a dropship picking 
is not taken into account for the svl quantity
(it's always the full initial quantity)

**Steps to reproduce:**
- create a storable product with dropship route
- set the category as avco auto
- set a vendor in the purchase tab with a price of 10
- confirm a SO for a quantity of 2
- confirm the related PO with a unit price of 10
- on the dropship picking change the quantity to 1
- validate without backorder
- click on the valuation smart button

**Current behavior:**
- the svls have quantities of 2 and -2
- the related amls have debit/credit of 20

**Expected behavior:**
- the svls should have quantities of 1 and -1
- the related amls should have debit/credit of 10

**Cause of the issue:**
when creating the svls we use the move's product_qty
instead of its quantity
https://github.com/odoo/odoo/blob/c97629d5efb82aed191de211593c539686cae65b/addons/stock_account/models/stock_move.py#L290

**fix:**
product_qty is expressed in the uom of the product
and quantity in the uom of the move so we need 
to add a uom conversion to the fix

opw-6113031

Avoid traceback when there is special hidden characters on the VAT numer, compact() method from stdnum does not process it.

We use regex to get only the number part for all the doc types

### Description of the issue/feature this PR addresses:

1. Create new contact
2. add cuit value (in the vat field). This one is copy from an external program with special hidden characteres

### Current behavior before PR:

There is a traceback and the user can not create the contact

```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/addons/l10n_ar/models/res_partner.py", line 123, in _get_id_number_sanitize
res = int(stdnum.ar.cuit.compact(self.vat))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '\u206030717808599'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30061:19)
at XMLHttpRequest.<anonymous> (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30124:27)
```
### Desired behavior after PR is merged:

Will let us to create the contact and validate the cuit no matter if it has or not an special character



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

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#120967

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865