**Steps to produce:**
- Install `website_sale` with demo data.
- Go to the shop page.
- Select product `Customizable Desk` > click `Add to cart`.
- In the wizard, change the quantity to 100 and directly click `Checkout`.

**Issue:**
- The cart shows the product with quantity = 1 instead of the edited value.

Root cause:
- When the user clicks Checkout, both `setQuantity` and `onConfirm` are triggered
  almost simultaneously.
- At [1], the `_setQuantity` method is called, but due to the await before the
  quantity update is completed, the update may not finish in time. As a result,
  the previous quantity is sometimes used during checkout instead of the
  newly selected one.

Solution:
- we can update the quantity immediately before awaiting `_updateCombination`,
  ensuring that the correct quantity is already set when onConfirm runs.

[1]: https://github.com/odoo/odoo/blob/f4eabe47a602301013afa63da6bdf87809903d29/addons/sale/static/src/js/product_configurator_dialog/product_configurator_dialog.js#L225

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

Forward-Port-Of: odoo/odoo#247866
Forward-Port-Of: odoo/odoo#241424

If provided a `datetime.time`, `babel.dates.time_format` needs to complete it to a datetime in order to resolve timezone offsets (and legacy names). In order to do that, it ultimately uses "now" as the reference: [`format_time`] calls [`DateTimePattern.apply`] which calls [`DateTimeFormat.__getitem__`] which calls
[`DateTimeFormat.format_timezone`] which calls [`get_timezone_gmt`] which calls [`_get_datetime`], which for a `datetime.time()` input resolves:

    return datetime.datetime.combine(datetime.date.today(), instant)

This means DST changes impact the timezone being resolved timezone (offset or legacy name), which is what occurred here: S summer time starts on the second sunday of March at 0200 local which for 2026 is 2026-03-08 0200, faketime builds started failing with a virtual time of 2026-03-08 12:00 UTC which is well past 0200 local in America/New_York, and thus into the summer timezone, with an offset of -0400, thus different from the reference offset of -0500.

The reference date can be fixed to anything which results in standard time in all the timezones being checked, so between the first sunday of november (end of DST in the US) and the last sunday of march (start of DST in Europe), in the past (to ensure no DST rules change). Just use the reference date of the test itself as it's fine enough.

Now why did this test pass before #236660? This was hinted at when I needed to fix the offset from -0504 to -0500 but it didn't register as it was a minor edit: because the timezone was associated via `tzinfo` rather than `localize`, `pytz` was not able to select the correct timezone so would just select some prehistorical timezone, which doesn't have DST rules associated, and so would remain on standard time year round.

With the switch to zoneinfo the timezone can be interpreted dynamically, leading to the timezone offset varying when the reference date changes, and thus the issue revealing itself.

And `odoo.misc.format_time(datetime)` has a similar issue, because it strips out the `date` part of a `datetime` input, so similarly babel itself receives a lone zoned time, which it resolves using the date at the time of the test running. Which is funny because `babel.dates.format_time` itself can take a `datetime` and will use that directly for its timezone resolution, so on this bit we shot ourselves in the foot.

https://runbot.odoo.com/odoo/runbot.build.error/238900

