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

Step to reproduce:
1. Install `website_link`
2. Open Website > Site > Link Tracker
3. Type in text into any pre-defined field (Campaign, Medium, Source)
4. Observe that the input is not showing all the typed characters

Issue:
- It's randomly removing characters, for example, type "1234567890" and observe

Cause:
- SelectMenu updates its internal searchValue only inside the debounced onInput handler `debouncedOnInput`. When an autocomplete callback reloads choices before that debounce fires, the component rerenders with a stale searchValue and writes that outdated value back into the controlled input, overwriting newer characters already typed by the user.

Solution:
- Update searchValue immediately on every raw input event and keep only the search callback debounced.
- Also reset searchValue to null when a required single-select is blurred while empty, so the input falls back 
  to the selected choice label instead of staying visually cleared.

opw-6000540

---

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

Forward-Port-Of: odoo/odoo#267974
Forward-Port-Of: odoo/odoo#255819

Version:
- 19.0

Steps to reproduce:
- Create a sign template with a readonly sign item linked to an auto field.
- Use a reference record where the linked field value is empty or False.
- Send the document for signing.
- Complete the signing flow.

Issue:
- Readonly sign items linked to auto-filled values could not properly handle
  falsy values. Empty values could trigger the error "Some required items are
  not filled" and completed sign requests displayed the sign item placeholder
  instead of the actual auto-filled value.
- completed document generation could fail when rendering falsy values for
  textarea sign items.

Cause:
- Falsy auto-filled values were ignored during constant item population and
  replaced by the sign item placeholder. Additionally, readonly constant items
  were included in required field validation and completed sign requests
  continued to display placeholders when the stored value was empty.
- document rendering assumed sign item values were always strings for textarea
  sign items but when auto field is empty it value can be False.

Fix:
- Preserve falsy values when populating readonly constant items, exclude
  constant items from signer validation, and hide placeholders for empty
  auto-filled constant items when displaying completed sign requests.
- Normalize falsy values to prevent crashes and allow completed documents
  to be generated correctly.

Forward-Port-Of: odoo/enterprise#121255
Forward-Port-Of: odoo/enterprise#121009

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:**
- 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:
1. Install CRM, Calendar, and Contacts.
2. Create a contact with an email address you can receive emails on.
3. Configure an outgoing email server.
4. Open a CRM lead and create a meeting activity using the calendar.
5. Add the created contact as an attendee of the meeting.
6. Return to the lead and click the Reschedule button on the activity.
7. Select the same meeting and change its start date to a future date.

Issue:
- Attendees receive the meeting date-change email twice.

Root cause:

- When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event.
https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779
https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33
- This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails.

Solution:
- Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling.

opw-6209956

Forward-Port-Of: odoo/odoo#266675

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

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Forward-Port-Of: odoo/odoo#269743

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

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:
1. Install Knowledge.
2. Create an article.
3. Open the more actions menu.
4. Click "Add Cover".
5. Upload a cover image.

Issue:
- The upload crashes with the following traceback:
`Uncaught Promise > this.props.setAbortUploadsCallback is not a function`

Cause:
- `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop.

Solution:
- Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded.

Alternative approach: 
- Make ImageSelector tolerate callers that do not provide
  setAbortUploadsCallback by calling it with optional chaining.

opw-6176716

Forward-Port-Of: odoo/enterprise#121162
Forward-Port-Of: odoo/enterprise#116906

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

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

Currently, an error will occur when user multi edits name of projects.

Steps to replicate:
- Install `documents_project` and open any project's settings using kebab menu (3 dots).
- Click new > name `Test` > open settings page and unselect `Documents` > Save.
- Click new > name `Test1` > Save.
- From the list view select `Test` and `Test1` and edit their name.

Error:
```
ValueError: Expected singleton: project.project(9, 10)
```

Cause:
- During `multi-edit`, self contains multiple project records.
- When only one of the selected projects has a documents folder (i.e. `use_documents` enabled), `self.documents_folder_id` contains that single folder, making `len(self.documents_folder_id.project_ids) == 1` to be True [1].
- The condition then proceeds to access `self.name` on the `multi-recordset`, raising singleton.

Solution:
- Avoided accessing `self.name` on a `multi-recordset` during multi-edit.
- Filtered projects individually and updated the document folders using the name in vals.

[1]: https://github.com/odoo/enterprise/blob/3c2985ca6011700c271ed14e40e08c89be822753/documents_project/models/project_project.py#L101

sentry-7452096418

Forward-Port-Of: odoo/enterprise#120654
Forward-Port-Of: odoo/enterprise#119060

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

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

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

**Steps to reproduce:**
* Install **l10n_mx_edi**.
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the
  custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new
  invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

**Observed behavior:**
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

**Cause:**
* `_get_invoice_report_filename` in `l10n_mx_edi` unconditionally returned the CFDI filename whenever `l10n_mx_edi_is_cfdi_needed` was `True`, ignoring the `invoice_report` context key.
* `account_move_send` sets `invoice_report` to the extra mail template when requesting the filename for dynamic report attachments, expecting the method to delegate to `super()` and evaluate the template's `print_report_name`.  The MX override never reached that branch.

**Fix:**
* Check for the `invoice_report` context key before applying the CFDI filename logic.  When it is present (i.e. a custom/extra report is requesting its filename), fall through to `super()` so the template's `print_report_name` is used correctly.

opw-6228268

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