### Issue

Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).

### Analysis

Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.

### Solution

Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.

For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.

### Benchmarks

Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types

| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |

### References

opw-5130725

Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key.

BEFORE:
Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC)

NOW:
Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour.  

Note:
I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4
as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different)

task#4629641

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Version:
- 18.0

Steps to reproduce:
1. create a subscription with a mixed invoice_policy (order + delivered)
2. pay through the portal
3. on the next_invoice_date of the subscription:
   - set qty_delivered = 1 for the delivered-policy product.
   - run _cron_recurring_create_invoice to generate a new invoice.

Issue:
When cron generates the invoice for the delivered product, the system links two
payment transactions to this invoice

Cause
- On portal confirmation, only order-policy products are invoiced.
- Because the delivered products are not invoiced upfront, the initial payment
  transaction gets linked only to part of the subscription.
- Later, when 2nd invoice is generated by cron, the system reuses the original
  payment token and tries to apply payment for both (delivered + ordered) again.

Solution
- When confirming a subscription with portal payment, create the invoice for all
  products (order + delivered).
- This way, the first payment covers the whole subscription and later invoices
  won’t get duplicate payments.

Taskid-4250892

Versions
--------
- 18.0+

Steps
-----
1. Have a product with multiple variants;
2. go to one of its attributes;
3. in the form, change the default extra price on multiple lines;
4. click on "Update extra prices";
5. add the updated variants to a sale order.

Issue
-----
Only the line on which "Update extra prices" was clicked has been updated, even though the button disappeared on all lines after clicking it.

Cause
-----
The `_compute_default_extra_price_changed` method only compares the `default_extra_price` of the current record to its `_origin` value. Consequently, after saving the form, it will return `False`, even though only one attribute has been updated.

Solution
--------
Aside from checking whether the value changed on the form, also check whether any product template attribute value has a `price_extra` that's different from the product attribute value's `default_extra_price`.

This way, clicking on "Update extra prices" once won't make the other update buttons disappear.

opw-5240236

### Steps to reproduce the issue:

(Easier to reproduce client side with CRM installed)

0. Install crm
1. Create Second Company
2. Create New User with Current Company as Default Company and Second Company in Allowed Companies
3. Create CRM Team belonging to Second Company
4. Add New User to Members of CRM Team
5. Receive error:

>     [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company.

### Explanation:

`crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it.

### Fix reasoning:

Removing restriction, as we want to avoid other multi-company issues by changing the behaviour.

opw-4214192

---

@nd-dew note:
Situation recap
![image](https://github.com/user-attachments/assets/9377ec70-0a57-4a48-b071-de588cde06a6)

So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). 

However looking at the tests it seems like this is desired limitation.

Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority.

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#225014

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

In the POS of a Mexican company, when requesting an invoice, the user
is asked to set the invoice to public or not. If the customer does not
have a recognized ZIP code or country, setting the invoice to public
**should not** raise an error, but it does. This is because the
`l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM,
which leads to the UserError below being triggered, as
`l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not
updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a *compute field*.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: \[[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)\]

To minimize behavioral changes, the required field
(`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not
longer raised when the *Invoice to Public* field is set to "Yes"
in the POS.

### Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"*
and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#98983

Versions
--------
- 18.0+

Steps
-----
1. Have a minimal database with `event_product` installed;
2. run `:TestEventProduct.test_ensure_event_service_tracking`.

Issue
-----
> FAIL: TestEventProduct.test_ensure_event_service_tracking
> AssertionError: ValidationError not raised

Cause
-----
The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30

This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183

As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised.

Solution
--------
Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected.

runbot-234024

Steps to reproduce:
===================
1- Website app > Open any page in Edit mode.
2- Drag a Video block into the page.
3- Paste a Vimeo video URL in the dialog and save. 
4- Save the page, then re-open it in Edit mode.
-> traceback

Cause:
======
The Wysiwyg "openMediaDialog" passes the selected media DOM node as "media" to the MediaDialog.
The MediaDialog forwards that value as "media" prop to VideoSelector. VideoSelector declared "media" as "{ type: Object, optional: true }". Owl validates "type: Object" as a plain object, not as any "typeof object".
DOM elements such as HTMLImageElement do not pass this plain object check, so Owl raises an error.

Solution:
=========
Relax the "media" prop type in VideoSelector so DOM nodes are accepted. In web_editor VideoSelector, change the "media" prop to "{ optional: true }".
In html_editor VideoSelector, also keep "media" declared as "{ optional: true }".

opw-5239889

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