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

Reports with hundreds of pages and repeated barcodes or QR codes (same document number, same lot code on every page) re-run reportlab's createBarcodeDrawing and PNG encoding on every occurrence, even when type, value and options are identical.

### Current behavior before PR:

Every call to ir.actions.report.barcode() re-renders the barcode/QR from scratch, regardless of whether an identical (type, value, options) combination was already rendered earlier in the same report. On a 900-page report with 4 barcodes/page, this dominates generation time.

Benchmark, 900 pages x 4 barcodes/page, 4 distinct combos, 3600 calls: 19.131s.

### Desired behavior after PR is merged:

The pure rendering step (createBarcodeDrawing + mask + PNG encoding) is extracted to a module-level function keyed on (barcode_type, value, options, mask) and wrapped with functools.lru_cache. Repeated barcodes reuse the cached PNG instead of re-rendering.

Same benchmark after the fix: 0.020s (946.7x speedup, cache_info hits=3596 misses=4).







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

Forward-Port-Of: odoo/odoo#289979
Forward-Port-Of: odoo/odoo#289135

Before this commit, relation reads such as map, filter and some copied the entire relation into an array of proxies before starting. Even a search matching the first record paid that cost.

This commit fixes the issue by implementing these common methods directly on RecordList and centralize the lazy relation computation. On read this accesses the backing array and exposes record proxies as needed, while preserving the callback arguments the inherited array methods accept, including thisArg.

The read snapshots the array, so that any mutation during a traversal never skips or repeats a record: the read finishes on the records the relation held when it started.

Add regression coverage for traversal during mutations, completed mutation visibility to immediate observers, and callback binding.

Chrome 153, median across 18 batches in two runs, in µs per operation (lower is better):

| Operation | Records | Before | This commit |
| --- | ---: | ---: | ---: |
| `some()`, first match | 5 | 0.597 | 0.204 |
| `some()`, first match | 500 | 40.02 | 0.203 |
| `map()` | 50 | 6.10 | 5.58 |
| `map()` | 500 | 63.35 | 62.45 |
| `shift()` + `push()` | 500 | 142.38 | 49.65 |
| `pop()` + `unshift()` | 500 | 185.11 | 98.95 |
| Indexed replacement (`list[i] = record`) | 500 | 1.13 | 47.13 |

These are isolated RecordList/Owl microbenchmarks, not end-to-end Discuss UI timings.

Forward-Port-Of: odoo/odoo#287994

[IMP] ai_website: propose to allow javascript session-wise

Commit [1] added an option to add javascript and to allow it for the
whole website. This commit adds an option to allow inserting javascript
in the current chat only.

[1]: https://github.com/odoo-dev/enterprise/commit/ad87d6aac19ad4a2b0fe572fff8931c9c122723d

task-6481594

---

[REF] ai_website: rename aiScriptsRuntime to aiScriptsManager

aiScriptsRuntime wasn't the best name for it, so we renamed it to the
aiScriptsManager.

task-6481594

---

[FIX] ai_website: run ai scripts only when the dom is loaded

Scripts that are generated by AI run as soon as they are parsed, which
might lead to issues if it uses not yet parsed content.
Steps to see the issue:
- Drop a `splash_intro` snippet and some snippet after it
- Ask AI to "scroll the page down to the next section when 'Impact' is
  hovered"
=> It might check for the presence of the next section immediately when it runs, exiting the script early.

task-6481594

Forward-Port-Of: odoo/enterprise#129834

*: mrp_subcontracting_purchase

Currently, when a subcontracting MO is opened from the picking view, only
limited information is displayed. Users need to navigate to the corresponding MO
via Manufacturing Operations in Inventory to access additional details. In
addition, the MO overview displays component information based on the warehouse
instead of the subcontracting location, making it difficult to review the actual
component availability for the subcontracting process.

This commit improves the subcontracting MO by:
- Adding Overview and Transfers smart buttons, along with the start date and
component status, directly on the subcontracting MO form.
- Adding a `Free to Use / On Hand (Subcontractor Location)` column to display
the quantities available at the subcontractor location for each component in the
MO overview.
- Hide free to use/on hand and Reserved for finished product.
- Computing the `receipt status and reserved quantities` using the
subcontractor location instead of the warehouse.
- Allow replenishment of components at the warehouse from subcontracting
MO overview.
- Show the Source PO smart button only in the resupply picking view.
- Renamed the `Subcontracting Productions` smart button to `Subcontracted
Productions`.

TaskId-6234816

Forward-Port-Of: odoo/odoo#267733

