Since https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac, in certain cases, customers sending large batches of emails to an accounting email alias would report a small number of emails being bounced (ca. 5%).

Context:

1. While processing an email (after matching mail.alias, with the thread going through `message_process`), if an error is uncaught and raised, the mailgate generates a bounce email, as we presume that the email could not be processed correctly.
2. When sending an email with an attachment to an accounting journal alias, depending on the DB configuration, IAP calls for automatic OCR are triggered asynchronously. These calls trigger callbacks from the IAP server, which might hit the DB in parallel while another thread is processing another email. Given their nature, they trigger updates on the relevant account.move, thus triggering downstream computes in the model.
3. When processing an attachment, the account module triggers `_extend_with_attachments`, which tries decoding the attachment in a rollback context (see:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/account/models/account_document_import_mixin.py#L343-L344). If a SerializationError happens during that process (concurrent update), it will NOT use the retry mechanism of the ORM because the error is caught in the `except Exception` block. Instead, it will try to post a message to the record to inform the user that the attachment could not be processed.
4. The commit mentioned above changes the way `_update_sequence_made_gap` works. One side effect seems to be that every time `made_sequence_gap` is re-assigned (even if the value does not change per se), the ORM tries to update the `write_date` on the flagged invoice that generated a sequence gap.

Bug:
Given the above context, emails might bounce unnecessarily for a valid email alias and a valid email with an attachment if:

1. The journal is not using a slash-based sequence pattern (e.g., using "1234" for the naming instead of "INV/2026/1234"). In that case, `sequence_prefix` == "".
2. The first invoice does not start at "1".
3. When sending a burst of simultaneous emails in a multi-worker setup, each thread will trigger `message_process` and downstream accounting computes while processing the invoice. It will also trigger IAP calls and callbacks asynchronously when automatic digitization is activated.
4. Each draft invoice that is created is named "/", meaning `sequence_prefix` == "", which in turn re-triggers the checks in `_update_sequence_made_gap`.
5. This increases the chances dramatically of a serialization error while all the parallel processes indirectly trigger an update on the `made_sequence_gap` field of invoice "1234".
6. Most of the time, the serialization error is not triggered in the thread processing the email, which correctly retries it. But in the few unlucky cases where it is raised in the thread processing the email, it will be triggered in the transaction rollback in `_extend_with_attachments`. While handling the exception, it triggers a second error because it tries to post a message to the record that was just rolled back: -> `ERROR: current transaction is aborted, commands ignored until end of transaction block` is raised in the thread running `message_process`, which in turn triggers a bounce email.

Example logs (simplified):

```
2026-06-12 14:12:15 [Worker-Thread-101] INFO mail_thread: Routing email (1)
2026-06-12 14:12:15 [Worker-Thread-102] INFO mail_thread: Routing email (2)

2026-06-12 14:12:16 [Worker-Thread-101] INFO iap_tools: dispatching /parse
2026-06-12 14:12:16 [Worker-Thread-102] INFO iap_tools: dispatching /parse

2026-06-12 14:12:18 [Worker-Thread-101] INFO iap_tools: Webhook received,
triggering /get_result
2026-06-12 14:12:18 [Worker-Thread-102] INFO iap_tools: Webhook received,
triggering /get_result

2026-06-12 14:12:19 [Worker-Thread-101] INFO odoo.sql_db:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
-> STATUS: OK (Acquired Row Lock)

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
ERROR: could not serialize access due to concurrent update
psycopg2.errors.SerializationFailure: could not serialize access

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
SELECT "mail_message"."id" FROM "mail_message" WHERE ...
ERROR: current transaction is aborted, commands ignored until end of
transaction block
psycopg2.errors.InFailedSqlTransaction: transaction is aborted

2026-06-12 14:12:19 [Worker-Thread-102] INFO "POST /saas_worker/smtp" 200
-> triggers Bounce email

```

Proposed Fix:
A) We update the conditions in `check_around` to ignore draft invoices when they are the "previous" entity being checked. Only posted invoices should be considered when doing the gap checks.
B) We add some guard clauses to prevent unnecessary writes to invoices that created sequence gaps. Instead of assigning values directly, we store the result of the check and only assign `made_sequence_gap` explicitly if the value is different from the currently stored value. This prevents unnecessary writes to the record if the value did not change.

Note:
- We chose this approach instead of touching `_extend_with_attachments` and the rollback context directly. Mostly to prevent any unforseen side-effects, given that this methods are used in accounting for all attachments. But it might be worth analysing if those methods might be improved to handle scenarios as described above in multi-worker setups + email handling.
- fixing the rollbackable context might tricky because the serialization error happens at the first `cr.commit()` inside the context manager
- raising explicitly with `except psycopg2.extensions.TransactionRollbackError:` in `_extend_with_attachments`
retries the whole request to the `message_process`, which might not be a good idea

OPW-6272396


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

Forward-Port-Of: odoo/odoo#270251

Steps to reproduce
------------------
1. Open a PoS session, e.g. at 1h45
2. Wait a bit and make an order, e.g. at 1h55
3. Keep the session open and go to PoS > Reporting > Sale Details.
4. Select a starting date before the ordre and after the session open, e.g. at 1h50
5. Generate the report.

The header shows the starting date of the session, i.e. at 1h45, instead of that of the selected date, i.e. 1h50

Why it's happening
------------------
Commit 5003774bf2a7 changed the way the report decides if the data comes from a single session: now if all the orders in the user selected start and end date belong to one particular session, the start and end date on the report are overriden to be those of that particular session, ignoring the user selected ranges.

