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

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

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

When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display crash and show a blank white screen, so the kitchen can no longer see any order.

Steps to reproduce:
-------------------
* Configure a PoS product with an attribute whose variant that has a custom (free text) value.
* In the PoS, add the product, select that attribute value and send the order to the preparation display.
* Back in the PoS, completely delete that order line (do not just set its quantity to 0) and send the order to the preparation display again.

> Observation:
The preparation display crashes and only a white screen is shown. The browser console reports "TypeError: Cannot read properties of undefined (reading 'id')".

Why the fix:
------------
Completely deleting the line deletes the source pos.order.line, so the preparation line that is still displayed no longer resolves its `pos_order_line_id`. While building the attributes to display, the orderline component dereferenced `.id` on that (now undefined) relation, as well as on the related custom value records, which threw and brought down the whole preparation display instead of only that line.
We now guard those relations: when the originating order line is gone, the unresolvable custom value is simply dropped and the attribute is still shown, keeping the preparation display alive.

opw-6282607

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

**Problem:**
On a planned work order, changing only the start date (e.g. in the planning gantt edit dialog) corrupts the expected duration instead of just shifting the end date. The duration drifts to a wrong value, and in some cases (e.g. dependent work orders) collapses to 0.

**Steps to reproduce:**
1. Plan a work order on a workcenter (start, end, expected duration).
2. Open it and change only the start date to a time that is not on a working-hours boundary.
3. The end date updates, but the expected duration is now wrong.

**Expected behavior:**
Changing the start date replans the work order: the duration is kept and the end date is recomputed from it. This is how 19.0 behaves and how dragging the pill in the gantt already behaves.

**Cause of the issue:**
Changing date_start triggers _onchange_date_start, which recomputes date_finished from start + duration via plan_hours. That cascades into _onchange_date_finished, which recomputes duration_expected from the dates via get_work_duration_data. Since the resource calendar refactor in 19.2, plan_hours and get_work_duration_data are no longer exact inverses around the work order's own planned slot, so the round trip drifts the duration.

**Fix:**
Only recompute the duration when the end date was edited on its own. When date_finished already matches the planned end for the current duration, it was merely derived from the start change, so the duration is kept. This keeps the duration authoritative when moving the work order while still recomputing it on a genuine end-date resize.

opw-6231569