[`format_time`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L841
[`DateTimePattern.apply`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L1424
[`DateTimeFormat.__getitem__`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L1487
[`DateTimeFormat.format_timezone`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L1675
[`get_timezone_gmt`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L459
[`_get_datetime`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L158

**Steps to reproduce:**
- Go to the current user preferences
- Go to its signature field
- The current state should be something like:
```
--
Mitchell Admin
```
- Apply bold formatting on the text
- Save the changes
- Refresh
- Remove the bold formatting
- Press enter between the two lines (at the end of `--`)
- Save the changes
- Go to the Contact app
- Select any record
- Go to its chatter
- Click on `Send Message` and then the `Full Composer` expand button
- Send the mail
- In the chatter multiple `Read More` are added for the same signature

(I think it can appears in multiple operations,
this is just an example related to the `<strong>`
element becoming `<span>` on removal)

**Issue:**
Playing with the html editor on the signature field can break the `tag_quote` flow due to the added elements.

**Fix:**
Explicitly add `"data-o-mail-quote"` to the signature container which is added when opening the `fullComposer`.
It could also be an issue related to the html_editor but this seems cleaner to fix it here.

This issue was fixed in 19.0 in a similar way by adding a common div around the signature and adding the same attribute.

related: https://github.com/odoo/odoo/commit/6eb55c42158b08652c4c533bf56b5333c162bd3a

opw-5149505

Forward-Port-Of: odoo/odoo#247560
Forward-Port-Of: odoo/odoo#231954

Currently, accessing the Forecast report on a Product Template causes a crash if the template contains an archived variant that still has active stock moves (e.g., a pending delivery).

## **Steps to Reproduce:**
1) Install `stock` with demo data.
2) Create a Delivery orders(stock picking) for product `conference chair(E-COM12)`
   with demand of 40 qty, click on `Mark as todo`.
3) Navigate to `stock>products>products` and open `conference chair` product form
   view.
4) From the variant smart button archive `E-COM12` variant.
5) Navigate back to product form view and click on `forecast` smart button.

## **Error:**
`TypeError: Cannot read properties of undefined (reading 'free_qty')`

## **Root Cause:**
`this.props.docs.product[line]` at [1] is undefined because the server did not
include an entry for that product id in the report header.

### **Complete Flow:**

On clicking the Forecast button an ORM call is made to [_get_report_values](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L512-L519),
which calls [_get_report_data](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L156-L172) to build the report data.

#### **Header Part:**
- [_get_report_header](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L112-L144) returns metadata only for active variants because,
  [_get_product_quantity](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L69-L72) is called which calls _get_products(see[2]), and _get_products only
  returns active variants for the product template.

#### **Lines Part:**
- [_get_product_lines](https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L239) iterates over products coming from the move search
  and it includes both archived and unarchived variants.
  [_move_confirmed_domain](https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L55-L56) calls _move_domain(see[3]), which searches stock.move using
  product_tmpl_id when given a template id and therefore returns moves for
  every variant of the template (archived or not).

#### **Why the mismatch happens:**
- `_get_products` fetches variants using `browse()` which by default excludes archived variants.
  `_product_domain`(see[3]) uses product_tmpl_id when given product_template_ids,
  which matches moves for all variants of the template. As a result, moves can reference
  archived variant ids that the header never listed.

[1]- https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/static/src/stock_forecasted/forecasted_details.js#L188

[2]- https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L61-L67

[3]- https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L25-L31

## **Fix:**
- This commit ensures that archived product variants are excluded directly
  at move search level by appending `('product_id.active', '=', True)` to
  the product domain used by the forecast report. This ensures that only
  active product variants are considered when fetching stock moves.

### **opw-5440872**

Forward-Port-Of: odoo/odoo#245852

Currently, an error occurs when a user changes the stage of lead.

**Steps to Reproduce:**
 - Install the `crm` module.
 - Go to `crm` and switch to `List view`.
 - Click `New` and then click on any `stage`.

`AssertionError: Invalid falsy real id`

This error occurs because, after the recent commit [1], falsy IDs are no longer allowed.
When the user changes the stage without creating the record, the record ID is passed
as False when it goes to calculate the rainbowman message [2]. Browsing the record with
a falsy ID [3] then raises this error.

This commit ensures that if a record has no ID and the stage ID is changed, the rainbowman
message is not calculated.

[1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f

[2]: https://github.com/odoo/odoo/blob/6bce0128fdd5176c55ac9ed5af1922c1f6f97da5/addons/crm/static/src/views/crm_form/crm_form.js#L51

[3]- https://github.com/odoo/odoo/blob/403f3cf8d291ff2023fc4c5d3631a01465f292c3/odoo/orm/models.py#L5200

sentry-7207509338


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

**Problem:**
the cogs do not take into account lot valuation and the standard 
price of the form is not updated after a move out.

**Steps to reproduce:**
- create storable avco perpetual product, tracked and valued by lot
- confirm a purchase order for 2 qty at price 10
- in the receipt add 'lot 1' for the lot
- validate
- confirm a purchase order for 2 qty at price 16
- in the receipt add 'lot 2' for the lot
- validate
- confirm a sale order for a qty of 1, validate the move
- invoice the sale order, and confirm the invoice

**Current behavior:**
1) the cogs line (stock valuation and expenses) have a value of 13
(the avco value)
2) the standard price on the form view is still 13

**Expected behavior:**
1) it should be 10 (the value of lot1)
2) it should have been updated to 14 (weighted average of the lots value)

