### [FIX] website: guard form default email in cross-company editing
Since [1], the website form uses the website's company email as the
default recipient. With cross-company editing, the editor user may not
have access to that company's email and hits an `Access Error` when
reading `res.company`.
This commit catches the error and falls back to the editor user's email.

Steps to reproduce:
- Log in as admin
- Set demo user Access Right to `Editor and Designer` for website
- Log in as demo user
- Change company to `My US company`
- Enter website builder and edit mode on `My website`
- Drop a snippet `s_website_form`
- Save
- Traceback: `Access Error`

[1]: https://github.com/odoo/odoo/commit/10eea785e631fb3398ed5df5bfbb8d2f17453551

---

### [FIX] website: ensure default email is used for every form
Following [1], `applyDefaultValues` was no longer applied to snippets
that contain an `s_website_form` without being one themselves, such as
`s_website_form_info`.
`onSnippetDropped` only matched `.closest(".s_website_form")`,
so wrapper snippets returned early and never got their default recipient
email.

Steps to reproduce:
- Drop a `s_website_form_info`
- Click on the form
- "Recipient Emails" is empty, it should contain the company email

task-6356910

[1]: https://github.com/odoo/odoo/commit/ff44e9d56fa64f02946a1432a03f19db1b17ec37

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

Problem
----------------------
When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect.

Reason
-------------------
The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation.

Solution
-------------------
The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income.

task-6237717

Forward-Port-Of: odoo/enterprise#121742
Forward-Port-Of: odoo/enterprise#120180

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

Forward-Port-Of: odoo/odoo#273097

Issue:
----------------------------------------
The overtime calculation ignores attendances overlapping midnight when creating an attendance on the day they overlap.

Steps to reproduce:
----------------------------------------
- Have the standard 8 hours per day working schedule
- Use the default overtime ruleset:
    - Quantity, per day, more than the contract
    - Have no rule on weeks
- Create an attendance of 8+ hours overlapping midnight on a day:
    - From 10pm to 10am (2h + 10h = 12h)
- Create another attendance on the day the first ended:
    - From 2pm to 6pm (4h)
- The first attendance has 2h of overtime:
    - 0h from the first worked day (from 10pm to midnight = 2 < 8)
    - 2h on the next day (10h worked from midnight to 10am)
- The second attendance have 0h of overtime even though it should be 4h
    - We only considered this attendance in the calculation, ignoring the 10h worked in the morning

