#### Description of the issue/feature this PR addresses:
In the Singapore localization (l10n_sg), reverse charge is modelled as a group tax pairing a -9% SRRC child with a +9% TXRC child, so the GST on a bill nets to zero while both legs are still reported in their respective GST return boxes. The child taxes "9% TXRC-TS" and "9% TXRC-ESS" shipped inactive, while their siblings "9% TXRC-N33" and "9% TXRC-RE" shipped active. Because children_tax_ids is a many2many onto account.tax (which has an active field), inactive children are filtered out of the group, so the groups "Reverse Charge - SRRC + TXRC-TS" and "Reverse Charge - SRRC + TXRC-ESS" only kept the -9% SRRC leg and computed a wrong GST amount, while leaving the +9% leg out of the GST return.

#### Current behavior before PR:
A vendor bill of S$10,000 taxed with "Reverse Charge - SRRC + TXRC-ESS" (or "+ TXRC-TS") shows 9% GST = -S$900.00 and a total of S$9,100.00 instead of net S$0.00 / S$10,000.00. The +9% TXRC leg never reaches Box 5 / Box 7 of the GST return. The sibling groups "+ TXRC-N33" and "+ TXRC-RE" are unaffected because their children are active. The only workaround is to manually activate the two child taxes.

#### Desired behavior after PR is merged:
The "9% TXRC-TS" and "9% TXRC-ESS" child taxes are active by default, so the group taxes aggregate both legs: a S$10,000 bill shows 9% GST = S$0.00 with a total of S$10,000.00, and both reverse charge legs land in their GST return boxes. New SG databases get this from the tax template; existing SG databases get the two taxes reactivated by a migration on upgrade.

opw-6199248

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

Forward-Port-Of: odoo/odoo#267670

[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf)
and deduplicating overlaps

* Current Situation: Currently real duration is total duration of each
time tracking which
is not consistent with the time that use to calculate the cost for
valuation , see https://github.com/odoo/odoo/pull/205154 .The real
duration of a work order was incorrectly summing all time tracking
entries regardless of their loss type, and using simple addition which
double-counts overlapping intervals.

* Solution:
- Filter time entries to only 'productive' and 'performance' loss types,
  excluding 'availability' and 'quality' as they represent
downtime/blocking
  time, not actual work duration.
- Pool all productive and performance entries into a single Intervals
call
  so that overlaps across both types are merged in one pass.

Note: the enterprise17 implementation groups time entries by loss_type
into
separate buckets before calling Intervals, which means overlaps between
'productive' and 'performance' entries are not merged and get
double-counted.
Pooling both types together before the Intervals call avoids this.

* This also fix:
- Fix _set_duration to ensure newly created time entries start after the
  latest existing entry's end date. Without this, calling _set_duration
  twice in quick succession (e.g. in tests) produces two entries with
  overlapping timestamps, which Intervals correctly merges into one,
  causing the computed duration to be half the expected value.




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

Forward-Port-Of: odoo/odoo#270809
Forward-Port-Of: odoo/odoo#248381

Currently, an error occurs when a user tries to create a group time off.

**Steps to Reproduce:**
 - Install the `hr_presence` module without demo data.
 - Go to `Employees` > `Configuration` > `Working Times` > `Time Types` and 
   delete all records.
 - Make sure there are at least `two employee` records.
 -  Go to `Employees` and switch to the `list view`.
 - Select `both employees` > click `Presence Control` > click `Create a Time Off`.

**Error1:**
`TypeError: unsupported operand types in: hr.work.entry.type() | None`

**Error2:**
`AttributeError: 'NoneType' object has no attribute 'ids'`

When a user creates a group time off record and the wizard is opened, it computes the valid work 
entry types. If no work entry type exists, accessing the `True` key (`requires_allocation`) from the 
empty dictionary returns None [1]. Later, when performing a union (|) between an empty work entry 
type recordset and None, it raises the first error [2]. Additionally, accessing ids on None raises 
the error [3].

This commit ensures that when no work entry type exists, accessing key(requires_allocation) from 
an empty dictionary returns an empty work entry type record instead of None.

[1]- https://github.com/odoo/odoo/blob/374f48cfba75ff98f53d8c3fcc51847711bd406a/addons/hr_holidays/wizard/hr_leave_generate_multi_wizard.py#L144-L145

[2]- https://github.com/odoo/odoo/blob/374f48cfba75ff98f53d8c3fcc51847711bd406a/addons/hr_holidays/wizard/hr_leave_generate_multi_wizard.py#L146