The fix
-------
Only overwrite the start and end dates when `session_ids` was passed (i.e. the report is about a specific session).

When called via date range + `config_ids` (from the backend wizard like in our reproduction steps), keep the user-selected range.

opw-6185106

Forward-Port-Of: odoo/odoo#270310
Forward-Port-Of: odoo/odoo#267200

This is because webclient knows the current value (c), but not the new
available choices, still with the previous one (a, b).

Actually this works correctly if the field is created within a model
class.

```py
if model_cls._setup_done__ and field._base_fields__:
    # the field has been created by model_classes._setup() as
    # Field(_base_fields__=...); restore it to force its setup
    name = field.name
    base_fields = field._base_fields__

    field.__dict__.clear()
    field.__init__(_base_fields__=base_fields)
    field._toplevel = True
    field.__set_name__(model_cls, name)
    field._setup_done = False

    models_field_depends_done.discard(model_cls)
```

It does not works with studio because there are no parent class
(`_base_fields__`), so the if is not reached.

A solution would be to check if the field is a manually created related
and mark the whole model for setup unlike when `_base_fields__` is
present where we only setup this specific field.

opw-6293768

Forward-Port-Of: odoo/odoo#270349

Currently, an error occurs when opening the gantt view of work orders.

**Steps to Reproduce:**
 - Install `mrp_workorder` with demo data.
 - Go to `Settings` > `Technical` > `Resource` > `Resources`.
 - Open the `Assembly 1` resource and remove its `working time`.
 - Go to `Manufacturing` > `Operations` > `Work Orders`.
 - Switch to the `Gantt view`.

`KeyError: 22`

when the user opens the Gantt view, the system checks the unavailability of work centers and employees 
based on their resource calendars. While computing unavailable intervals for resources [1], resources 
without a calendar are flexible resources. If no leave interval exists within the specified start and end 
range that matches the domain, the resource is not included in the result [2]. when updating the 
unavailable intervals dictionary [3], the resource is missing. As a result, when it later tries to access 
the unavailable intervals for that resource, it raises an error [4].

This commit prevents the error by safely handling resources that are not present in the unavailable 
intervals dictionary by using an empty list instead.

[1]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L186

[2]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_calendar.py#L532-L536

[3]:https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L187

[4] https://github.com/odoo/enterprise/blob/47f2e9e88fa0bbb8852fe7734c6bece4dca8b9d0/mrp_workorder/models/mrp_workorder.py#L692-L694

sentry-7525704808

Forward-Port-Of: odoo/enterprise#119385

### What & why

`odoo db load` always calls `restore_db(..., copy=True)`, which forces the
generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is
the right default when *duplicating* a database, but it breaks the intended
behaviour when *moving* a database between servers: Enterprise subscription codes
are registered against the database UUID, so regenerating it deregisters the
moved database.

The web database manager already lets the user choose between copying and moving
(the `copy` flag of the `/web/database/restore` route), but the CLI exposed no
equivalent and forced a copy unconditionally. The CLI is the better tool for
server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits
and can run unattended or interactively.

### Steps to reproduce the current limitation

1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID)
2. On server B: `odoo db load mydb mydb.zip`
3. `database.uuid` has changed → the subscription is deregistered

### Fix

Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`,
keeping the original UUID. The default remains `copy=True`, so existing behaviour
is unchanged.

```sh
odoo db load mydb mydb.zip          # unchanged: restore as a copy (new UUID)
odoo db load --move mydb mydb.zip   # new: restore as a move (keep the UUID)
```

### Backport request

This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well.
Those are precisely the versions that ship the `odoo db` CLI subcommand, so the
fix is applicable to all of them — which is why the backport range is 16.0 → 19.0
and stops at 16.0.

Forward-Port-Of: odoo/odoo#268700
Forward-Port-Of: odoo/odoo#268501

Since https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac, in certain cases, customers sending large batches of emails to an accounting email alias would report a small number of emails being bounced (ca. 5%).

Context:

1. While processing an email (after matching mail.alias, with the thread going through `message_process`), if an error is uncaught and raised, the mailgate generates a bounce email, as we presume that the email could not be processed correctly.
2. When sending an email with an attachment to an accounting journal alias, depending on the DB configuration, IAP calls for automatic OCR are triggered asynchronously. These calls trigger callbacks from the IAP server, which might hit the DB in parallel while another thread is processing another email. Given their nature, they trigger updates on the relevant account.move, thus triggering downstream computes in the model.
3. When processing an attachment, the account module triggers `_extend_with_attachments`, which tries decoding the attachment in a rollback context (see:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/account/models/account_document_import_mixin.py#L343-L344). If a SerializationError happens during that process (concurrent update), it will NOT use the retry mechanism of the ORM because the error is caught in the `except Exception` block. Instead, it will try to post a message to the record to inform the user that the attachment could not be processed.
4. The commit mentioned above changes the way `_update_sequence_made_gap` works. One side effect seems to be that every time `made_sequence_gap` is re-assigned (even if the value does not change per se), the ORM tries to update the `write_date` on the flagged invoice that generated a sequence gap.

Bug:
Given the above context, emails might bounce unnecessarily for a valid email alias and a valid email with an attachment if:

1. The journal is not using a slash-based sequence pattern (e.g., using "1234" for the naming instead of "INV/2026/1234"). In that case, `sequence_prefix` == "".
2. The first invoice does not start at "1".
3. When sending a burst of simultaneous emails in a multi-worker setup, each thread will trigger `message_process` and downstream accounting computes while processing the invoice. It will also trigger IAP calls and callbacks asynchronously when automatic digitization is activated.
4. Each draft invoice that is created is named "/", meaning `sequence_prefix` == "", which in turn re-triggers the checks in `_update_sequence_made_gap`.
5. This increases the chances dramatically of a serialization error while all the parallel processes indirectly trigger an update on the `made_sequence_gap` field of invoice "1234".
6. Most of the time, the serialization error is not triggered in the thread processing the email, which correctly retries it. But in the few unlucky cases where it is raised in the thread processing the email, it will be triggered in the transaction rollback in `_extend_with_attachments`. While handling the exception, it triggers a second error because it tries to post a message to the record that was just rolled back: -> `ERROR: current transaction is aborted, commands ignored until end of transaction block` is raised in the thread running `message_process`, which in turn triggers a bounce email.

Example logs (simplified):

```
2026-06-12 14:12:15 [Worker-Thread-101] INFO mail_thread: Routing email (1)
2026-06-12 14:12:15 [Worker-Thread-102] INFO mail_thread: Routing email (2)