Before this commit:-
- Company Data check was always created, just like other
checks.
- Company Data check's message was using static 'VAT' word.
- Drafts & Reviews check excluded moves with type `entry` for common vat report.
- Tax Reconciliation check action
   - Opens pivot view of move lines with row group by tax_tag_ids > account_id.
   - Domain used only outgoing moves.
   - There was no date filter.

After this commit:-
- Company Data check will be created only when failing, if it is passing then
don't create. Because unlike other checks, once company data is set, this check
will always pass, and creating it every time is useless.
- Company Data check's message uses dynamic vat label.
- Drafts & Reviews check now includes `entry` type moves for the common VAT
report, but only when they carry taxes.
- Tax Reconciliation check action
   - Opens pivot view of move lines with row group by tax_ids > account_id.
   - Remove domain and apply Sales and Purchase journals in default filters so
     user can remove it and see it all if needed.
   - Apply current return's date period in default filters.
   - Apply only Posted moves in default filters.
- Improved names and messages of some checks.


[task-6486107](https://www.odoo.com/odoo/project/967/tasks/6486107)

Forward-Port-Of: odoo/enterprise#130750

**Steps to reproduce:**
- Receive a mail with an embedded code block
- Open a chatter containing this message
- Error: "Cannot mount a component on a detached dom node"

**Issue:**
Mail message are rendered with a shadow dom body and isolated from surrounding styling.
```xml
<div class="o-mail-Message-shadowBody overflow-x-auto" t-if="this.message.message_type and this.message.message_type.includes('email')" t-custom-ref="shadowBody"/>
```
Then in `useLayoutEffect` parent element is created for the shadow root and the message body is created:
```js
const bodyEl = createElementWithContent(
    "span",
    this.message.showTranslation
        ? this.message.richTranslationValue
        : this.props.messageSearch?.highlight(this.message.richBody) ??
                this.message.richBody
);
const roots = this.prepareMessageBody(bodyEl) ?? [];
this.shadowRoot.appendChild(bodyEl);
```
But after [1] we have `return this.renderEmbeddedCodeBlocks(bodyEl);` which calls:
```js
const { root, mountPromise } = mountComponent(...);
```
And root creation fails as the element is not on the shadow root yet (due to `validateTarget` and `isAttachedToDocument`).
```js
const root = app.createRoot(Component, { props, env });
```

But even if we have the element directly added on the `shadowRoot` the highlighting styling won't be applied properly without all the needed assets.

**Fix:**
Prevent `ReadonlySyntaxHighlightingComponent` for incoming email body.

Doesn't seem worth to try to load the needed css/style elements in the shadow root.

[1] https://github.com/odoo/odoo/commit/8fa3cc31e8b81645d40b5d09c925b57d2c0558ab

opw-6463735

Forward-Port-Of: odoo/odoo#288136
Forward-Port-Of: odoo/odoo#287977

eproduction steps:
 - MRP subcontracting + purchase
 - Subcontracted product with BOM
 - Create PO with a qty > 1 for this product
 - Go into barcode
 - Scan > 0 and < all of the expected quantity
 - Back out of barcode
 - Click validate -> Error **OR** Go back into barcode, attempt to validate -> Error

Added the StockMove and StockPicking classes to stock_barcode_mrp_subcontracting
to extend functions `_subcontracted_produce`, `_clean_merged`, and `split_uncompleted_moves`
to use a new context flag, `keep_subcontract_production`. When this flag
is set, the move Barcode creates from the split keeps the MO of the move
it was split from rather than splitting the MO in two, gives that link up
before it is merged away so its cancellation does not cancel the MO, and
the MO quantity is resynced with the merged move afterwards.

Error thrown here:
https://github.com/odoo/odoo/blob/f84eeb3ed1421e0cc07c906ff6444734dc01d35f/addons/mrp_subcontracting/models/stock_move.py#L248

opw-6428928

Forward-Port-Of: odoo/enterprise#131459

Steps to reproduce:
- Ecuadorian company, PoS with a preparation printer (or use the "Back" button on the feedback screen)
- Open a session, add a product, go to the payment screen
- Select a customer, uncheck "Invoice", pay in cash and validate

Issue:
An invoice is created and sent to the SRI although "Invoice" was unchecked.

Cause:
l10n_ec_edi_pos patches PosOrder.setup() to force to_invoice = true. setup() runs not only on creation but every time the record is reloaded from the server, so the sync done at validation flips the flag back to true in the browser. Since the paid order can now be re-synced after validation (kitchen printer, "Back" on the feedback screen), the server processes it in process_saved_payments, writes to_invoice = True and generates the invoice.

Fix:
Only apply the Ecuadorian default when the loaded values carry no to_invoice, i.e. for a newly created order. Reloaded records keep the value the user chose.

opw-6572987

Forward-Port-Of: odoo/enterprise#131612

[FIX] ai_website: save custom css scoped

Before this commit, if you had multiple websites, AI wouldn't save
custom css in the correct website's bundles, which caused the following
broken flow:
- open css editor, make any changes, and save it
- open the AI website builder agent and ask it to make all buttons red,
  writing a custom css for that

=> you get a traceback, and after reloading your website is broken.

Note that this isn't an issue in 20.0 as this behavior has been changed.

Related to task-6578231

---

 [FIX] ai_website: validate custom SCSS with bundle url rewriting

When AI used url($var) in scss, it would break the style compilation and
display an error. This happened because compiling replaced relative urls
with the absolute path. It wasn't caught before saving the custom css,
because we preprocessed css content inline, which doesn't rewrite
relative url()s.

To directly check it, you can just ask it to save this custom css:
`'$img: "a.png"; #test { background: url($img); }'`
=> Style compilation will fail.

Also, this commit updates some already present nested `with` statements
in tests to remove Ruff warnings.

task-6578231

Forward-Port-Of: odoo/enterprise#132463
Forward-Port-Of: odoo/enterprise#131954

**Steps to reproduce:**
- Install Appointment app
- Create an appointment type based on resources, auto-assigned, with two shareable resources linked together
- Set the first resource's capacity to 3 and the second resource's capacity to 4
- From the backend Gantt view, create a booking for 2 people on the first resource
- Create a second booking for 2 people on the same resource, at the same date and time
- First resource is now overbooked with reserved capacity of 4 out of 3
- Try to create an appointment from the website
- Error: "The capacity reserved should be positive."

**Issue:**
When bookings are created from the backend gantt view, the selected resource can be overbooked even if another linked resource still has available capacity.

Then when trying to book an appointment the new booking lines will trigger this constraint:
```py
_check_capacity_reserved = models.Constraint(
    'CHECK(capacity_reserved >= 0)',
    "The capacity reserved should be positive.",
)
```
This is caused by the negative values in:
```py
booking_line_values = []
if appointment_type.schedule_based_on == 'resources':
    capacity_to_assign = asked_capacity
    for resource in resources:
        resource_remaining_capacity = resources_remaining_capacity.get(resource)
        new_capacity_reserved = min(resource_remaining_capacity, capacity_to_assign, resource.capacity)
        capacity_to_assign -= new_capacity_reserved
        booking_line_values.append({
            'appointment_resource_id': resource.id,
            'capacity_reserved': new_capacity_reserved,
            'capacity_used': new_capacity_reserved if resource.shareable and appointment_type.resource_manage_capacity else resource.capacity,
        })
```

**Fix:**
Avoid negative remaining value in resource booking when computing available slots.

Note: Tried to take the capacity already used by overlapping bookings into account when assigning resource booking lines from the backend gantt view. And also force linked_resources booking when trying to book more
than the total capacity to properly dispatch as many slots as possible. But it was breaking `appointment_google_reserve` tests.

opw-6503147

Forward-Port-Of: odoo/enterprise#132484
Forward-Port-Of: odoo/enterprise#130520

Issue Before This Commit:
=========================
Currently, the Purchase Order Line field on the vendor bill line allows users to 
select purchase order lines regardless of the purchase order state. As a result,
lines from purchase orders that are not confirmed can also be selected and 
linked to vendor bill lines.

Steps to Reproduce:
===================
- Install Purchase and create an RFQ.
- Create a vendor bill for the same vendor.
- Add a bill line and enable the Purchase Order column.
- Open the dropdown of the Purchase Order Line field.
- Observe that lines from unconfirmed purchase orders are available
  for selection.

Cause of the Issue:
====================
This [PR](https://github.com/odoo/odoo/pull/266003) made Purchase Order lines selectable directly on bill lines, 
but the selection domain did not restrict the lines to confirmed purchase orders. 
Therefore, lines from unconfirmed purchase orders remained available for selection.

After This Commit:
==================
Only Purchase Order lines from confirmed purchase orders are selectable
on vendor bill lines.

Forward-Port-Of: odoo/odoo#288858

When a translatable field is displayed in the multi create popover (e.g. in a calendar view with a `multi_create_view`), the rendering of the popover crashes when the props are validated (in debug mode) with "Invalid component props (TranslationButton)", `resId` being reported as a missing key of the `record` prop.

The `TranslationButton` indeed requires a `resId` on the record it receives, which must be `false` when the record doesn't exist yet. The record of the popover is produced by the `Record` component (`@web/model/record`), which forwards its `resId` prop as is to the config of the standalone model. As no `resId` is given for that new record, the datapoint ends up with an `undefined` `resId`, which is considered as a missing prop by the props validation.

Normalize the `resId` in the model, such that a mono record config always has a `resId`, which is `false` when the record is new, as the `FormController` and the datapoints created by the lists already do. `_getNextConfig` is the single entry point of every load, so every root datapoint is covered, whatever the caller.

The next props are normalized as well in the `Record` component, otherwise each re-render of the parent would trigger a useless reload (`undefined !== false`).

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#289585

Issue Before this Commit:
=====================
Clicking on the rescheduling popover widget on the picking form leads to a page
crash.

Steps to Reproduce:
=====================
1. Install the `stock` module.
2. Create a storable product, then create a delivery order for it
3. Create a receipt for the same product, and `set its Scheduled Date to a date later than the delivery order's Scheduled Date`.
4. Open the Allocation Report from the receipt and assign the received quantity to the delivery order.
5. Open the delivery order and click the Danger icon next to the Scheduled Date. Observe that the page crashes with the following error:
`Uncaught Promise > Invalid loop expression: "undefined" is not iterable`

Cause of the Issue:
=====================
The `late_elements` is not defined in `useProps` of
`StockRescheculingPopoverComponent`, even though it was used by the
`stock.PopoverStockRescheduling` template. As a result, the template tried to
iterate over `undefined`, leading to a page crash.

After this Commit:
=====================
This commit defines the `late_elements` and `delay_alert_date` in useProps so
that the values are correctly available in the component and the rescheduling
popover renders without crashing.

Forward-Port-Of: odoo/odoo#288895

Step to reproduce:
------------------
- Install `pos_sale_stock` and `mrp` module.
- Go to the setting enable "Replenish on Order (MTO)"
- Create a storable product with the MTO route
- Create a Bill of Materials for the product with a storable component
- Now Create Sale order for the Product and confirm it.
- Open POS Store and settel Created sale order.
- Process toward payment and try to validate it.

Issue:
------

`AssertionError: Invalid falsy real id`

Cause:
------
When an MTO product with a manufacturing Bill of Materials is added to a Sale Order and the SO is confirmed, Odoo creates two distinct sets of stock.move records that share the same stock.reference group:

1. **Delivery moves** (picking_id → stock.picking) Created by the outgoing stock rule triggered by the MTO route. These moves are assigned to a delivery picking and have a valid picking_id.

2. **Manufacturing component moves** (picking_id = False) Created by the Manufacture route's procurement rule, which spawns an mrp.production. The raw-material moves inside an MO belong to the production order, not to any stock.picking. Their picking_id field is intentionally False by design.

Both sets of moves are linked to the same stock.reference record through the stock_reference_move_rel many2many table. This means that traversing:

    so_line.move_ids          → delivery move(s)
    .reference_ids            → shared stock.reference
    .move_ids                 → ALL moves in the group (delivery + MRP)

every move in the reference group, including MRP component moves whose picking_id is False.

- Then In PosOrder.sync_from_ui(), the code collected the IDs of all related pickings into a set for later cancellation:

https://github.com/odoo/odoo/blob/a0cdf9c33ed464b4ec8bd520e4d0523afb8dbd28/addons/pos_sale/models/pos_order.py#L111

https://github.com/odoo/odoo/blob/a0cdf9c33ed464b4ec8bd520e4d0523afb8dbd28/addons/pos_sale/models/pos_order.py#L130-L133

        waiting_picking_ids.add(move.picking_id.id)   # ← adds False for MRP moves

Because MRP moves pass the state filter ('confirmed') but have picking_id = False, `move.picking_id.id` evaluates to False (the empty recordset's falsy id), which was silently added to the waiting_picking_ids set.

Issue occur from this [commit](https://github.com/odoo/odoo/commit/515eb5ba0892a759dde32a9b2923d8ecc1e4bf74?debug=1), the ORM assertion in browse() rejects falsy IDs:

https://github.com/odoo/odoo/blob/a0cdf9c33ed464b4ec8bd520e4d0523afb8dbd28/addons/pos_sale/models/pos_order.py#L139

https://github.com/odoo/odoo/blob/9e02922f821a3b4e891e90bf9bd18448a08e66fa/odoo/orm/models.py#L5297

Fix:
---
Add guards in `sync_from_ui()`
*Inner filtered() guard* — add `m.picking_id` as the first condition so
   that MRP component moves (picking_id = False) are never iterated, preventing
   `False` from ever entering the set

---

opw-6486681

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

Forward-Port-Of: odoo/odoo#289890
Forward-Port-Of: odoo/odoo#284103