[3]: https://github.com/odoo/odoo/blob/374f48cfba75ff98f53d8c3fcc51847711bd406a/addons/hr_holidays/wizard/hr_leave_generate_multi_wizard.py#L148

sentry-7552717400

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

Forward-Port-Of: odoo/odoo#270302

Currently an error occurs when user opens stock report after uninstalling mrp.

Steps to replicate:
- Install mrp.
- Uninstall mrp and open `Stock > Reporting > Stock`.

Error:
```
ValueError: Invalid field product.product.is_kits in condition ('is_kits', '=', False)
```

Cause:
- The `mrp` module overrides the `stock.action_product_stock_view` window action domain with `is_kits` field referenced inside [1].

- When mrp is uninstalled, the `is_kits` field is removed from `product.product` but the overridden action domain remains stored in the database. Opening the action then tries to evaluate a domain referencing a non-existent field, resulting in this error.

Solution:
- Restore the original `stock.action_product_stock_view` domain during mrp uninstallation to remove the `is_kits` condition.

[1]: https://github.com/odoo/odoo/blob/c8390638cae4b4dafb805bc0d3a4149fb5194934/addons/mrp/views/product_views.xml#L164-L166

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

Forward-Port-Of: odoo/odoo#269512

## **Issue:**
When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by another salesperson.

## **Steps to reproduce:**
- Install sale_subscription_stock.
- Create a user with Sales: Own Documents Only and Inventory Administrator access rights.
- Create a sale order as another user.
- Validate the delivery with the restricted user.

