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

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:
===================
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

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

### 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