2026-06-12 14:12:16 [Worker-Thread-101] INFO iap_tools: dispatching /parse
2026-06-12 14:12:16 [Worker-Thread-102] INFO iap_tools: dispatching /parse

2026-06-12 14:12:18 [Worker-Thread-101] INFO iap_tools: Webhook received,
triggering /get_result
2026-06-12 14:12:18 [Worker-Thread-102] INFO iap_tools: Webhook received,
triggering /get_result

2026-06-12 14:12:19 [Worker-Thread-101] INFO odoo.sql_db:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
-> STATUS: OK (Acquired Row Lock)

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
ERROR: could not serialize access due to concurrent update
psycopg2.errors.SerializationFailure: could not serialize access

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
SELECT "mail_message"."id" FROM "mail_message" WHERE ...
ERROR: current transaction is aborted, commands ignored until end of
transaction block
psycopg2.errors.InFailedSqlTransaction: transaction is aborted

2026-06-12 14:12:19 [Worker-Thread-102] INFO "POST /saas_worker/smtp" 200
-> triggers Bounce email

```

Proposed Fix:
A) We update the conditions in `check_around` to ignore draft invoices when they are the "previous" entity being checked. Only posted invoices should be considered when doing the gap checks.
B) We add some guard clauses to prevent unnecessary writes to invoices that created sequence gaps. Instead of assigning values directly, we store the result of the check and only assign `made_sequence_gap` explicitly if the value is different from the currently stored value. This prevents unnecessary writes to the record if the value did not change.

Note:
- We chose this approach instead of touching `_extend_with_attachments` and the rollback context directly. Mostly to prevent any unforseen side-effects, given that this methods are used in accounting for all attachments. But it might be worth analysing if those methods might be improved to handle scenarios as described above in multi-worker setups + email handling.
- fixing the rollbackable context might tricky because the serialization error happens at the first `cr.commit()` inside the context manager
- raising explicitly with `except psycopg2.extensions.TransactionRollbackError:` in `_extend_with_attachments`
retries the whole request to the `message_process`, which might not be a good idea

OPW-6272396


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

Forward-Port-Of: odoo/odoo#270251

**Problem:**
When an attendance has overtimes across multiple days, those overtimes can
overlap when calculating their intervals.

There will always be rounding errors since only the durations are saved to 3
decimals, but this is normally fine since the durations are accumulated when
calculating the next interval.

However, on a day boundary in the employee timezone, the end of the interval is
forced to the end of day, which incidentally removes the rounding error. This
causes the overlap when calculating the next interval since its start will be
based on the rounded duration, not the actual end of day.

**Steps to Reproduce:**
- Configure an overtime rule where >8 hours is considered overtime, and a
second rule applies to non-working days
- Set Overtime Rule on employee "Anita Oliver"
- Set employee work entry source to "Attendances"
- Create an attendance that exceeds 8 hours in a day and crosses into a
non-working day and creates enough of a rounding error (see unit test)

-> Traceback error:
`ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)`

**Solution:**
Add an additional check to ensure the overtime cannot start on the previous
day.

opw-6067969

Forward-Port-Of: odoo/enterprise#118825
Forward-Port-Of: odoo/enterprise#118570

**Description of the issue/feature this PR addresses:**

When generating a SEPA QR code for a vendor bill payment, the embedded 
amount could occasionally contain excess decimal places instead of 
respecting the currency's expected precision.

This occurs because the `amount` variable in `_get_qr_vals` was being 
converted directly using `str(amount)`. Due to Python's floating-point 
arithmetic, the float value in memory can contain decimal drift.
Directly casting it to a string exposes this drift in the payload.

This commit resolves the issue by replacing `str(amount)` with 
`float_repr(amount, currency.decimal_places)`. This safely bypasses 
the float representation issue, ensuring the string strictly respects 
the currency's configured decimal precision before being injected 
into the QR code.

opw-5504258

**Steps to reproduce:**

- Select company “My Belgian Company”
- Create a 23% purchase tax
- Create vendor bill
   - Select Vendor “BE Company CoA”
   - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73
   - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show

**Current behavior before PR:**

- When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift.

**Desired behavior after PR is merged:**

- The SEPA QR code is generated with the correct number of decimal places.

Forward-Port-Of: odoo/odoo#267293

### 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:
  - 2 x COMP (lot tracked)
- Put a lot for 6 units in of COMP in stock
- Create and confirm an MO for 5 units of FP
- Set the quantity producing on the MO to 1, requiring 2 of the 6 available units of COMP
- Validate the MO and create a backorder for the remaining quantity.
#### > The consumed qty on the main MO is of 0 units rather than 2.

### Cause of the issue:

Since the component is tracked, and since the pbm move was backordered, the move quantity will not be automatically set when setting the `qty_producing`:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1405-L1411 And in particular, the move is not picked as it would if the product was untracked or if the pbm move was not backordered:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1421-L1427 And, since the move will not be picked at any other point in this flow, the move will be unreserved during the `button_mark_done`: https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L2216 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1895-L1896 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1901

opw-6128575

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

Forward-Port-Of: odoo/odoo#269235

## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#120756
Forward-Port-Of: odoo/enterprise#116430

Steps to reproduce
------------------
1. Open a PoS session, e.g. at 1h45
2. Wait a bit and make an order, e.g. at 1h55
3. Keep the session open and go to PoS > Reporting > Sale Details.
4. Select a starting date before the ordre and after the session open, e.g. at 1h50
5. Generate the report.

The header shows the starting date of the session, i.e. at 1h45, instead of that of the selected date, i.e. 1h50

Why it's happening
------------------
Commit 5003774bf2a7 changed the way the report decides if the data comes from a single session: now if all the orders in the user selected start and end date belong to one particular session, the start and end date on the report are overriden to be those of that particular session, ignoring the user selected ranges.

The fix
-------
Only overwrite the start and end dates when `session_ids` was passed (i.e. the report is about a specific session).

When called via date range + `config_ids` (from the backend wizard like in our reproduction steps), keep the user-selected range.

opw-6185106

Forward-Port-Of: odoo/odoo#270310
Forward-Port-Of: odoo/odoo#267200

This is because webclient knows the current value (c), but not the new
available choices, still with the previous one (a, b).

Actually this works correctly if the field is created within a model
class.

```py
if model_cls._setup_done__ and field._base_fields__:
    # the field has been created by model_classes._setup() as
    # Field(_base_fields__=...); restore it to force its setup
    name = field.name
    base_fields = field._base_fields__

    field.__dict__.clear()
    field.__init__(_base_fields__=base_fields)
    field._toplevel = True
    field.__set_name__(model_cls, name)
    field._setup_done = False

    models_field_depends_done.discard(model_cls)