**Cause of the issue:**
1) get_cogs_price_unit() is taking standard price of the product
if the product is not fifo.
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/stock_move.py#L245 
In case of avco lot valuated product, this is not correct, the value should be 
the sum of (the value of each lot * the number of product from this lot in the 
moves) divided by the total quantity. 
this value can be obtained be dividing the total value of the moves by the total 
quantity. 

2) after the move is validated, the standard price should be updated because 
for lot valued product, the avco value can change after a move out. 
Currently it's only updated for fifo products.
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/stock_move.py#L172

**fix**
For the diff inside _update_standard_price() for problem 2,
I use avg_cost instead of doing the computation directly in 
_update_standard_price() to not duplicate code logic
 because the computation logic for lot valued products is 
already inside _compute_value()
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/product.py#L152-L157

The extra dependency on compute_value on the stock.lot model 
is needed because otherwise total_value of the lot is not 
invalidated in the cache after an out mouve is validated
(in our steps it will stay in cache with a value of 20 even 
after the out move is validated). 
With our steps this does not cause problem because when we use 
the avg_cost value for the product,  \__get__() is called on total_value of the lots, 
but it was not in cache because we didn't compute it before in 
this environment , so it will be recomputed with correct current value . 
But in other cases where the action_done is called on 
the move and there is already a value in cache for total_value 
of the lots (like in the test of this commit for instance), 
this value will become wrong after the move is validated 
and the cache won't be invalidated which will lead to 
incorrect computation of avg_cost because it will use the 
wrong cache value of total_value for the lots.

the test needs to be in sale_stock because the moves used 
for the cogs are being returned via the sale_stock override 
of _get_stock_moves()
https://github.com/odoo/odoo/blob/7ae112acd0c333f09c54e4eabbd22bcef72c32a7/addons/stock_account/models/account_move_line.py#L67

opw-5459082

Forward-Port-Of: odoo/odoo#246821

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Forward-Port-Of: odoo/odoo#248009
Forward-Port-Of: odoo/odoo#241603

**Issue**
When producing a large number of serial-tracked products, a RecursionError can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo
-> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/odoo#247839

### Steps to reproduce:

1. In the settings enable: Multi-steps route
2. Put your warehouse in 2-step deliveries
3. Create a kit product:
   - With one component
   - There is one component in the stock
4. Create and confirm a SO with 1 x K
5. Process the pick and ship
6. Return the delivery
7. Set the sol qty to 0
#### > Two unexpected pickings are created to put the kit in output

### Cause of the issue:

Decreasing the sol quantity to 0 will call the `_action_launch_stock_rule` in order to create and run procurements related to that quantity change. However, the quantity currently handled by other procurements is determined here by the `_compute_kit_quantities`:
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_mrp/models/sale_order_line.py#L154-L166 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/mrp/models/stock_move.py#L578-L580
Now, the issue is that `_compute_kit_quantities` does not handle move chains properly, as all delivery moves contribute to the `incoming_qty` and all return moves contribute to the `outgoing_qty`. This results in an `incoming_qty` of 1 (for the pick) + 1 (for the ship) and an `outgoing_qty` of 1 (for the 1-step return), that is a `qty_processed` of 1. As a result, the procurement will be generated for a quantity of `0 - 1` (rather than 0):
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388-L402 
which leads to the unexpected picking creations.

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

Forward-Port-Of: odoo/odoo#246141

**Steps to produce:**
- Install `mrp` with demo data.
- Inventory > Configuration > Settings > Warehouse > enable `Multi-Step Routes`.
- Go to Configuration > Warehouse Management > Warehouses.
- Open `YourCompany` record.
- Click on Routes > open `Manufacture` > enable `Products`.
- Return to `YourCompany` and disable `Manufacture to Resupply`.

**Issue:**
- After disabling `Manufacture to Resupply`, the option is automatically re-enabled.

**Root cause:**
- In [1], `manufacture_to_resupply` is set to true if either
  `manufacture_route.product_selectable` is true OR the current warehouse
  is included in `manufacture_route.warehouse_ids`.
- In the `_inverse_manufacture_to_resupply` method, unchecking the flag only
  unlinks the warehouse from the route. However, if `product_selectable` is
  still enabled, the compute logic will continue to set the field back to true.

**Solution:**
- Now, when we uncheck `manufacture_to_resupply` then also made manufacture
  route non-selectable on products. As a result, manufacture_to_resupply
  will no longer be set to true again.

[1]https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/mrp/models/stock_warehouse.py#L48

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

Forward-Port-Of: odoo/odoo#239217

This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines.

