The Download PDF option of an article prints the page with the browser. On screen, the article body is inside .o_scroll_view_lg, which scrolls when the content is longer than the screen:

https://github.com/odoo/enterprise/blob/79f8defa04476e1b939dc8bb5449a775137aed62/knowledge/static/src/scss/knowledge_views.scss#L170-L177

The print stylesheet used to force overflow: visible on every div, so this container did not scroll when printing. It also hid every child of the body except the action manager, so the navbar and open dropdowns were left out of the print. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rewrote knowledge_print.scss to scope its rules to the Knowledge view and removed both rules. The scroll container now keeps its fixed height and its scrollbar when printing, so the scrollbar is drawn in the print preview and on every page of the PDF. The dropdown opened to reach Download PDF is printed on top of the article when it overlaps the page area, which happens when the browser is zoomed in.

Add overflow: visible to the print rule of knowledge_print.scss that already targets .o_scroll_view and .o_scroll_view_lg with position: static. That rule exists to undo the screen positioning of the scroll containers when printing, so the overflow reset belongs there. Its selector is also more specific than the screen one, so the value applies without !important, like position: static already does. Restore the rule that hides the body children other than the action manager, scoped to the Knowledge view like the rest of the file since the print stylesheet is now loaded on every page.

Before:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/44aa3366-3fc8-4382-8aa2-84625fa4b6d8" />

After:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/8b6eb2bc-37a3-4666-b871-0e6149c41fea" />

Steps to reproduce:
1. Open the Knowledge app and create an article
2. Paste enough text in the article to fill more than one PDF page
3. Zoom the browser to 200%
4. Click the three dots in the top right corner, then Download PDF
5. Check the print preview or the saved PDF

=> A scrollbar is drawn on the right edge of every page and the dropdown menu is printed on top of the article