```

It does not works with studio because there are no parent class
(`_base_fields__`), so the if is not reached.

A solution would be to check if the field is a manually created related
and mark the whole model for setup unlike when `_base_fields__` is
present where we only setup this specific field.

opw-6293768

Forward-Port-Of: odoo/odoo#270349

When importing a Peppol/UBL vendor bill containing a line with a 100% discount, the line was created in Odoo with quantity=1 and discount of 100*original_qty, instead of the
expected quantity=qty_original and discount=100%.

This happened because the line-level branching in
`_import_ubl_invoice_line_add_price_unit_quantity_discount` relied on the truthiness of `line_extension_amount` to detect whether the `LineExtensionAmount` node was present in the XML. a line with a genuine `<cbc:LineExtensionAmount>0</...>` was indistinguishable from a line where the node was missing, and fell
through to the fallback branch intended for incomplete XML. That fallback reconstructs the quantity from `<cbc:BaseQuantity>`, ignoring `<cbc:InvoicedQuantity>`, and then computes the discount percentage against the wrong denominator.

a `LineExtensionAmount` of 0 is the only legal way to express a fully discounted line, so this case must be distinguished from the node being absent.

the fix is simply checking if the line exist not if its True

opw-6176349

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

Forward-Port-Of: odoo/odoo#268954
Forward-Port-Of: odoo/odoo#265261

PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.

The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.

In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.

`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
    MISSING = 0    # function is not present (falsy)
    PRESENT = 1    # function is present but not indexable (not immutable)
    INDEXABLE = 2  # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.

task-6307060

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

Forward-Port-Of: odoo/odoo#270420
Forward-Port-Of: odoo/odoo#270278

#### Description of the issue/feature this PR addresses:
Opening the Asset Depreciation Schedule report with a period comparison enabled crashes with KeyError: 'no_format' when prefix grouping is active (large number of assets in one account group). The report becomes unusable for affected customers.

#### Current behavior before PR:
_regroup_lines_by_name_prefix sums each subline column by indexing prefix_subline['columns'][i]['no_format'] directly. Empty columns are built as {} by _build_column_dict (both col_value and col_data are None), so they have no 'no_format' key. With a comparison period enabled, an asset that has no value in the comparison period produces an empty column for that period; once prefix grouping fires (len(lines) >= prefix_groups_threshold, default 4000), the direct lookup hits that empty dict and raises KeyError: 'no_format'.

#### Desired behavior after PR is merged:
The prefix group total treats a missing 'no_format' as 0, matching the sibling caller in account_asset/models/account_assets_report.py that already guards with .get('no_format', 0). The report builds without crashing and the empty comparison column contributes 0 to the prefix group total.

opw-6225639

Forward-Port-Of: odoo/enterprise#119775
Forward-Port-Of: odoo/enterprise#119088

Since https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac, in certain cases, customers sending large batches of emails to an accounting email alias would report a small number of emails being bounced (ca. 5%).

Context:

1. While processing an email (after matching mail.alias, with the thread going through `message_process`), if an error is uncaught and raised, the mailgate generates a bounce email, as we presume that the email could not be processed correctly.
2. When sending an email with an attachment to an accounting journal alias, depending on the DB configuration, IAP calls for automatic OCR are triggered asynchronously. These calls trigger callbacks from the IAP server, which might hit the DB in parallel while another thread is processing another email. Given their nature, they trigger updates on the relevant account.move, thus triggering downstream computes in the model.
3. When processing an attachment, the account module triggers `_extend_with_attachments`, which tries decoding the attachment in a rollback context (see:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/account/models/account_document_import_mixin.py#L343-L344). If a SerializationError happens during that process (concurrent update), it will NOT use the retry mechanism of the ORM because the error is caught in the `except Exception` block. Instead, it will try to post a message to the record to inform the user that the attachment could not be processed.
4. The commit mentioned above changes the way `_update_sequence_made_gap` works. One side effect seems to be that every time `made_sequence_gap` is re-assigned (even if the value does not change per se), the ORM tries to update the `write_date` on the flagged invoice that generated a sequence gap.

Bug:
Given the above context, emails might bounce unnecessarily for a valid email alias and a valid email with an attachment if:

1. The journal is not using a slash-based sequence pattern (e.g., using "1234" for the naming instead of "INV/2026/1234"). In that case, `sequence_prefix` == "".
2. The first invoice does not start at "1".
3. When sending a burst of simultaneous emails in a multi-worker setup, each thread will trigger `message_process` and downstream accounting computes while processing the invoice. It will also trigger IAP calls and callbacks asynchronously when automatic digitization is activated.
4. Each draft invoice that is created is named "/", meaning `sequence_prefix` == "", which in turn re-triggers the checks in `_update_sequence_made_gap`.
5. This increases the chances dramatically of a serialization error while all the parallel processes indirectly trigger an update on the `made_sequence_gap` field of invoice "1234".
6. Most of the time, the serialization error is not triggered in the thread processing the email, which correctly retries it. But in the few unlucky cases where it is raised in the thread processing the email, it will be triggered in the transaction rollback in `_extend_with_attachments`. While handling the exception, it triggers a second error because it tries to post a message to the record that was just rolled back: -> `ERROR: current transaction is aborted, commands ignored until end of transaction block` is raised in the thread running `message_process`, which in turn triggers a bounce email.

Example logs (simplified):

```
2026-06-12 14:12:15 [Worker-Thread-101] INFO mail_thread: Routing email (1)
2026-06-12 14:12:15 [Worker-Thread-102] INFO mail_thread: Routing email (2)

2026-06-12 14:12:16 [Worker-Thread-101] INFO iap_tools: dispatching /parse
2026-06-12 14:12:16 [Worker-Thread-102] INFO iap_tools: dispatching /parse

2026-06-12 14:12:18 [Worker-Thread-101] INFO iap_tools: Webhook received,
triggering /get_result
2026-06-12 14:12:18 [Worker-Thread-102] INFO iap_tools: Webhook received,
triggering /get_result

2026-06-12 14:12:19 [Worker-Thread-101] INFO odoo.sql_db:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
-> STATUS: OK (Acquired Row Lock)

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
ERROR: could not serialize access due to concurrent update
psycopg2.errors.SerializationFailure: could not serialize access

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
SELECT "mail_message"."id" FROM "mail_message" WHERE ...
ERROR: current transaction is aborted, commands ignored until end of
transaction block
psycopg2.errors.InFailedSqlTransaction: transaction is aborted

2026-06-12 14:12:19 [Worker-Thread-102] INFO "POST /saas_worker/smtp" 200
-> triggers Bounce email

```

Proposed Fix:
A) We update the conditions in `check_around` to ignore draft invoices when they are the "previous" entity being checked. Only posted invoices should be considered when doing the gap checks.
B) We add some guard clauses to prevent unnecessary writes to invoices that created sequence gaps. Instead of assigning values directly, we store the result of the check and only assign `made_sequence_gap` explicitly if the value is different from the currently stored value. This prevents unnecessary writes to the record if the value did not change.

Note:
- We chose this approach instead of touching `_extend_with_attachments` and the rollback context directly. Mostly to prevent any unforseen side-effects, given that this methods are used in accounting for all attachments. But it might be worth analysing if those methods might be improved to handle scenarios as described above in multi-worker setups + email handling.
- fixing the rollbackable context might tricky because the serialization error happens at the first `cr.commit()` inside the context manager
- raising explicitly with `except psycopg2.extensions.TransactionRollbackError:` in `_extend_with_attachments`
retries the whole request to the `message_process`, which might not be a good idea

OPW-6272396


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

Forward-Port-Of: odoo/odoo#270251

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

Forward-Port-Of: odoo/odoo#265582

There's a few problems with kits and cogs
This PR fixes them and unskips most tests 
of the test class.

**Problems:**
- Problem 1 multiple steps delivery 
  - steps to reproduce: 
    - activate 3 steps delivery 
    - create 2 storable products 'comp A' and 'comp B' 
with category standard perpetual
    - for both : set a cost of 10 and on on hand quantity
    - create a storable kit product with category standard perpetual 
    - create a kit bom for the kit product with 1 comp A and 1 comp B
    - confirm a SO for 1 quantity of the kit prod
    - validate only first delivery
    - confirm invoice 
  - Current behaviour: 
 No cogs line 
  - expected behaviour : 
There should be cogs for 20$
- Problem 2 multiple kits in Bom : 
  - steps to reproduce: 
    - (multiple steps delivery not needed)
    - use same products as for problem 1 but, in the Bom, set
    the number of kit products produced to 2
    - confirm a SO for 2 quantity of the kit prod
    - validate all pickings
    - confirm invoice 
  - Current behaviour: 
 Cogs have a value of 10$
  - expected behaviour : 