## **Solution:**
During _action_done(), [This line](https://github.com/odoo/enterprise/blob/19.0/sale_subscription_stock/models/stock_picking.py#L45) is checking subscription_state. Since the user does not have read access to the sale order, reading this field raises an access error and prevents the delivery from being validated. As the method only needs to read the subscription state, access the field with sudo() to avoid the unnecessary access error while preserving the existing business logic.

Runbot Video : [Video](https://drive.google.com/file/d/1d7U2jTCxaaVk2YJcy3bi2SlYuT-yXMsu/view?usp=drive_link) 

OPW - 6295712

Forward-Port-Of: odoo/enterprise#122420

Steps to reproduce:
- Open the website configurator in Chrome.
- Choose an industry and reach the Layout step.
- Look at the theme preview cards.
=> Thin gaps can appear between adjacent sections.

Before this commit, Chrome could show 1px gaps in configurator theme
previews when the `iframe` was scaled down. This came from a known
rendering issue with fractional transforms [1].

A similar issue was already fixed for website pages built with the
Website Builder when using background shapes [2]. That fix uses JS to
adjust each `.o_we_shape` size. In the configurator, previews are static
and small, so a local CSS overlap is enough and avoids running layout
calculations for each preview `iframe`.

After this commit, configurator previews add a small overlap on sections
and shapes, so Chrome no longer exposes the background seam.

[1]: https://issues.chromium.org/issues/41137778
[2]: https://github.com/odoo/odoo/commit/f7fd40d619d8bc2b5edc09de3a71a1954b4f3b52

task-6340483

BEFORE THE FIX (only Chrome)
<img width="706" height="544" alt="image" src="https://github.com/user-attachments/assets/93c94961-8fd3-43da-bf32-3932ee98118d" />

AFTER THE FIX (only Chrome)
<img width="704" height="540" alt="image" src="https://github.com/user-attachments/assets/acfc474e-fa03-4ff5-8ab1-52070619d78f" />

#### Description of the issue this PR addresses:
- When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler` runs. Since `ev.data` still reflects the original typed `/`, the powerbox was incorrectly opening.
- Emoji shortcuts works only when it is used at the end of a text node, because the matching logic checked the whole remaining substring from the current position.
- Sometimes, pressing Backspace splits one text node into two, and then an emoji shortcut works at the end of the first text node even when the paragraph is visible as a single line.

#### Desired behavior after PR is merged:
- Check the DOM character at cursor position instead of `ev.data` to determine whether `/` is actually present before opening the powerbox.
- Emoji shortcuts now works when used with a preceding space anywhere in the paragraph.

Enterprise PR-https://github.com/odoo/enterprise/pull/118310
task-6243724

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

Forward-Port-Of: odoo/odoo#266284

Description of the issue/feature this PR addresses:

The actual XML extraction hardcoded the double-zipped case by reading only
   the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it
   was always a nested zip containing the XML.

This made it fail when:
- The XML was directly in the outer zip (single-zipped).
- The zip contained multiple files and the first nested zip didn't hold the XML.

Current behavior before PR:
After sending an Invoice to Viettel S-Invoice, the e-Invoicing platform would return a ZIP containing one XML file.
The XML File being double-unzipped, a traceback is raised.

Desired behavior after PR is merged:

The fix rewrites _recursive_zip_xml_file_data to actually be recursive. Invoices can be sent to Viettel S-Invoice without raising a traceback.

opw-[6249929](https://www.odoo.com/odoo/project.task/6249929?debug=1)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272643
Forward-Port-Of: odoo/odoo#268482

**Steps to reproduce on a new db:**
(bug also reproducable on runbot but the impact 
is less easy to compute because of influence of other
existing companies)

- create a new company as company 2 and use the existing 
default company as company 1.
- create a warehouse for both company
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).
- for both comp, in settings for inventory valuation set 
'periodic' and for periodic valuation set 'daily'

From company 1 : 
- create a storable product with standard price method and 
set a cost of 30
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 30 
  - the variation lines have a balance of 30
  - all of this is expected

From company 2 :
- change the cost of the product to 10
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 10 
  - the variation lines have a balance of 10
  - all of this is expected
 
From any company :
- navigate to 'scheduled actions' and select the action 
'Stock Account: Inventory Valuation Closing'
- click on 'Run Manually'
- navigate to 'inventory valuation'

**Current behavior:**
with company 1 selected :
  - the initial balance is now 30 
  - ending stock still 30
  - no variation lines
  - the initial balance was correctly increased by the closing entry

with company 2 selected: 
  - the initial balance is now 40
  - the ending stock is still 10
  - the variation lines credit 30 in stock valuation

In company 2 the closing entry debitted 40 in stock valuation 
instead of 10 which increased the initial balance to 40 instead of 10

If you open the journal items you'll find the closing amls have a 
balance of 40 instead of 10

**Cause of the issue:**
The _cron_post_stock_valuation() method 
calls action_close_stock_valuation() on both companies
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L143-L144

This methods calls _action_close_stock_valuation
with a context modified with only self.env.company.ids
in 'allowed_company_ids'
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L56

This is needed because inside stock_value() we use 
the total value of the product 
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L92
which will be the sum of the values of the product 
for each company inside allowed_company_id
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/product.py#L274
So in case action_close_stock_valuation() was called from 
the 'generate entry' button from the inventory valuation view
we need only the main company selected to be in the
'allowed_company_ids' so that the inventory value is computed 
based only on this company (as is the accounting value).

The problem is that this does not work when calling the 
method from _cron_post_stock_valuation because then
there is no 'allowed_company_ids' in the context (because it was
called from _process_job() with a new env).
so self.env.company will be the company of the user 
which will be company 1.
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/odoo/orm/environments.py#L243

Therefore when _action_close_stock_valuation will be 
called on company 2, in the context, allowed_company_ids 
will be company 1. Then, when computing 'products', with_company() 
will add self (company 2) to the context.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L151-L152
So stock_value will return the sum of the total_value 
of each product for company 1 and company 2 which is 40 (instead 
of 10 for just company 2)
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L242

We then create the closing accounting entry to match the 
accounting value with the stock value, which explains why 
the new initial accounting balance of company 2 is 40.

**fix:**
We set the context using self instead of self.env.companies
This makes more sense as both in the cron use case and 
the generate entry use case the stock value we want is the 
one of the company in self. 
- In cron use case, it's obvious as the method is called 
in a for loop on each company
- In the generate entry use case, self will also be the main 
company, because it's called, in actionGenerateEntry, 
on this.companyId 
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L75
which is computed based on the get_report_values
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L21
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L28-L30
Which returns the main company
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/report/stock_valuation_report.py#L29


Most importantly, this is also aligned with how the accounting 
values are computed.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L103-L105


opw-6237402

Forward-Port-Of: odoo/odoo#270127
Forward-Port-Of: odoo/odoo#266932

Steps to reproduce:
===================
1. Add several delivery addresses & billing addresses
2. Add a product to the cart and go to checkout.
3. Select a specific delivery address and a different invoice address.
4. Pay and click "Skip" immediately on that page.
5. Open the resulting sales order.

=> The delivery address is reset to the company's first delivery child
   instead of the one selected during checkout.

Root cause:
===========
`partner_shipping_id` and `partner_invoice_id` are stored computed fields
(compute + store + readonly=False) that depend on `partner_id`. Any write
that includes `partner_id`, even writing the same value, retriggers the
compute and overwrites a manually selected address with the result of
`partner_id.address_get()`.

`_get_and_cache_current_cart` resurrects the customer's draft cart when it
is no longer referenced in the session and re-runs
`_update_address(partner, ['partner_id'])` on it to refresh the
pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`,
which clears the session cart key while the order is still draft, so the
next cart access takes that abandoned-cart branch and the redundant
`partner_id` write discards the selected delivery/invoice address.
Waiting a few seconds lets the order reach the 'sale' state first, so
the draft search no longer matches and the address is kept, which is why
the issue is timing dependent.

Fix:
====
In `_update_address`, when partner_id is written, keep the delivery and
invoice addresses already set on the cart if they still belong to the new
partner's company (same `commercial_partner_id`) by writing them in the same
`write()` so the recompute does not override them. Addresses that do not
belong to the new partner are still recomputed to the partner's defaults.

opw-6267188

Forward-Port-Of: odoo/odoo#272814
Forward-Port-Of: odoo/odoo#270300

**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
    behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```

**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).

This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.

**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).

(Note: we don't want to be used as a media streaming platform)

[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe

opw-6235043

Forward-Port-Of: odoo/enterprise#119644

When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see
 
https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177

That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc.

Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name.

Steps to reproduce:
1. Enable Reserve with Google on an appointment type.
2. Book a slot from Google Maps with given name John and family name Doe.
3. Open the created booking and its contact in Odoo.

=> the contact name is the email instead of John Doe

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318)
opw-6232318

Forward-Port-Of: odoo/enterprise#120604

# Setup
Ensure you currently have no activity

# How to reproduce
- Go to any form view with a chatter (e.g. Quotation form view)
- Add 2 activities with a due date of today or before
> Notice there activity counter next to the activity clock icon in the top right should be 2
- Click on the activity clock icon in the top right
> Notifce the activity counter decreases to 1
- Mark as done both To-Do activites

# The problem
The activity counter is negative

# Cause
This issue is due to a desync between the activity counter client side and server side.
When clicking on the activity clock icon, the front-end fetches the mail store data from the
backend, which is why we see the activity counter decrease.

The server computes the activity counter the following way :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457

It searches for up to 1000 activities and group them by the record they are
associated to (e.g. a sale.order). Then, for each of these records, if atleast
one activity is late or for today, increase the counter by 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509

Essentially, server side, we get a single +1 in the activity counter by record, not by activity

On the other hand, client side, we simply add 1 in the activity counter every time a
new activity is created. If an activity is deleted, then we remove 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309

# Proposed solution
Both the client and server side logic were edited fairly recently

Server side :
https://github.com/odoo/odoo/pull/234899

Client side :
https://github.com/odoo/odoo/pull/215880

According to experts, the activity counter should count records, not activities, so we
should fix the client side but properly doing so would introduce too much complexity.
We instead simply prevent the counter from going below 0.

opw-6116821

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

Forward-Port-Of: odoo/odoo#259602

The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces `mountedAndLoaded` false and bumps `resetCount`, a dependency of that effect, so the mirror is meant to re-sync after a reset.

But `resetCount` was a plain instance field. The effect's dependency function reads it, and OWL only re-renders (hence re-runs the effect) when a value the render observed changes; a plain field is not reactive, so reading it observes nothing. Bumping it therefore never scheduled a render, and the mirror only re-ran when some other reactive write happened to schedule one. When a `reset()` lands while `mountedAndLoaded` is already false (a no-op write) with `isLoaded` true, and no such write follows, no render is scheduled: the mirror never re-runs and `mountedAndLoaded` strands at false, so the empty phantom list renders no message. This happens on an out-of-render-cycle `applyScroll` (a late `onImageLoaded` or `ResizeObserver`), and when `showLoadOlder` short-circuits on `loadOlder` false and leaves the render unsubscribed from `isLoaded`.

Move `resetCount` into `this.state`. Reading it in the effect's dependency array now subscribes the render to it (OWL subscribes the `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: `applyScroll` resets on every patch while `!isLoaded`, so an unconditional bump would spin the render loop during loading; the guard re-arms only in the case that heals.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#273651

Since [1], the `re-subscribe on reconnect` bus test has been failing intermittently. This is because that PR reduced `OUTGOING_BATCH_DELAY`, which is a good change since it speeds up the tests, but it also makes the ordering of some events non-deterministic.

In this particular case, the test expects the client to receive a `BUS:RECONNECT` event before the worker sends the `subscribe` request to the server.

However, there is no guarantee which one will be observed first by `expect.step`:
- `_sendToServer` is debounced.
- Messages sent to the client pass through several asynchronous stages, such as the message port and event dispatching.

In practice, the ordering does not matter as long as both events occur. This commit adds the `ignoreOrder` option to the `waitForSteps` call.

[1]: https://github.com/odoo/odoo/pull/272199

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

# How to reproduce
- Create a new Receipt
- Save
- Delete the new Receipt

# The issue
A traceback is shown :
`TypeError: Cannot read properties of undefined (reading 'label')`

# Cause
This is caused by the custom status bar for pickings `StockPickingLockedStatusBarField`. In its template, we replace the display of the current label : https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L20-L23 https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L4-L9

The issue is that the base implementation of the current label properly handles the case were no item is currently selected:
https://github.com/odoo/odoo/blob/7630f8fe2d5198b7a1ed538241795dc26a497fa0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L298-L300

But the picking implementation does not :
https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.js#L12-L14

And it seems that the template is quickly rendered without any selected item before deletion.

opw-6345192

Forward-Port-Of: odoo/odoo#273184
Forward-Port-Of: odoo/odoo#273030

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121809
Forward-Port-Of: odoo/enterprise#119525

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 1 x COMP (lot tracked)
- Create and confirm an MO for 1 units of FP
- Set the quantity producing on the MO to 1
> The consumed qty was updated to 1 unit
- Set a lot on the pre-production pikcing and validate
#### > The lot is not transfered to the MO which you are not able to validate since the registered component is lot less

### Cause of the issue:

The issue is caused by https://github.com/odoo/odoo/commit/3223deb871ca4cb4ac0381e4321f2dbf79a60189 as the `qty_waiting` is based on the reservation state of the move origin of the move rather than its actual demand:
https://github.com/odoo/odoo/blob/00118002bd6eab2f4c34a32e993a9219fded06ac/addons/mrp/models/mrp_production.py#L1419-L1426
In particular, since the backorder of the pre-production picking was not reserved (since nothing was available in stock), it was not taken into account as it should have been.

Issue 2:

Steps to reproduce:

- In the settings Enable Multi-Steps Routes
- Unarchive MTO
- Create 3 products: 
  - Final Product: Tracked by SN with a BOM: 1 X Super Component
  - Super Component: Tracked by SN, MTO with a BOM: 1 X Component
  - Basic Component: Put 10 units in stock
- Create and confirm an MO for 3 units of Final Product
> This should create an MO for 3 units of Super Component
- Go to the Child MO > Cogs wheel > Split in 3 MO's
- Click "Generate serial" on each Child MO and validate the first one
- On the MO for Final Product > Cogs wheel > Split in 3 MO's
- On the first MO, click "Generate Serial"
> Error: Reserving a negative quantity is not allowed.

### Cause of the issue:

The `action_generate_serial` calls in turn the `set_qty_producing`:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1601
However, since the main MO was split the Super component demand is of 1 but each child MO provide an origin quantity of 1 so that the `new_qty` will be set to a negative one here:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1418-L1426
But, since the first child MO was validated, there is already a move line associated to the Super component move and the `_set_quantity_done` will therefore try to adapt the reservation to a negative quantity which leads to the error:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/stock/models/stock_move_line.py#L469-L470

opw-6128575
opw-6317083

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

Forward-Port-Of: odoo/odoo#273168
Forward-Port-Of: odoo/odoo#271123

### Steps to reproduce:

- Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP
- Create, confirm and validate an MO for 10 unit of P using COMP's at 10$ (by setting its standard price).
- Create and confirm a Sales Order for 1 unit of P
> This generate an MO
- Validate this MO for a new serial say SN011 using a COMP at 20$.
- Validate the Delivery Order using SN011
- Create and post the customer invoice
#### > The invoice COGS uses Std Price rather than the 20$ lot's fifo value

### Cause of the issue:

The cogs value are generated based on the moves returned by the `_get_stock_moves` call of the acount.move.line:
https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/account_move_line.py#L66-L68 Currently, if an account.move.line is linked to a sale.order.line, this methods returns the entire pull of stock moves linked to the sol: https://github.com/odoo/odoo/blob/79c9e7de6764e7f8e47709b827df6eee81e72637/addons/sale_stock/models/account_move.py#L155-L156 However, these moves include both, the delivery move and the `move_finished_ids` of the MTO prodcution. This is problematic since the delivery move is considered as positive cogs qty and the MO is considered as incoming cogs qty leading to a sum of 0 cogs qty which in turns make the cogs price unit fall back to the product standard price instead of the fifo cost of the produced lot.: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/stock_move.py#L257-L271

opw-6292048


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

Forward-Port-Of: odoo/odoo#272815
Forward-Port-Of: odoo/odoo#271018