Ticket [link](https://www.odoo.com/odoo/project.task/6279174)
opw-6279174

Forward-Port-Of: odoo/enterprise#120249

**Problem:**
When a team restricts automatic closing to specific stages
(from_stage_ids), the closing-reminder email is still sent to every
inactive ticket in the team, including tickets in stages that are
never auto-closed.

**Steps to reproduce:**
1. On a helpdesk team, enable Automatic Closing with a reminder and set
   "In Stages" (from_stage_ids) to one specific stage
2. Leave a ticket inactive in a different, non-folded stage until it
   reaches the reminder threshold (auto_close_day - reminder_delay)

**Current behavior:**
The ticket gets a "your ticket will be closed soon" reminder even
though it is not in an auto-close stage and will never be closed.

**Expected behavior:**
Only tickets that would actually be auto-closed (those in
from_stage_ids) should receive the reminder.

**Cause of the issue:**
The reminder selection filters on auto_close_ticket_reminder and the
reminder date only; unlike the auto-close selection, it does not apply
the team's from_stage_ids condition.

**Fix:**
Reuse the same stage condition used to select tickets for closing when
selecting tickets for the reminder, so the reminded set stays
consistent with the set that will be auto-closed.

opw-6291237

Forward-Port-Of: odoo/enterprise#120732

From saas-18.4, the expiration confirmation wizard can be triggered not only from expired lots, but also from stock move lines whose `removal_date` has passed.

For incoming receipts, tracked products use the `lot_name` field when the user is entering the lot. The corresponding `lot_id` is only created later once the receipt is validated.

As a result, it is possible for the expiration confirmation wizard to be displayed before the lot exists. In this situation, it attempts to display the product and lot information using `lot_id`, which is still empty, causing the message to show "False, False" instead of the actual lot name entered by the user.

It should use the move line information as a fallback when no `lot_id` has been created yet so it still displays the correct product and lot name.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
   - Tracking: By Lots
   - Use Expiration Date: enabled
   - Removal Time > 0
3. Create a receipt for the product.
4. Open Detailed Operations.
5. Enter a new lot number in the Lot/Serial Number field.
6. Ensure the removal date is in the past and validate the receipt.

Related Tickets: opw-6303140

Forward-Port-Of: odoo/odoo#273970
Forward-Port-Of: odoo/odoo#273143

On a mo that has byproducts, if you unreserve, it will also set the quantity of byproducts to 0

Steps to reproduce:
-------------------
* Create a Products main, component and byproduct
* Create a bom for main with component as component and byproduct as byproduct
* Create and confirm a mo for main
* Set qty_producing to quantity ot produce
* click on "Unreserve" (do_unreserve)
* click on "Check availability"  (action_assign)
* Produce All
-> the byproducts will not be produced.

 Observation:
-------------
When updating the qty_producing value it will also update the quantity of the byproducts moves:
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L892-L893
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L1350
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/stock/models/stock_move.py#L2382
The quantity on the byproducts move has been updated.

When clicking on Unreserve it will call do_unreserve,
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L2297-L2298
It will filters the moves that do not need to be unreserved and select the others:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L900
and it will unlink all the sml from the moves:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L919
Which will set the quantity on the byproduct moves to 0.

When Producing all (button_mark_done) since the qty_producing has already been set, it will simply mark the byproduct move has picked.
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L1323-L1324

In our case, this means that the no byproducts will be created since, the quantity was previously set to 0

opw-6296562

Forward-Port-Of: odoo/odoo#273739
Forward-Port-Of: odoo/odoo#272216

The following use case has been observed:

0. Customer start a payment from /shop/payment.
1. We received the webhook that notifies that the payment succeeded.
2. The payment post-processing cron start (it gather all the transactions that need to be processed, including the customer new transaction)
3. Meanwhile, the customer is redirected back by the payment provider to Odoo, which then redirect to /payment/status and start the payment post-processing for that specific transaction
4. The customer initiated payment processing finishes, he is redirected back to /my/orders/... page.
5. The payment post-processing cron finally start processing the same customer transaction and process it (a second time).

In that case, as the transactions to be post-processed backlog was quite high, there is consequent time between the time we gather all the TXs to post-process and actually process the customer transaction.

Also we don't end up with a `SerializationError` as the cron do commit after each transaction post-processing.

This commit force invalidate individual transaction cache values and recheck if it effectively still need to be post-processed before doing it.

opw-6332192

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

Forward-Port-Of: odoo/odoo#274725
Forward-Port-Of: odoo/odoo#274010

Guests never receive any bus notification when the websocket is not handled by Odoo itself but by a proxy that forwards subscriptions through `/websocket/peek_notifications` and dispatches the notifications on its own (which is how Odoo.sh serves databases).

The peek controller calls `ir.websocket._prepare_subscribe_data()` directly, bypassing `_subscribe()`, the only method decorated with `@add_guest_to_context`. The guest cookie is present on the request but never read, so the returned channel list only contains the anonymous channels (broadcast, res.groups) and lacks the guest's personal ones: ("mail.guest", id), ("discuss.channel", id) and presence. The proxy therefore never registers those channels, and every notification targeted at the guest is silently dropped.

Before this commit, discuss calls with a guest are broken: a 2-person call never connects (p2p offers/answers/ICE are delivered over the bus); in a 3+ person call, any guest who joined before the SFU threshold stays stuck in dead p2p (they never receive the `sfu_hot_swap` notification) while a guest joining as 3rd+ participant works, since the join RPC returns the SFU credentials synchronously.

We override `peek_notifications` with `add_guest_to_context` so the route is aware of guests.

opw-5490739

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

Forward-Port-Of: odoo/odoo#274743

Version:
---------
- saas-18.4+

Steps to reproduce:
----------------------
1. Install `stock` and `purchase` module
2. Create a storable and tracking product with a vendor.
3. Create a reordering rule: Route = Buy, Min Qty = 10, Max Qty = 20 
and Trigger `manual`
4. Create a receipt for 10 units from the vendor and confirm it.(Mark as todo).
5. Observe the Order button is hidden in reorder rule(expected—incoming qty covers the minimum)
6. Delete the receipt move line.
7. Open reordering rule and check order button

Issue:
------
After deleting a confirmed incoming move, the Order button on the reordering rule
does not reappear, even though there is no longer any incoming quantity to cover
the minimum threshold.

Cause:
-------
https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/views/stock_orderpoint_views.xml#L55-L56

The Order button visibility is driven by `qty_to_order > 0` on the orderpoint.
`qty_to_order` itself resolves to `qty_to_order_computed` (a stored field) when no
manual override is set:

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L317-L319

 ``` 
 qty_to_order─depends─>qty_to_order_computed  (stored)
                                      │
                                      └─ reads qty_forecast  (non-stored, computed)
                                              │
                                              └─ depends on product_id.stock_move_ids.
 ```

`_compute_qty_to_order_computed` checks whether `qty_forecast < product_min_qty`.
If so, it calculates how much to order to reach `product_max_qty`. When a confirmed
incoming move exists, its quantity is included in `qty_forecast`,

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L347
This return False.
So, `qty_to_order_computed = 0` → button hidden.

To avoid recomputing `qty_to_order_computed` for all orderpoints on every stock
move change severe performance issue — see [Commit](https://github.com/odoo/odoo/commit/6f2d1b26b34129cfbd62d2fe44f306bfe89794b5
), 
`qty_forecast` is intentionally excluded from
 `@api.depends` on `qty_to_order_computed`. Instead,
`_update_orderpoints()` is called selectively from `create()` and `write()` to
schedule a targeted recompute via `env.add_to_compute()`.

However, `unlink()` never called `_update_orderpoints()`, so deleting a move left
`qty_to_order_computed` stale at 0 — the Order button stayed hidden permanently.

Solution:
---------
- `_update_orderpoints()` now returns the found orderpoints recordset.
- `unlink()` calls `_update_orderpoints()` before deletion to capture the affected
  orderpoints (product_id / location data still accessible), then calls
  `_compute_qty_to_order_computed()` immediately after `super().unlink()`.

opw-6174454


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

Forward-Port-Of: odoo/odoo#274832
Forward-Port-Of: odoo/odoo#264039

Use case
--------

A recurring sale order, is automatically invoiced. The transaction is postprocessed and crash with this traceback

```
File "/home/odoo/src/enterprise/saas-19.2/sale_subscription/models/sale_order.py", line 1881, in _handle_automatic_invoices
invoice._post()
File "/home/odoo/src/custom/private/openerp_enterprise/models/subscription_assignation.py", line 439, in _post
posted_moves = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/custom/private/openerp_enterprise/models/account.py", line 193, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/hr_payroll_expense/models/account_move.py", line 21, in _post
res = super()._post(soft=soft) # Posting will automatically reconcile same-account-same-matching lines
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/l10n_in_reports/models/account_move.py", line 135, in _post
to_post = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_loans/models/account_move.py", line 20, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/sale_subscription/models/account_move.py", line 21, in _post
posted_moves = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_invoice_extract/models/account_invoice.py", line 235, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/account_asset/models/account_move.py", line 130, in _post
posted = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_it_edi/models/account_move.py", line 360, in _post
return super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_in_edi/models/account_move.py", line 156, in _post
res = super()._post(soft=soft)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account_peppol_response/models/account_move.py", line 42, in _post
res = super()._post(soft)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/sale/models/account_move.py", line 149, in _post
invoice.js_assign_outstanding_line(line.id)
File "/home/odoo/src/enterprise/saas-19.2/account_accountant/models/account_move.py", line 589, in js_assign_outstanding_line
super().js_assign_outstanding_line(line_id)
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move.py", line 6430, in js_assign_outstanding_line
return lines.reconcile()
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 3324, in reconcile
return self._reconcile_plan([self])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 2978, in _reconcile_plan
plan_list, all_amls = self._optimize_reconciliation_plan(reconciliation_plan)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 2940, in _optimize_reconciliation_plan
amls._check_amls_exigibility_for_reconciliation(shadowed_aml_values=shadowed_aml_values)
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_move_line.py", line 2832, in _check_amls_exigibility_for_reconciliation
raise UserError(_("You can not reconcile cancelled entries."))

You can not reconcile cancelled entries.
```

Because an old transaction: state = 'reconciled' but is_reconciled is false get attached to the new invoice. The the tx.payment_id.move_id was cancelled by the accounting team, and the invoice was reconcilled directly with the bank statement.

So we end up with a cancelled move that block any further invoice for this subscription.

Solution
--------

According to accounting team, the move_id of the payment is always posted except if there is some manual intervention. We make sure we link only transaction with payment with posted moved

opw-6368231

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

SurveyResult binds a click listener on each .filter-add-answer icon when it starts. The response tables are rendered by a separate interaction, SurveyResultPagination, which swaps the tbody through a t-out directive on every page change and on Show All. Those new rows are nodes SurveyResult never bound, so their filter icon does nothing and the page reloads on the unfiltered view.

The direct binding comes from https://github.com/odoo/odoo/commit/dfc1c742e35f75f2c386c4ef50d5584537ac1ed4, which replaced the jQuery delegated handlers that used to survive re-renders. https://github.com/odoo/odoo/commit/c2f0f681714fcb936ce058e8dd4f1b1e9fa7448c reattaches them on tab change but not on pagination or Show All, so only the first page works.

Bind updateContent on .pagination_wrapper, which holds the page links and the Show All button and stays outside the re-rendered tbody. A click on either bubbles up and rebinds .filter-add-answer on the rows that were just rendered.

Steps to reproduce:
1. Install survey
2. Create a survey with a Date question
3. Share it and record more than ten responses so the responses table spans several pages
4. Open the survey results page and click the list icon on the date question to show the User Responses table
5. Move to page 2 and click the filter icon on any row

=> The page reloads on the unfiltered view and the selected date is not applied

Ticket [link](https://www.odoo.com/odoo/project.task/6238514)
opw-6238514

Forward-Port-Of: odoo/odoo#268569

Stacktrace during Peppol file generation when creating downpayment from POS
- activate peppol (and set system parameter to peppol demo)
- create a sale order
- on the pos, select order, choose downpayment
- pay (for example by card)
-> error: 
<img width="461" height="276" alt="image" src="https://github.com/user-attachments/assets/aadc9467-04e5-413a-97ea-8378252a56a0" />


When an invoice line has no description (name=False in Odoo ORM), base_line.get('name', '') returns False because the key exists. Using `or ''` ensures we always get a string before calling .replace().

Reproduces when generating Peppol XML for a POS down-payment invoice with no line description.

Description of the issue/feature this PR addresses:

Current behavior before PR:
stacktrace:
```
2026-07-03 12:19:39,347 46424 ERROR bsr odoo.http: Exception during request handling. 
Traceback (most recent call last):
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/service/model.py", line 188, in retrying
    result = func()
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File ".../lib/python3.13/site-packages/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File ".../lib/python3.13/site-packages/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File ".../lib/python3.13/site-packages/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File ".../lib/python3.13/site-packages/odoo/service/model.py", line 97, in call_kw
    result = method(recs, *args, **kwargs)
  File ".../lib/python3.13/site-packages/odoo/addons/pos_sale/models/pos_order.py", line 59, in sync_from_ui
    data = super().sync_from_ui(orders)
  File ".../lib/python3.13/site-packages/odoo/addons/pos_enterprise/models/pos_order.py", line 25, in sync_from_ui
    data = super().sync_from_ui(orders)
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 1271, in sync_from_ui
    order_ids.append(self._process_order(order, False))
                     ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/pos_online_payment/models/pos_order.py", line 78, in _process_order
    return super()._process_order(order, existing_order)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 151, in _process_order
    return pos_order._process_saved_order(draft)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 161, in _process_saved_order
    self._generate_pos_order_invoice()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 1196, in _generate_pos_order_invoice
    invoice.with_context(skip_invoice_sync=True)._generate_and_send()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../lib/python3.13/site-packages/odoo/addons/account/models/account_move.py", line 6770, in _generate_and_send
    wizard.action_send_and_print(allow_fallback_pdf=allow_fallback_pdf)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_peppol/wizard/account_move_send_wizard.py", line 78, in action_send_and_print
    return super().action_send_and_print(allow_fallback_pdf=allow_fallback_pdf)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account/wizard/account_move_send_wizard.py", line 397, in action_send_and_print
    attachments = self._generate_and_send_invoices(
        self.move_id,
        **self._get_sending_settings(),
        allow_fallback_pdf=allow_fallback_pdf,
    )
  File ".../lib/python3.13/site-packages/odoo/addons/account/models/account_move_send.py", line 833, in _generate_and_send_invoices
    self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account/models/account_move_send.py", line 723, in _generate_invoice_documents
    self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_move_send.py", line 132, in _hook_invoice_document_before_pdf_report_render
    ._export_invoice(invoice)
     ~~~~~~~~~~~~~~~^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py", line 46, in _export_invoice
    document_node = self._get_invoice_node(vals)
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_21.py", line 21, in _get_invoice_node
    document_node = super()._get_invoice_node(vals)
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py", line 142, in _get_invoice_node
    self._add_invoice_line_nodes(document_node, vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py", line 240, in _add_invoice_line_nodes
    self._ubl_add_invoice_line_nodes(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_ubl.py", line 1716, in _ubl_add_invoice_line_nodes
    self._ubl_add_invoice_line_node(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py", line 222, in _ubl_add_invoice_line_node
    vals['line_node'].update(self._get_invoice_line_node(sub_vals))
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py", line 415, in _get_invoice_line_node
    self._add_invoice_line_item_nodes(line_node, vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py", line 205, in _add_invoice_line_item_nodes
    self._ubl_add_line_item_node(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_ubl.py", line 1092, in _ubl_add_line_item_node
    self._ubl_add_line_item_name_description_nodes(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_ubl.py", line 929, in _ubl_add_line_item_name_description_nodes
    description = line_name.replace(name, '').strip()  # Remove the redundant product's name from the description.
                  ^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'replace'
```

Desired behavior after PR is merged:
PEPPOL file is generated



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

Forward-Port-Of: odoo/odoo#274034

Before this commit, calls to the route `/shop?search=<search_term>` would lead the search for `product_public_categories` to use a query in the shape of `product_id in (<list_of_ids>)`.
In the case where the cardinality of the product table becomes large (> 10k products), if `search_term` is very broad-spectrum, the length of `list_of_ids` reaches the size of the product table.
In that case the query generated to search for categories becomes significantly slow to parse (> 14 seconds in our tests).

This commit proposes as an alternative to resort to a sub-query to fetch the product ids that are relevant in the context of `product_public_categories`. Because of how the list of products is acquired initially, we can't rely on the `_search()` method to generate the sub-query.

The following table shows average gains for "increasing search term specificity". Here, "specificity" is determined by the amount of characters in the search term and the related number of hits expected from the search.

### Cardinality ~250k records
| Metric | ~228,872 hits | ~2,870 hits | ~377 hits | ~11 hits |
| :--- | :--- | :--- | :--- | :--- |
| Before Fix | 14.027s | 5.726s | 3.183s | 3.139s |
| After Fix | 1.216s | 3.794s* | 1.330s | 1.301s |

### Cardinality 10k records
| Metric | 8,897 hits | 1,122 hits | 15 hits | 0 hits |
| :--- | :--- | :--- | :--- | :--- |
| Before Fix | 1.386s | 3.232s* | 0.580s | 0.395s |
| After Fix | 0.756s | 3.410s* | 0.772s | 0.572s |


*Note: The increase in response time in the second column is caused by a different execution path taken (fuzzy search) which becomes the most significant path in terms of execution time once the other queries are optimized.

opw-6299343

Forward-Port-Of: odoo/odoo#271306