There should be cogs for 20$
- Problem 3: fifo comp
  - steps to reproduce: 
    - with 1 step delivery
    - create a storable product 'comp A' with fifo perpetual
    category
    - Confirm a PO and validate receipt for 1 comp A at 10
    - Confirm a PO and validate receipt for 1 comp A at 20
    - create a storable product 'kit' with fifo perpetual categ
    - create a kit bom for the kit product with 1 comp A
    - confirm SO for 2 kit
    - deliver 1 quantity and create backorder
    - confirm invoice for 1 
    - COGS line are created for 10$ (as expected)
    - deliver the backorder
    - confirm invoice for 1
  - Current Behaviour: 
  Cogs are created for 15$
  - Expected Behaviour: 
  Cogs should be created for 20$

**Cause of the issues:**
To compute the price_unit used for the cogs we call 
_get_cogs_value()
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/stock_account/models/account_move.py#L122
What we want is the price unit for 1 unit of the kit product
So we want : 
sum(unit price of each comp * quantity of comp in bom)/ quantity of kit in bom
What is done for now : 
Inside the sale_mrp override, for each component of 
the bom we call _get_price_unit() on its move and 
add the value to 'average_price_unit' and then divide
by the quantity of the kit product in the bom
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/sale_mrp/models/account_move.py#L38-L42
Inside the sale_mrp override of _get_price_unit() 
we return _get_kit_price_unit() called on the move,
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/sale_mrp/models/stock_move.py#L15
Inside _get_kit_price_unit(), the variable 'component_qty_per_kit', 
contains the quantity of each component as recorded in the bom 
times the valued quantity (sale order line quantity).
For each comp :  
    - we store the return value of _get_price_unit 
called on its moves in 'price_unit'.
    - we add to 'total_price_unit': 
    price_unit * component_qty_per_kit/ the kit qty in the bom
we then return total_price_unit / valued quantity
So we actually return:
sum(unit price of each comp * quantity of comp in bom* 
valued quantity)/ (quantity of kit in bom * valued quantity)
which is equal to:
sum(unit price of each comp *quantity of comp in bom)
/ quantity of kit in bom
https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/mrp_account/models/stock_move.py#L40-L44
Problem 1 is caused by the fact that _get_price_unit()
will return 0 if there's only internal moves because
they have a value of 0.
(The problem does not happen with a single component
cause then the fallback on the super method is correct, but 
with multiple comp the super method also returns 0
because _get_cogs_price_unit returns 0 when more than 
one product).
Problem 2 is caused by the fact that we divide by the 
quantity of the kit in the bom (kit_bom.product_qty) here 
(inside _get_kit_price_unit) and again inside _get_cogs_value
as mentionned before.

Problem 3 happens because there is no mechanism 
to account for already posted cogs inside the sale_mrp 
override of _get_cogs_value(), as qty_invoiced
is computed but never used
https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/sale_mrp/models/account_move.py#L31

**Fix** 
As regards to the super methods (so non kit scenario),
_get_cogs_value() is used to : 
  -  use original invoice if needed
  - use standard price of the product if no moves
  - deduct already posted cogs 
  - calls get _get_cogs_price_unit() to compute price_unit 
based on the moves

All of this is also wanted for kits and don't need adaptation, 
therefore the override should be on the _get_cogs_price_unit
where we do need a different behaviour when the product is a kit
Doing this we benefit from the 'already posted mechanism' 
from _get_cogs_value which solves problem 3

Additionally, instead of calling get_price_unit we can directly 
call the super method _get_cogs_price_unit as we have 
already computed all the components quantities needed 
for our computation and therefore don't need 
_get_kit_price_unit to recompute all of this.
Also, _get_cogs_price_unit will fall back on the product
standard price if the move has no value which solves 
problem 1.
That will also prevent dividing twice by the quantity 
of kit product in the bom (bom.product_qty) 
which solves problem2.

**Tests:**
Out of the 9 existing tests of the class (that were skipped
before this PR) and after adapation to v19 valuation : 
- 2 succeeded before and after the fix : this PR unskips them
- 5 failed before the fix and now suceed with the fix : this PR 
unskips them 
- 2 failed before the fix and after the fix, they were let 
skipped
In addition, 2 tests were added to cover problem 1 and 3
(problem 2 is covered in test test_sale_mrp_kit_bom_cogs)

Forward-Port-Of: odoo/odoo#270075

This is because webclient knows the current value (c), but not the new
available choices, still with the previous one (a, b).

Actually this works correctly if the field is created within a model
class.

```py
if model_cls._setup_done__ and field._base_fields__:
    # the field has been created by model_classes._setup() as
    # Field(_base_fields__=...); restore it to force its setup
    name = field.name
    base_fields = field._base_fields__

    field.__dict__.clear()
    field.__init__(_base_fields__=base_fields)
    field._toplevel = True
    field.__set_name__(model_cls, name)
    field._setup_done = False

    models_field_depends_done.discard(model_cls)
```

It does not works with studio because there are no parent class
(`_base_fields__`), so the if is not reached.

A solution would be to check if the field is a manually created related
and mark the whole model for setup unlike when `_base_fields__` is
present where we only setup this specific field.

opw-6293768

Forward-Port-Of: odoo/odoo#270349

Steps to reproduce:
===================
1. Edit a job page.
2. Delete every `s_rating` block.
3. Save.

=> Validation Error: Document is empty.

Cause:
======
Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does
`html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving.

The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1])
added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path.

Solution:
=========
Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed.

[1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529

opw-6244892

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

Forward-Port-Of: odoo/odoo#267397

PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.

The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.

In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.

`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
    MISSING = 0    # function is not present (falsy)
    PRESENT = 1    # function is present but not indexable (not immutable)
    INDEXABLE = 2  # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.

task-6307060

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

Forward-Port-Of: odoo/odoo#270420
Forward-Port-Of: odoo/odoo#270278