Cause:
----------------------------------------
In `_update_overtime()` we create a domain to include all useful attendances in the calculation. As all rules are based on days, the domain will use the date of the attendance to get overlapping attendances. But the date of the attendance is the date of its `check_in` ([src](https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/hr_attendance/models/hr_attendance.py#L91)). So when creating the second attendance, the domain only fetches attendance with their `date` on the same date as the `check_in` of the second one. This excludes the first one even though it overlaps on the same day.

Solution:
----------------------------------------
Don't use `date` but `check_in` and `check_out` in the domain to really get all attendances overlapping a day with an updated attendance.

As this domain was used on both `hr.attendance` and `hr.attendance.overtime.line`, we adapt it so it uses the correct fields (`time_start` and `time_stop`) from the overtime lines.

opw-6253777

Forward-Port-Of: odoo/odoo#272447

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

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

Forward-Port-Of: odoo/enterprise#122308

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

Forward-Port-Of: odoo/odoo#273097

Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
   - Apply To: Category
   - Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.

Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.

Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.

This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.

Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.

opw-6346422

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

### Steps to Reproduce
1. Activate any other language (ex. FR)
2. Create a new Discount code in Discount & Loyalty
3. Change your user language preference to FR, open the newly created loyalty reward, and change the Description on Order to Test Discount for both languages
4. Navigate to the backend Product Variants menu and observe how its name did not translate in English

### Description of the issue/feature this PR addresses:
**Issue:** When you edit a translation for a loyalty.reward description in a multi-language setup, the product name (`discount_line_product_id.name`) fails to receive the complete translation in all languages. It only updates the current language.

**Solution:**
Override the 'update_field_translations' method on the loyalty.reward model. When changes are saved for the 'description' field on the discount code, intercept the payload and mirror directly at the discount product's `name` field.

### Current behavior before PR:
Updating the reward description only updates the current language and all other languages do not change.

### Desired behavior after PR is merged:
For all languages in which changes are made in a discount code's description, the discount line product name will reflect the same changes. 

opw-6314760

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

Forward-Port-Of: odoo/odoo#271680

Steps to reproduce:
-------------------
- Install `stock`
- Create a receipt for a product with `x` quantity
- Validate the receipt
- Click `Return` and create a return picking
- Validate the return picking
- Open the Moves History

Issue:
------
The stock move line generated by the return operation still displays the
original receipt reference (`WH/IN/000XX`) in the Reference column
instead of the return picking reference (`WH/OUT/000XX`).

As a result, the return move appears to belong to the original receipt
rather than being identified as a separate stock operation.

Cause:
--------
In this [commit](https://github.com/odoo-dev/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba
) `reference`  is become editable field (readonly=False)

Now `stock.move.reference` is a stored, editable computed field

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/models/stock_move.py#L182

Since `_compute_reference` derives its value from `move.picking_id.name

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/models/stock_move.py#L383

Because the field is both `store=True` and `readonly=False`, the
field-setup logic in `Field._setup_attrs_` no longer applies its usual
default of disabling `copy` for computed fields

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/odoo/orm/fields.py#L460-461

With `store=True` and `readonly=False`, this condition evaluates to
`False`, so the line is skipped and `copy` falls back to the base
`Field` default of `True`  instead of `False`.

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/odoo/orm/fields.py#L286

When the return wizard duplicates the original move with

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/wizard/stock_picking_return.py#L53

therefore copies the *old* stored `reference` value ("WH/IN/000XX") into the
`create()` vals of the new move, alongside the new `picking_id`.

`BaseModel.create()` then protects editable computed fields that
receive an explicit value in `vals` from being recomputed.

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/odoo/orm/models.py#L3996-L3999

Since `reference` is present in `vals` and `readonly=False`, it is
added to the `protected` set, so `_compute_reference` never runs for
the new move even though its `picking_id` now points to the new
return picking. The stale value from the original receipt is kept
as-is, and propagates to the move line via the related field

https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/models/stock_move_line.py#L89

Fix:
----
Set `copy=False` explicitly on `stock.move.reference`, restoring the
behaviour it had before `readonly=False` was added (when `readonly`
defaulted to True, `copy` was already False automatically). This
keeps the field editable in the UI while preventing the stale value
from being carried over on `copy()`, so it is correctly recomputed
from the new move's own `picking_id`.

---

opw-6293019

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

### Issue:
In 19.0, the values of lines 415 and 420 in the Swiss tax report are negative, causing line 479 to add them instead of subtracting

Line 479 formula:
`tax_ch_400 + tax_ch_405 + tax_ch_410 - tax_ch_415 - tax_ch_420`
For the subtraction to be correct, 415 and 420 must be positive

### Cause:
In 18.0, each tax grid had two variants (`+415`/`-415`) allowing the user to control the sign manually
The double negative (`-*-`) incidentally produced positive values in the report

In 19.0, the unified tax grid merges them into a single tax grid (`415`) with automatic sign handling
415 and 420 are correction lines that must appear positive in the report so that 479 subtracts them correctly
The formulas were not updated to reflect this change

### Steps to reproduce:
- Install `l10n_ch_reports` and `accountant`
- Switch to `CH Company`
- Create and confirm a Bill (Amount: 100, Tax: 8.1%)
- Create and post a Journal Entry:
  - Account: 1170 Input Tax (VAT), Credit: 2, Tax Grids: 415 and 420
  - Account: 1021 Bank, Debit: 2
- Open the Tax Report for this month
 
Before the fix, lines 415 and 420 are negative and line 479 adds them instead of subtracting

opw-6311126

Forward-Port-Of: odoo/odoo#272385

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

Forward-Port-Of: odoo/enterprise#121114

### Issue:
When creating a website through the configurator and selecting the
website type 'an eCommerce', the shop feature is not preselected as
expected.

### Steps to reproduce:
- Ensure that the eCommerce module is not installed.
- Navigate to Website > Configuration > Settings.
- Click on the "New Website" button to create a new website.
- Select the "eCommerce" option as the website type and proceed to the
  next step.
- On the "Add Pages and Features" screen, observe that the "Shop" option
  is not selected by default.

### Reason:
0cb45457 renamed the website type from `online_store` to `eCommerce`,
but the related feature was not updated and still references the old
name. As a result, the preselection is not triggered.

### Fix:
Restore the eCommerce website type's internal name to `online_store` in
the configurator. This matches the value already stored in the database
for existing installations, allowing the shop feature preselection to
work for existing users as well, without requiring a data update.

task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263)

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

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

### Commit 1:

[FIX] website: prevent CSRF error by blocking duplicate form submission

Before this commit: Clicking the logout button from the website
preview triggered two simultaneous logout requests:

1. The browser performed the default form submission with a valid
   `csrf_token`, destroying the session afterward.
2. During the same click event, `setupClickListener()` intercepted
   the click using `closest('[action]')`, found the parent
   `/web/session/logout` form, and triggered a second POST request
   using `odoo.csrf_token`.

Since the session was already destroyed by the first request, the
second request resulted in a "CSRF validation failed" error.

This commit prevents the default form submission before triggering
the manual POST request, ensuring that only one request is sent.

Runbot-940403

--------------------------------------------------------------------------------------------------------------------------------

### Commit 2:

[FIX] website: enable free sign up setting in test_auth_forms_warning

Steps to reproduce:
1. Install any website related module (e.g. `website`, `website_event`).
2. Keep the default configuration and do not manually enable
   'Free sign up' in Settings.
3. Run `test_auth_forms_warning`.

Before this commit: The test did not programmatically enable the
'Free sign up' setting. As a result, it failed unless a developer
manually navigated to the setting and enabled it beforehand.

After this commit: This commit explicitly enables the "Free sign up"
configuration during test execution, allowing public access to the
`/web/signup` page and ensuring the test passes without any manual
setup.

runbot-940394

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

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

Forward-Port-Of: odoo/odoo#269247

Steps to reproduce
---
1. Install a carrier that requires a positive package shipping weight (e.g. UPS) and enable Packages.
2. From the Barcode app, process a delivery and Put in Pack the products.
3. Validate the transfer.

Issue
---
Validation is refused because the package has no positive shipping weight, even though its computed weight is correct.

The package shipping weight is only set in `_post_put_in_pack_hook` from `context['weight']`, which is filled exclusively by the put in pack wizard. Flows that bypass the wizard, like the Barcode app, never provide that key, so the stored `shipping_weight` stays 0 while carriers reading it directly reject the delivery. The Barcode app suppresses the wizard through the `barcode_view` context, so its put in pack goes straight to the hook without any weight.

https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/stock_barcode/models/stock_move_line.py#L193-L196

This handling was centralized in this hook by 9a2ff6f4033e, so every wizard-bypassed pack leaves the field empty. Defaulting it to the package computed weight via `_get_weight` when the context did not provide one makes the stored value correct for any carrier, independently of the flow that created the package.

https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/stock_delivery/models/stock_move.py#L111-L115

opw-6297689

Forward-Port-Of: odoo/odoo#272510

Steps to reproduce
1. Create two customer invoices that share the same VAT tax, with a payment term granting an early payment discount.
2. Create one bank statement line whose amount equals the sum of both invoices' discounted totals.
3. From the bank reconciliation widget, select both invoices and validate in a single batch reconciliation.
4. Open Accounting > Reporting > Tax Return, switch the variant to "Group by: Account > Tax".

Issue
The cash-discount expense row shows a Net base column equal to twice the real
discount base. The Tax column is correct.

The bank-statement reconciliation paths (set_line_bank_statement_line,
set_batch_payment_bank_statement_line, _reconcile_payments) loop over each
invoice and call _apply_early_payment_discount one invoice at a time. Each
call writes one discount base line and one discount tax line on the resulting
bank entry, so when two invoices share the same tax the bank entry ends up
with two pairs carrying the same (account, partner, currency,
tax_repartition_line_id, tax_ids).

The SQL that feeds the tax report at
https://github.com/odoo/odoo/blob/d7d0efd39a65bfb6fee307b661cd2523a6b8231d/addons/account/models/account_move_line_tax_details.py#L100
matches every base line of a tax with every tax line of that tax inside the
same move. With two pairs sharing one tax that turns two rows into four, and
SUM(base_amount) doubles. The Tax column does not double because the same SQL
redistributes each tax line's recorded amount across its matched rows so the
totals still add back to the original tax.

The payment register flow does not have this problem because it calls
_get_invoice_counterpart_amls_for_early_payment_discount once with every
invoice, and that helper already collapses duplicates with the merge key at
https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/account/models/account_move.py#L5082-L5093

opw-6199906

Forward-Port-Of: odoo/enterprise#117743

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

Forward-Port-Of: odoo/enterprise#116022

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

Forward-Port-Of: odoo/enterprise#121114

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

[*]=website

1. Sync background shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    3. Drop any snippet.
    4. Add a background shape.
    5. Set the background shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
  
    Issue:
    The background shape color is not updated when the theme color changes.
    
    Reason:
    The background shape color is embedded in the URL of the "**background-image**" style attribute. When the theme color value changes, this URL is not updated. Additionally, the URL uses color variables rather than resolved hexadecimal color values as parameters. As a result, even when an updation occurs, the URL itself remains unchanged, preventing the background shape color from being updated.
    
2. Sync image shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    2. Drop any snippet.
    4. Click on the image and add a shape.
    5. Set the image shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
    
    Issue:
    The image shape color is not updated when the theme color changes.
    
    Reason:
    When the theme color value changes, the SVGs are not re-fetched. Additionally, the image "**shapeColors**" dataset stores the hexadecimal value of the theme color instead of the corresponding CSS variable. As a result, there is no way to determine which theme color was selected (for example, whether `o-color-1` or `o-color-2`), since only the hex value is available.


task-5438314

Forward-Port-Of: odoo/odoo#272191
Forward-Port-Of: odoo/odoo#241968

Before:
- Documents flow: after signing, the signed copy was placed in the Sign folder instead of the same folder as the original document.
- HR flow: after signing a sign.request linked to an HR record (e.g. hr.employee, hr.version), the signed document appeared twice, once in the Employee/Payroll folder and again in the Sign folder.
- [_sign()](https://github.com/odoo/enterprise/blob/19.0/sign/models/sign_request.py#L505) attaches a copy of the signed document to the linked record, but the missing `no_document=True` was mistakenly creating an extra document
- Import from Documents flow: after signing via "Import from Documents" in the Sign app, the signed copy was placed in the original document folder instead of the Sign folder.

After:
- Documents flow: the signed document is now placed in the same folder as the original document.
- HR flow: the signed document is created only once, in the Employee/Payroll folder. No copy is made in the Sign folder.
- No extra documents are created in the background when a sign request linked to a record is completed.
- Import from Documents flow: the signed document is now placed in the Sign folder.

Impact:
- Signed documents from the Documents app stay in the same folder.
- Signed HR contracts appear only in the Employee/Payroll folder.
- No duplicate documents are created on completion.

Task: 6176315

[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config

Bug reproduction:
    1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour
    2 - When only single app is installed without installing l10n_be_hr_contract_salary, the tour test fails

Bug cause:
    1 - When the employee's company's country is belgium we were showing NISS instead of identification number.
    2 - But NISS field is appended in l10n_be_hr_contract_salary and if you do not install, there is no identification number and NISS.
    3 - That's why the test fails (it looks for identification number or NISS but none of them is there)

Bug solution:
    1 - I moved the code of hiding identification number or hiding NISS to the l10n_be_hr_contract_salary. So, when only hr_contract_salary is installed, identification number field won't get hided.

task - 6333129

runbot error link: https://runbot.odoo.com/odoo/error/941044

Forward-Port-Of: odoo/enterprise#121800

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

Forward-Port-Of: odoo/enterprise#120379

Problem
----------------------
When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect.

Reason
-------------------
The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation.

Solution
-------------------
The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income.

task-6237717

Forward-Port-Of: odoo/enterprise#120180

Replaced 4 `useLayoutEffect` calls with `onMounted` (3 cases) and `useEffect` (1 case) because `useLayoutEffect` is deprecated in OWL3.

3 of the 4 effects run once at mount with an empty dependency array, making `onMounted` the natural fit. The remaining effect tracked `this.state.documentsWithUnsignedItems` and `this.state.openedDocumentIndex` — the state is a reactive proxy mutated via Set in-place, which would break with signals. `useEffect` auto-tracks reactive reads and preserves the exact same reactive behaviour.

Note: `usePublicRefuseButton` was refactored to accept a `component` parameter instead of calling `useComponent()`, which only exists in the OWL2 compat layer `@web/owl2/utils` and is not available in OWL3.

The useLayoutEffect refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- `@sign/document_backend/simple rendering`: getDataFromHTML step not received
- `@sign/signable_sign_request/simple rendering`: getDataFromHTML step not received
- `TestPortalSignFlow.test_portal_sign_document`: .o_sign_sign_item_navigator not found
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596833/build/114857629

### Issue:
On Chilean export invoices, the customs information table may display data in the wrong columns

When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left

This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document

### Cause:
`l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields
`t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment

Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set

### Steps to reproduce:
- Install `l10n_cl_edi_exports` and switch to CL Company
- Create an Invoice (any customer, any line)
- In the gear menu, select Print > Invoice PDF copy (Chile)

Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set

opw-6304670

# Description of the issue/feature this PR addresses

When updating mail notifications during `mail.mail._send()`,

a `SerializationFailure` raised while flushing the notification recordset leaves the current transaction in an aborted state.

As `_send()` continues handling the exception, accessing fields:
 - https://github.com/odoo/odoo/blob/127f1316540ec6cc6880ea3515e6923ba3903bc7/addons/mail/models/mail_mail.py#L816

So, any subsequent SQL query fails with

`InFailedSqlTransaction`, masking the original concurrency error. Wrap the notification flush in a savepoint so that PostgreSQL rollbacks only the failed flush, keeping the cursor usable while preserving the original `SerializationFailure`.

A regression test is added to simulate a concurrency failure during

`flush_recordset()` and verify that the cursor is no longer left dirty

The logger for the unittest without the fix is the following:

```log
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/mail/models/mail_mail.py", line 719, in _send
    notifs.flush_recordset(['notification_status', 'failure_type', 'failure_reason'])
  File "<string>", line 3, in flush_recordset
  File "unittest/mock.py", line 1139, in __call__
    return self._mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1143, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1204, in _execute_mock_call
    result = effect(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 93, in mocked_mail_notification_flush_recordset
    return original_flush_recordset(self, *vals, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 6788, in flush_recordset
    self._flush(fnames)
  File "odoo/odoo/models.py", line 6852, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "odoo/odoo/models.py", line 4938, in _write_multi
    self.env.execute_query(SQL(
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 107, in test_mail_send_dirty_cursor
    mails.send()
  File "odoo/addons/mail/models/mail_mail.py", line 652, in send
    self.browse(batch_ids)._send(
  File "odoo/addons/mail/models/mail_mail.py", line 818, in _send
    mail.id, mail.message_id)
             ^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1309, in __get__
    self.compute_value(recs)
  File "odoo/odoo/fields.py", line 1491, in compute_value
    records._compute_field_value(self)
  File "odoo/odoo/models.py", line 5302, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/odoo/fields.py", line 113, in determine
    return needle(records, *args)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 710, in _compute_related
    record[self.name] = self._process_related(value[self.related_field.name], record.env)
                                              ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 7083, in __getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1272, in __get__
    recs._fetch_field(self)
  File "odoo/odoo/models.py", line 4120, in _fetch_field
    self.fetch(fnames)
  File "odoo/addons/mail/models/mail_message.py", line 756, in fetch
    return super().fetch(field_names)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4158, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4245, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block
```

Real error in production:

```log
2023-04-15 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_notification" SET "failure_reason" = "__tmp"."failure_reason"::text, "failure_type" = "__tmp"."failure_type"::VARCHAR, "notification_status" = "__tmp"."notification_status"::VARCHAR FROM (VALUES (4426629, 'Error without exception. Probably due to concurrent access update of notification records. Please see with an administrator.', 'unknown', 'exception')) AS "__tmp"("id", "failure_reason", "failure_type", "notification_status") WHERE "mail_notification"."id" = "__tmp"."id" ERROR: could not serialize access due to concurrent update
```

```log
2023-04-14 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_mail" SET "failure_reason"='Error without exception. Probably due do sending an email without computed recipients.',"headers"='{''X-SMTPAPI'': ''{"ip_pool": "Transactional"}'', ''X-Odoo-Objects'': ''sale.order-1436960''}',"state"='exception',"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (2548540)
ERROR: current transaction is aborted, commands ignored until end of transaction block
```

Commit related:
 - Flushing
   - https://github.com/odoo/odoo/commit/6cf8db906f595a0e579f9b0fd93e789c54c17fd4
 - Using fields after psycopg errors:
   - https://github.com/odoo/odoo/commit/6fa292cec861da0ccfd3afe443062080171d2fc4
   

Enterprise https://github.com/odoo/enterprise/pull/122393

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

Steps to reproduce:
----------------------
1. Install `mrp`, create two warehouses A and B.
2. Create a storable product with Track Inventory True.
3. Create a Manufacturing Order for 10 qty with(Miscellaneous tab):
   - Components location = Warehouse A (raw materials)
   - Finished product Location = Warehouse B
4. Confirm the MO.
5. Open the Forecast report for the product.

Issue:
-------
- Warehouse B forecast shows the MO under the replenishment detail
  lines (correctly, via `location_dest_id`) but the header displays
  "0 Incoming", "0 Outgoing", "0 Forecasted".
- Warehouse A forecast incorrectly shows "10 Incoming" in the header,
  even though no finished product is going there.

Cause:
-------
- When we create MO for finished Product move is created
if there no `location_final_id` then it set mo.warehouse_id.lot_stock_id` 
as the `location_final_id`.

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/stock_move.py#L466-L467

which is introduce in this [commit](https://github.com/odoo-dev/odoo/commit/95ce0ed97a160e3465c313ed6b9bef938d61586b)

- The problem is that `mo.warehouse_id` is a related field computed from
`mo.location_src_id.warehouse_id`

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/mrp_production.py#L110

- this warehouse that supplies the **raw materials** (Warehouse A). 
When the user sets `location_dest_id`
to Warehouse B's stock, `mo.warehouse_id` is still Warehouse A, so
`location_final_id` is stamped with Warehouse A's stock location.

- `product.incoming_qty` (used by the forecast header) evaluates non-done
moves using `location_final_id` first (if set), falling back to
`location_dest_id` only when `location_final_id` is False:

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/models/product.py#L331-L335

- Because `location_final_id` is set (to WH-A) and non-False, the
second clause (which would pick up `location_dest_id` = WH-B) is never
evaluated. The result: the move is counted as incoming in Warehouse A
and ignored in Warehouse B.

- The forecast detail *lines* use only `location_dest_id` to classify
moves, so they correctly show the MO as incoming for Warehouse B —
producing the inconsistency the user observes.

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/report/stock_forecasted.py#L42-L46

Fix:
----
- Replace `mo.warehouse_id.lot_stock_id.id` with `mo.location_dest_id.id`:

- `location_final_id` is meant to track where the product ultimately
ends up when the immediate destination is intermediate. The correct
"final" location for a finished-product move is exactly what the user
chose as `location_dest_id` on the MO — not the stock location of the
warehouse that happens to supply the raw materials.

- For the standard single-warehouse case, `mo.location_dest_id` equals
`mo.warehouse_id.lot_stock_id`, so the behaviour is unchanged. For
cross-warehouse MOs (destination = WH-B), `location_final_id` is now
stamped with WH-B's stock, making `product.incoming_qty` and the
forecast header consistent with the detail lines.

----

opw-6294479