Steps to reproduce:
1. Create payment with x amount and validate it.
2. Open the payment journal entry.
3. Reset to draft and update the liquidity line amount from x to (x - y)
4. Create another liquidity line with amount y to balance entry and post it.
5. Draft the payment and try to update the amount.

A traceback will appear. `ValueError: Expected singleton`

Cause:
The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error.

Description of changes made:
While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write.
Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually.

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

Forward-Port-Of: odoo/odoo#246675

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made.

### **Steps to reproduce:**
1) Install `l10n_gt_edi` and switch to a GT company. 
2) Create a branch of the GT company.
3) In the parent company, go to Accounting Settings, set the Guatemala
   Localization to 'Demo', and save.
4) Switch to the branch company.
5) Open Accounting Settings and click Save.

### **Observed Behavior:**
An error occurs because `l10n_gt_edi_service_provider` is empty but required.

### **Root Cause:**
The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails.

[1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22

### **FIX:**
Update the `required` domain to include `l10n_gt_edi_is_root_company`.
This ensures the field is only mandatory in the root company where it
is actually visible and configurable and also set the `l10n_gt_edi_service_provider`
for branch company same as parent company.

**opw-5385819**

Forward-Port-Of: odoo/enterprise#106323

## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift

Before this commit, the user could update the shift linked to a rental
order and creating a conflict with another shift for the same resource
and so, it would be impossible for the resource to be in 2 spaces at the
same time (or it is impossible to rent a room to 2 different customers).

This commit returns an Validation Error if the user updates the planned dates
of a rental shift and creates a conflict.

## [FIX] sale_renting_planning: add problematic shifts only if rental order

Before this commit, the previous fix making sure the error, saying no
resource is available during the generation of a shifts when the user
confirms a sale order, is only displayed when the `Sync Shifts and
Rental Orders` is enabled, could potentially never display the error
when it should be expected because we only check if the last SOL of the
batch to generate shifts has the feature enable or not.

This commit makes sure the error is correctly displayed as expected.

## [FIX] sale_renting_planning: update condition of Rental buttons in shift

Before this commit, the user could click on Create order button for an
open shift is the role having the rental feature enabled. To problem is
a resource is required to make sure the rental order can be delivered.
About the other button shown, `Add to Last Order` one, this one could be
clicked even if the shift is in conflict with another shift and so, it
will display a warning saying no resource is available.

This commit makes sure
- `Create Order` button in shift form view is not
visible when the shift is a open shift.
- `Create Order` and `Add to Last Order` buttons in shift form view are
not displayed when the shift is in conflict.

task-5065930

Forward-Port-Of: odoo/enterprise#97024

Currently, an error occurs when selecting a date on a rental product. 

**Steps to Reproduce:**
 - Install the `website_sale_stock_renting` module.
 - Go to `Products` and create a product with the following `configuration`:
   - Enable `Track Inventory` and set `Quantity On Hand` greater than zero.
   - Disable `Sell when Out-of-Stock` under the `eCommerce tab`.
   - Under the `Sales tab`, set `Periodicity to Days`, and set the same time for `Pickup and Return`.
 - Go to `Website > Shop`.
 - Open the product, select the same date for both `Start Date and End Date`, and `click anywhere`.

`ValueError: min() iterable argument is empty`

**Cause:**
 - This error occurs because when the start and end dates are the same, the method returns a set 
   of dates from here [1]. Since there is only a single date, the loop is not executed and it returns 
   an empty list of availabilities [2], which then raises the error [3].
 - The error happens due to the removal of this condition [4] in this [recent commit].
 - The warning message is now handled here [5].

**Fix:**
 - This commit ensures that when a user selects a start date that is greater than or equal to the 
   end date, a UserError is raised and the proper warning message is displayed.

[1]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/sale_stock_renting/models/sale_order_line.py#L616

[2]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/product_product.py#L77

[3]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/website.py#L18-L22

[4]: https://github.com/odoo/enterprise/blob/66f144df6f2056212797547dfef5ed58232698cd/website_sale_renting/models/product_template.py#L175-L176

[5]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_renting/static/src/interactions/daterange_picker.js#L213

[recent commit]: https://github.com/odoo/enterprise/commit/4afdc272e5a7fc4284bbd9f97283b8ec0aa28c34

sentry-7243018656

**Issue**
When producing a large number of serial-tracked products, a RecursionError can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo -> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/enterprise#106999