Step to reproduce:
1. Install `website_link`
2. Open Website > Site > Link Tracker
3. Type in text into any pre-defined field (Campaign, Medium, Source)
4. Observe that the input is not showing all the typed characters

Issue:
- It's randomly removing characters, for example, type "1234567890" and observe

Cause:
- SelectMenu updates its internal searchValue only inside the debounced onInput handler `debouncedOnInput`. When an autocomplete callback reloads choices before that debounce fires, the component rerenders with a stale searchValue and writes that outdated value back into the controlled input, overwriting newer characters already typed by the user.

Solution:
- Update searchValue immediately on every raw input event and keep only the search callback debounced.
- Also reset searchValue to null when a required single-select is blurred while empty, so the input falls back 
  to the selected choice label instead of staying visually cleared.

opw-6000540

---

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

Forward-Port-Of: odoo/odoo#255819

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#120251

Version:
- saas-18.4

Steps to reproduce:
- Create a sign template with a readonly sign item linked to an auto field.
- Use a reference record where the auto field value is 0 or False.
- Send the document for signing and try to sign it
- Observe that the readonly field is not populated with the auto-filled value.

Issue:
- Readonly sign items using auto-filled values from a linked record could not be validated when the value was 0 or False. Instead of using these values, the sign item kept its default value.

Cause:
- A previous fix was added to avoid replacing existing values with empty auto-filled values. However, the check also considered valid falsy values such as 0 and False as empty, so they were not populated into the sign item.

Fix:
- Only treat empty strings as missing auto-filled values. This allows valid values such as 0 and False to be populated correctly. Since the sign item value is stored in a text field, False is converted to the string "False" before storing it, ensuring it is preserved and correctly available during the signing flow.

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

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

Forward-Port-Of: odoo/enterprise#120747
Forward-Port-Of: odoo/enterprise#112654

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/odoo#269552

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#120251

**Description of the issue/feature this PR addresses:**

Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased.