[[REF] mail: consolidate attachment Content-Type normalization](https://github.com/odoo/odoo/pull/273097/changes/ad4e34c5c79450b1e976d9ba7047487218690585)

Two separate spots handled malformed Content-Type headers. Merge them
into one block, read the raw header once with partition(';') to have
both the type and its parameters available without re-fetching the
header for each case.

No behavior change.

[[FIX] mail: handle attachment Content-Type with no subtype](https://github.com/odoo/odoo/pull/273097/changes/7b410fbe606b7e476f0005485e42783834983b75)

Some mailers send attachments with a bare token as Content-Type instead
of a valid 'type/subtype' pair, e.g.:

    Content-Type: base64; name="foo.pdf"
    Content-Transfer-Encoding: base64

Python's email library normalises any MIME type without a '/' to
'text/plain'. get_content() then decodes the base64 payload as UTF-8
text, replacing invalid byte sequences with U+FFFD. The subsequent
encode('utf-8') bakes those replacements in, permanently corrupting
the stored file.

Per Postel's law [RFC 761], be liberal in what we accept: detect these
non-standard types via `not all(mimetype.partition('/'))` and fall back
to application/octet-stream, keeping the original parameters (filename,
charset, etc.) so the attachment is stored intact.

opw-6227526

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/6b67a45b-6e52-4e02-a827-1aca5d8417ec" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/077bc3ab-bc6e-42a1-85e6-adf778000b92" />

After the fix:
-----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/da2a43e3-01c0-44c5-b529-e73f21825150" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/b658b95f-5bc3-4b7a-9e7c-8b182cab48a0" />


opw-6131231

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

**Steps to reproduce:**
- Install the `l10n_mx_reports` module and switch to a Mexican company.
- Navigate to Accounting > Reporting > Trial Balance.
- From the dropdown menu, click `SAT (XML)`.
- Open the generated XML file and inspect the `<BCE:Ctas>` nodes.

**Observation:**
- The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni`
- However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin`

**Root Cause:**
At [1], the attributes of the `<BCE:Ctas>` node are defined in an order 
that differs from the SAT-recommended structure. While the XML remains 
valid, the generated report does not match the layout recommended by the 
Mexican government specification.

**Fix:**
This commit reorders the `<BCE:Ctas>` attributes to follow the 
SAT-recommended structure, aligning the generated XML with 
the behavior introduced at [2] for `saas-19.3`.

backport-of: https://github.com/odoo/enterprise/pull/115374

[1]:
https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20

[2]:
https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22

opw-6297711

Forward-Port-Of: odoo/enterprise#122469
Forward-Port-Of: odoo/enterprise#121440

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

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

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

The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24)
override builds link.tracker short URLs from
`website.get_current_website()` and the current company's website
domain. It was introduced by
https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a
for a multi-company backend flow (users switching companies to post
social marketing links), but it runs for every compute, including
CRON contexts with no HTTP request such as the mass-mailing queue.

Without a request, `get_current_website()` picks an arbitrary website
(the first in the database) and `self.env.company` resolves to the
user's main company, so the short URL uses that company's website
domain instead of `web.base.url`.

Fall back to `super()._compute_short_url_host()` (which uses
`web.base.url`) when no website is resolvable from the request,
session, or context. Backend flows with a real request still hit the
company-aware branch.

Steps to reproduce:
1. Install Email Marketing and Website.
2. Settings > Companies: create a second company B. Settings >
   Websites: ensure website A points to company A with domain A, and
   create website B for company B with domain B.
3. Settings > Technical > Parameters > System Parameters: set
   `web.base.url` to a third domain C, and add `web.base.url.freeze`
   = `True`.
4. On company A, Email Marketing: create a mailing with body
   `<a href="http://example.com">test</a>` and a recipient list,
   then click Send.
5. Settings > Technical > Automation > Scheduled Actions > "Mass
   Mailing: Process queue" > Run Manually.
6. Email Marketing > Configuration > Link Tracker: open the tracker
   generated for the mailing.

=> The Tracked URL uses domain A.
=> The Tracked URL uses domain C.

Ticket [link](https://www.odoo.com/odoo/project.task/6038590)
opw-6038590

Forward-Port-Of: odoo/odoo#259200

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

### Steps to reproduce:

- In the settings enable: Packages
- On the operation type `Delivery Order` set "Set Package Type"
- Create and confirm a delivery for 1 unit of a product P + reserve it
- Got to the barcode app to process the delivery
- Scan your product and click "put in pack"
#### > The put in pack wizard allowing you to set a package type on the new package does not pop up.

### Cause of the issue:

As a general rule of thumb the wizard is suppose to be displayed when the option is enabled and when a package/package type is not already provided to the call:
https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_package.py#L332-L341 https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_move_line.py#L1236-L1238 However an override was added to the barcode module so that the wizard is never displayed when the action is launched from the barcode app: https://github.com/odoo/enterprise/blob/673d449f38cd3eff27c44270c8f7edf91d0ecd02/stock_barcode/models/stock_move_line.py#L193-L196

The idea behind this override was that you could provide the package type id via scans and hence that is was not necessary. However, if you click directly on the put in pack button, the wizard still make sense and should therefore be displayed under the same conditions.

opw-6325092

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

When a customer invoice is sent to the DIAN. This call can time out
the DIAN is frequently slow or momentarily unavailable
while the DIAN has in fact already received, validated
and stored the document. The response never reaches Odoo,
the exchange is recorded as `invoice_sending_failed`, and
the accepted CUFE is never linked back to the move.

On the next attempt Odoo re-POSTs the same invoice number. The DIAN
validates only one transmission per document and rejects the second
with rule 90, "Documento procesado anteriormente" (document already
processed). The invoice is then stuck: the DIAN considers it accepted,
Odoo considers it failed, and it can never be moved forward because
every resend reproduces the same rejection.

Instead of blindly re-transmitting, we now check whether the document
already exists at the DIAN. When the move already carries a document in
`invoice_sending_failed`, `_send_to_dian()` extracts the CUFE from
the signed XML and calls the new `_get_status_by_cufe()` helper,
which queries the `GetStatus` web service for that CUFE. If the DIAN
confirmed it, the document is reconciled to `invoice_accepted`
storing the DIAN message and the confirmed CUFE 
and no second transmission is made. In every other case the helper
returns None and the existing `SendBillSync` flow proceeds unchanged.

Keying the lookup on the CUFE makes this safe against false positives.
A genuine lost acknowledgement yields the very same CUFE, so a matching
valid CUFE at the DIAN is by construction the same document and can be
accepted without any field-by-field comparison.

Description of the issue/feature this PR addresses:
Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts.

Current behavior before PR:

Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock).
Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user.
No validation is enforced, leading to potential security issues.
Desired behavior after PR is merged:

Adding a subscription for a non-existent or unavailable product raises a ValidationError.
Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first.
Backend validation prevents misuse of registered user emails and improves security.




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

Forward-Port-Of: odoo/odoo#271880

On a mo that has byproducts, if you unreserve, it will also set the quantity of byproducts to 0

Steps to reproduce:
-------------------
* Create a Products main, component and byproduct
* Create a bom for main with component as component and byproduct as byproduct
* Create and confirm a mo for main
* Set qty_producing to quantity ot produce
* click on "Unreserve" (do_unreserve)
* click on "Check availability"  (action_assign)
* Produce All
-> the byproducts will not be produced.

 Observation:
-------------
When updating the qty_producing value it will also update the quantity of the byproducts moves:
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L892-L893
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L1350
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/stock/models/stock_move.py#L2382
The quantity on the byproducts move has been updated.

When clicking on Unreserve it will call do_unreserve,
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L2297-L2298
It will filters the moves that do not need to be unreserved and select the others:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L900
and it will unlink all the sml from the moves:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L919
Which will set the quantity on the byproduct moves to 0.

When Producing all (button_mark_done) since the qty_producing has already been set, it will simply mark the byproduct move has picked.
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L1323-L1324

In our case, this means that the no byproducts will be created since, the quantity was previously set to 0

opw-6296562

The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24)
override builds link.tracker short URLs from
`website.get_current_website()` and the current company's website
domain. It was introduced by
https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a
for a multi-company backend flow (users switching companies to post
social marketing links), but it runs for every compute, including
CRON contexts with no HTTP request such as the mass-mailing queue.