For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`.

However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision.

This is inconsistent with sales: sale order lines preserve very small unit prices correctly.


https://github.com/user-attachments/assets/03d13596-d72b-4aee-bd37-7910a5842456



**Current behavior before PR:**

A product with `standard_price = 0.001235` keeps that value on the product form.

When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost.

The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line.

**Desired behavior after PR is merged:**

Purchase order lines preserve the computed unit price precision, just like sale order lines already do.

A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision.

---

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

Forward-Port-Of: odoo/odoo#269066
Forward-Port-Of: odoo/odoo#267664

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#120251

Bug 1: In the departure tab of the Employee, you can't open the payslip list
Fix: Added a check to get the correct departure id depending on the model we are in

Bug 2: You can select payslips for other employees than the departing employee and the payslips list is not affected
Fix:
- made fields `l10n_be_payslip_n_ids` and `l10n_be_payslip_n1_ids` stored and added a domain on them to only show the payslips of the departing employee
- when a payslip is validated for the departing employee after creating the departure, it's added to the corresponding field

Bug 3: You get an error because you can't read `currency_id` when opening n payslips (happens when the monetary fields are shown in the list)
Fix: moved the `currency_id` to be inside the list instead of the parent form

Note: the relation names for `l10n_be_payslip_n_ids` and `l10n_be_payslip_n1_ids` are changed to avoid upgrade error `m2m relations have respawn` as they existed before 19.2 in the removed `hr.departure.wizard` model.

task-id: 6265648

### Steps to reproduce:
- Install 'Appointment' app
- Configure an Appointment Type with your user as staff member
- Go to the Appointments Gantt view
- Click on the 'New' button to create a new appointment
> The staff member is not automatically added to the meeting's attendees (guests) list.

### Cause of Issue:
When generating the default values for a new calendar event from the Gantt view (indicated by `booking_gantt_create_record` in the context), the base `default_get` method doesn't account for auto-adding staff members in obvious cases (when there's only one staff member available or the current user is one of the staff).

### Fix:
Override `default_get` in `calendar.event` to automatically add these staff members when they are the only available option, providing a smarter and more seamless UX.

opw-6181794

Note: the same PR was done for 18.0, but now this is moving it to master since it's more of a feature not a fix.
Original PR: https://github.com/odoo/enterprise/pull/118331

The website appointment calendar fills availabilities one month at a time and the update_available_slots route maps the calendar month index to an absolute month from datetime.now(). This only matches the displayed months when the first one is the current month. When the first bookable slot is later, a punctual appointment starting in a future month or any appointment whose "at least X hours before start time" lead time pushes the first slot past the current month, navigating forward requests the wrong month and the reached month renders empty.

In update_available_slots, take the lead time into account when computing the reference month so it lands on the first displayed month: the start datetime for a punctual appointment starting in the future, otherwise now plus the minimum schedule hours. The navigated month index is then added to that reference. This extends https://github.com/odoo/enterprise/commit/f0e5b14a823cf97218f4094d287a328e2744fd73 which only handled the future start datetime.

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type, set Schedule to Weekly and Allow Bookings to On specific dates with a range ending a few months out
3. Set the "at least N hours before start time" field to 360
4. Save and click the Preview button in the header
5. Pick a resource or staff member to reach the calendar
6. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#120715

In the current code, for each slot, and for each "available"
resource, we check if the resource is available on the slot,
based on availability values. Then, we check the remaining
capacity of that resource. Also, linked resources information
is added when computing the original resource remaining capacity.
If many linked resources exist, this will be done several times
and is not useful.

This commit makes that loop disappear. We now check all resources
at once in terms of availability, and linked resources that could
be selected (in the appointment resources, in the slot resources
(if any restricted resource)) at the same time. Then, the total
capacity is the sum of the resource remaining capacity and the
ones of available linked resources.

Therefore, _slot_availability_is_resource_available is renamed to
_slot_available_resources, as it now takes more than one resource
and returns all resources among 'resources' that are valid on
the slot, based on the availability_values, slot restrictions and
booking lines.

A noticeable difference is mainly seen when using many resources
(and linked resources). For instance, a restaurant with a lot of
small tables will have their slot availability check much shorter.

BENCHMARK, LOCAL (time only, as number of requests does not change)
Only appointment installed

For a restaurant with
- 10 tables of 2
- 5 tables of 2 linked, 2 times
- 10 tables of 4
- 2 table of 2
- time then auto assign

On loading /appointment/id:
~ 3.1s -> ~ 1.6s
On selecting any number of people (1 to 10):
[2s, 2.5s] -> [0.6s, 0.8s]

Task-4144524

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#120251

### Issue
Loading a large General Ledger (e.g., during an "Unfold All" action)
and retrieving display names for thousands of journal lines 
(`account.move.line`) causes excessive memory and performance overhead.

Profiling with `memray` showed that one of the main memory hotspots 
was located in `custom_label_builder`.

**Previous behavior:** Accessing `record.display_name` in a loop without
an explicit `fetch()` call triggered lazy computation of the field via
`_compute_display_name()`. When the compute method accessed stored
dependency fields (such as `name`, `ref`, `move_id`), each cache miss
went through `_fetch_field()`, which greedily loaded **all fields sharing
the same prefetch group** on the model, far beyond the dependencies of
`display_name` alone. This caused the ORM cache to be filled with many
unnecessary stored fields for every record in the prefetch set.

---

### Dataset Volume
The performance metrics were captured using a dataset consisting of:
* **455,694** Journal Items (`account.move.line`)
* **19,947** Journal Entries (`account.move`)

---

### Solution
Add a single `fetch(['display_name'])` call on the browsed recordset.
By calling `fetch(['display_name'])` upfront, the ORM goes through 
`_determine_fields_to_fetch(['display_name'])`, which walks
only the declared `field_depends` of `display_name` and fetches **only
those specific stored fields**. nothing more.

---

### Impact & Results

| Metric | Before Optimization | After Optimization | Change / Note |
| :--- | :--- | :--- | :--- |
| **Peak Memory** | ~856 MB | ~223 MB | ~74% reduction |
| **Execution Time** | 2.48s | 2.13s | About the same time with multiple tries |

OPW-6275158

### Description

`.o_notebook_headers` sets `overflow-x: auto` while leaving `overflow-y` at its default `visible`. Per the [CSS overflow spec](https://www.w3.org/TR/css-overflow-3/#overflow-properties), when one axis is not `visible`, the computed value of the `visible` axis becomes `auto`. So `overflow-y` resolves to `auto`, and a sub-pixel vertical overflow (the active tab border / nav-link height) renders a useless vertical scrollbar next to the tabs — even when the tabs fit horizontally (no horizontal overflow).

Pinning `overflow-y: hidden` suppresses it, without affecting the legitimate horizontal scrolling of the tab bar when the tabs don't fit.

### Steps to reproduce
1. Open any form view with a notebook in a maximized window where the tabs fit horizontally.
2. A short vertical scrollbar is drawn at the right of the tab bar, scrolling nothing.

### Note
Already fixed on `master` (`addons/web/static/src/core/notebook/notebook.scss` has `overflow-y: hidden`). This backports the one-line fix to 18.0.

<img width="2637" height="1924" alt="29476" src="https://github.com/user-attachments/assets/9b51723d-5b98-4047-b51a-65c56c2505ce" />
<img width="1661" height="499" alt="88342" src="https://github.com/user-attachments/assets/0e7299f1-7b2b-4b19-9c2f-ff9bd3985e98" />

Issue:
Sending payments to CFDI before its full amount is reconciled allow sending the same invoice payment several times to CFDI. So some invoices are declared as paid several times and the total amount of the payment is seen as exceeding the real total.

This fix is a back port of odoo/enterprise#108355 and aim to prevent some things the backend allow, but the front end prevents.

Following steps could be used to reproduce from 18.3.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear before version 18.3)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

opw-5432421

Description of the issue/feature this PR addresses:
Since [1], studio binary fields uploaded through a form store their filename.
Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses.
Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields.
This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form.

Current behavior before PR:
When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file.

Desired behavior after PR is merged:
Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file.

Task related to this issue: https://www.odoo.com/odoo/project.task/5917543

[1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3
[2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f



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

Forward-Port-Of: odoo/odoo#268014

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

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

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

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

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




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

Fix a concurrency race condition in the product catalog where rapid quantity updates could result in incorrect final quantities on Sale Order Lines (SOL).

Steps to produce:
---
- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot.
- Open a Sale Order (SO) and open the Product Catalog.
- Rapidly change or paste quantities (e.g., changing from 1 to 100) across multiple records very fast.
- Return to the SO. Some lines intermittently retain an intermediate quantity (e.g., qty = 1) instead of the final entered value.

Cause:
---
- This is a concurrency issue. In the faulty cases, the `update_order_line_info` setting quantity to 1 takes a few seconds to resolve, while the update setting quantity to 100 resolves faster (around 200ms). This cause the SOL final quantity set to 1.

Fix:
---
- We can chain RPC calls to ensure that each request is completed before starting the next one.

Backport of ef9554ad95d5e39ab7b550db0d39454373f99aed

opw-6282877

---

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