Without a request, `get_current_website()` picks an arbitrary website
(the first in the database) and `self.env.company` resolves to the
user's main company, so the short URL uses that company's website
domain instead of `web.base.url`.

Fall back to `super()._compute_short_url_host()` (which uses
`web.base.url`) when no website is resolvable from the request,
session, or context. Backend flows with a real request still hit the
company-aware branch.

Steps to reproduce:
1. Install Email Marketing and Website.
2. Settings > Companies: create a second company B. Settings >
   Websites: ensure website A points to company A with domain A, and
   create website B for company B with domain B.
3. Settings > Technical > Parameters > System Parameters: set
   `web.base.url` to a third domain C, and add `web.base.url.freeze`
   = `True`.
4. On company A, Email Marketing: create a mailing with body
   `<a href="http://example.com">test</a>` and a recipient list,
   then click Send.
5. Settings > Technical > Automation > Scheduled Actions > "Mass
   Mailing: Process queue" > Run Manually.
6. Email Marketing > Configuration > Link Tracker: open the tracker
   generated for the mailing.

=> The Tracked URL uses domain A.
=> The Tracked URL uses domain C.

Ticket [link](https://www.odoo.com/odoo/project.task/6038590)
opw-6038590

Forward-Port-Of: odoo/odoo#259200

Steps to reproduce:
- Create a vendor bill, one journal item: no product, price 100, no tax -> save
- Change the account of the line to one having a default included tax
- Remove the suggested tax -> save

Issue:
The tax is back on the line, applied on top of the price (100 -> 117.36), making the included tax look like an excluded one.

Cause:
`_inverse_account_id` is the inverse of `account_id` and its onchange, and retriggers `_compute_tax_ids` on every write of `account_id`. When the user removes the tax the onchange just suggested, javascript `_getChanges` does not identify the user-deleted tax and sends back only the new account_id <-> `tax_ids` is back to its server value. So the field is not protected by `_get_protected_vals` and the compute reapplies the default taxes of the account, overriding the user.

Solution:
Split the method in two: the onchange keeps suggesting the default taxes (when the user keeps them, the client sends `tax_ids` explicitly), the real inverse only keeps the analytic part.
The create path is not impacted: `tax_ids` is precomputed from the account, so imports of new bills/entries still get the default taxes.

opw-6088331

### Steps to reproduce

- Install `sale_timesheet_enterprise`.
- Go to **Tasks → All Tasks**.
- Switch to the **Gantt** view.
- Group by **Sale Order Item** (`sale_line_id`).

### Issue

A traceback is raised when loading the Gantt view with group by `sale_line_id`:

```text
ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum'
```

### Root cause

The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`.

However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`.

Migration reference:
https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10

Issued PR: https://github.com/odoo/enterprise/pull/49685

### Fix

Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback.

### Summary

When `dev_mode` includes `reload`, `ThreadedServer`'s FSWatcher reacts to a file change by sending the process a `SIGHUP` to trigger a phoenix restart. `signal_handler` turns `SIGHUP` into `KeyboardInterrupt`, which `ThreadedServer.run()`'s wait-loop catches. The catch is too narrow — a reload `SIGHUP` can kill the process through **three** windows that all sit outside the wait-loop's `try/except`, so the exception escapes `run()`/`main()`. Under Docker's default `restart: no`, PID 1 dies and the container stays down.

### The three windows

1. **Teardown duplicate (exit 130).** One file change can emit several FS events; the FSWatcher's `if not odoo.phoenix:` dedup races across threads and fires more than one `SIGHUP`. The first begins the phoenix teardown; the second lands during `stop()` / `watcher.stop()` / `_reexec()` and `KeyboardInterrupt` escapes.
2. **Exec-gap (exit 129).** `os.execve()` resets caught signal handlers to their default disposition (`SIGHUP` terminates) but preserves `SIG_IGN`; a `SIGHUP` arriving after the exec but before the re-exec'd process re-installs its handler kills the process outright.
3. **Startup (exit 130).** In the re-exec'd process, a `SIGHUP` anywhere in the startup section that precedes the wait-loop — `start()`, `preload_registries()` **and** `cron_spawn()` — escapes `run()`.

### Reproducer (deterministic)

Boot a `ThreadedServer` (`--workers 0`) on any initialised db, then signal PID 1 a few times in quick succession:

```bash
docker exec <container> sh -c 'i=0; while [ $i -lt 8 ]; do kill -HUP 1; sleep 0.1; i=$((i+1)); done'
```

Unpatched the process exits 130 or 129. Patched it stays up after one clean phoenix reload. Verified live on 17.0 and 18.0: stock `server.py` dies; the patched `server.py` survives sustained bursts (20/20 across repeated reload cycles on each version); `SIGINT`/`SIGTERM` still exit 0.

### Fix

Minimal, in `signal_handler` + `run()` + `_reexec()`; `SIGINT`/`SIGTERM` untouched; one new instance attribute, no new module globals:

- **Teardown duplicate:** ignore a `SIGHUP` once `quit_signals_received` is set (a restart/shutdown is already pending; the re-exec reloads fresh code).
- **Startup:** a per-instance `in_preload` flag marks the entire startup section (`start()` + `preload_registries()` + `cron_spawn()`); a `SIGHUP` there sets the phoenix flag + counter and returns instead of raising, so the wait-loop exits right after startup and runs the normal restart.
- **Exec-gap:** `signal.signal(signal.SIGHUP, signal.SIG_IGN)` just before `os.execve` so a `SIGHUP` in the gap is dropped rather than terminating the process.

### Related

- #21209 (merged) — introduced the phoenix flag; did not guard these windows.
- #206898 (merged), #207930 (open) — PreforkServer reload.

### CLA

Covered by Codeforward B.V.'s corporate CLA; #269240 adds me to its contributor list (pending merge).

In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started.

Case 1:
- Have website A and website B
- Create an appointment page website A
- Log in via website B
- As public user, make an appointment in Website A
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url.
This parameter is then used as fallback when we need to retrieve the base url without an active record

Case 2:
- Have website A and website B
- Create an event and assign it to website B
- As public user, access the event and register to it
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event.
This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A)

opw-4146760
opw-4336369

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

**Steps to reproduce:**

- Create a product A, tracked by lots
- Create a kit product, include a component A
- Change the UoM to 0.5
- Go to the PoS, order this kit product
- Also order the component A, with a quantity of 2
- Pay for it, ask for an invoice
- Go to the created picking
- The Demand column is correctly computed and is 0.5
- The Quantity column is wrong and is 2

**Why the fix:**

When getting the data from https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L283 
we always get the component's line, as the move's product is the component, even if it used to be the kit product's move. This is because when exploding a kit's moves, it gets the kit's component as a product instead of keeping the kit product.

This was introducing a weird behavior because we took the quantity from the component line, and not from the kit line, meaning the kit would always have the same quantity as the component.

We now check if the move is actually a kit product's move, and if it is we adapt the qty to correct one by fetching the correct line's qty, and adapting it with the correct UoM.

Changing the line in itself would not work, as the kit itself is not tracked by lots, so we would not enter https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L284 
and the move line would not be correctly created.

opw-6153000