Current behavior:
On /shop and in the product configurator, the reference price (price per UoM, e.g. $/kg) shown next to a product's price is wrong when the website only sells that product in a uom other than its base uom.

Steps to reproduce:
- Enable "Units of Measure" and "Product Reference Price"
- Create a product priced per g, with base_unit_count set for kg
- Add kg as a packaging and restrict the base uom (g) on the website
- Open /shop, or the product configurator, for that product

Expected behavior:
The reference price matches the "Price Per Unit" shown on the product's own form.

Cause of the issue:
`_get_sales_prices` and `_get_basic_product_information` divided the price directly by base_unit_count, without converting it from the uom used to compute that price (the main/pricing uom) to the product's base uom. When both differ, the result is off by their ratio.

Fix:
Convert the price to the base uom before dividing it by base_unit_count, in both the shop listing and the product configurator.

opw-6566849


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

Forward-Port-Of: odoo/odoo#288079

Opening a view whose search panel has a `select="multi"` field of type many2many crashes when a record is only linked to comodel records the user cannot see:

  File "/addons/web/models/models.py", line 1496, in
  _search_panel_domain_image id_, display_name =
  group_id_name(group[field_name]) TypeError: cannot unpack non-iterable
  bool object

Steps to reproduce:
- On a db with Social Marketing installed, social accounts are automatically created per website
- Open Social Marketing > Posts
- Create a new Post with an social account
- Open Settings > Social Accounts > the chosen social account
- Archive it
- Get back to the Post created above => crash

`_search_panel_domain_image` restricts the domain with `(field_name, '!=', False)`, which is evaluated on the comodel with sudo and active_test=False, while the group by of the same query joins the comodel through `_search`, which applies record rules and active_test. A record whose values are all archived or hidden by a record rule therefore passes the condition but ends up in a group with no value, which the image loop unpacks as a tuple.

This commit skips those groups: their values have no place in the range anyway.

Seen on runbot, where `runbot.build.error.trigger_ids` points at `runbot.trigger` records that are archived or restricted by the project group rule.

Forward-Port-Of: odoo/odoo#288731
Forward-Port-Of: odoo/odoo#288503

**Problem:**
Creating a view from Settings > Technical > User Interface > Views fails with a validation error, even though both the model and the architecture are valid.

**Steps to reproduce:**
1. Go to Settings > Technical > User Interface > Views
2. Click New
3. Set the View Name and pick a model in "Model of the view"
4. Set the View Architecture to `<list><field name="name"/></list>`
5. Save

**Current behavior:**
The record cannot be saved:

    Error while validating view near:
    <list __validate__="1"><field name="name"/></list>
    Model not found: False

Duplicating an existing view and editing the copy works, so the issue only shows up on brand new records.

**Expected behavior:**
The view is saved, and validated against the model that was picked.

**Cause of the issue:**
The form edits `model_id`, a non-stored `Many2one` whose inverse `_inverse_compute_model_id` is what actually fills the stored `model` field. The architecture is edited through `arch_base`, whose inverse chain ends in `_inverse_arch` writing `arch_db`; `write` then runs `_check_xml`, which validates the architecture against `view.model`.

Both values therefore reach the record through inverse methods, so the order those run in decides whether `model` is set by the time the architecture is validated. That order became deterministic in this version: the ORM sorts inverse groups by `(field.write_sequence, field index)`. Both fields keep the default `write_sequence` of 0, which leaves the declaration order to break the tie, and `arch` is declared well before `model_id` — so the architecture is validated while `model` is still empty.

The same ordering also breaks a plain edit: changing the model and the architecture of an existing view in a single save validates the new architecture against the previous model.

**Fix:**
`write_sequence` is the ORM's hook for exactly this kind of ordering dependency, so a negative one on `model_id` states the real constraint — the model has to be known before anything is validated against it — rather than leaving it to where the fields happen to sit in the class. It also covers the write path, which a create-only workaround would miss.

opw-6467991

Forward-Port-Of: odoo/odoo#284143

Steps to reproduce:
- Create a company contact with a delivery address that has no name
- Make a PoS order for the delivery address and pay it
- Open the PoS, open the customer list, and click "Orders" on the company

Issue:
The screen goes blank.

Cause:
The ticket screen is opened with the company name as search term. The server domain searches on `partner_id.complete_name`, so the orders of the address contact are returned too. They are then fuzzy matched on `getPartnerName()`, which returns `false` for a partner without a name, and `fuzzyLookup` calls a string method on it. The error is raised during rendering, so the whole app is destroyed.

Fix:
Make `getPartnerName()` always return a string, and fall back on the parent name, like the complete name does. This way the orders of the address contact are still listed when searching on the company name, instead of being filtered out by an empty name.

opw-6578541

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

Forward-Port-Of: odoo/odoo#288880

Issue:

Duplicating a product raises `ValueError: False is not in list` when the
product has a pricelist rule set on its variant and that variant holds no
attribute value.

Steps to reproduce:

1. Install `website_sale_renting` with the demo data.
2. Open the `Luxury Room` product, whose only attribute, `Breakfast`,
   doesn't create variants, and which has a pricelist rule set on its
   variant.
3. Duplicate it.

Cause:

`get_combination_key` builds the combination of a variant through
`product_template_variant_value_ids.mapped(...)`. On an empty recordset,
`mapped` calls the given function once with that empty recordset instead
of not calling it at all, so `attribute_line_id.id` is `False` and
`attribute_line_ids.index()` raises. A variant holds no attribute value
when its template has no attribute line, or only lines whose attribute
doesn't create variants.

Fix:

Iterate `product_template_variant_value_ids` instead of mapping over it,
so that a variant without attribute value gets an empty combination key.

Version:20 (bugfix)

Forward-Port-Of: odoo/odoo#288252

Currently, when the user re-reserves a component and produces an MO for a lot-tracked product, putaway rules stop working.

## Steps to produce:
- Install the Manufacturing application.
- Go to Settings and enable Lots & Serial Numbers and Storage Locations.
- Create a product named 'Laptop' and set it to be tracked by Lots.
- Create a product named 'Graphics card' with some quantity on hand.
- Create a Bill of Materials (BoM) for the Laptop with Graphics card as a component.
- Create a location named 'Laptop Shelf' with 'WH/Stock' as its parent location.
- Create a putaway rule:
  - When a product arrives in: WH/Stock
  - Product: Laptop
  - Store to: WH/Stock/Laptop Shelf
- Create and confirm a Manufacturing Order (MO) for the Laptop.
- Unreserve the components, open Details, and re-add the Graphics card.
- Click Produce All and check the on-hand quantity list view of the Laptop.

## Issue:
The Laptop is stored in WH/Stock instead of WH/Stock/Laptop Shelf.

## Root cause:
When the user presses the unreserve button the finished move is passed to `_do_unreserve`
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L2407

which unlinks all the move lines on finished product moves if they are not picked:
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L1043

Now when the user presses the Produce All button, `button_mark_done` is called, which calls `_post_inventory` at:
https://github.com/odoo/odoo/blob/a51ca77c825d2dba326dd540e2b4c04ef6c2385d/addons/mrp/models/mrp_production.py#L2236

`_post_inventory` assigns `lot_ids` to the finished product moves at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L1928-L1930

This calls `_set_lot_ids` which creates a move line with quantity 1 at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L679-L683

After that, `_post_inventory` sets the quantity for the finished product moves at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L1935

Which calls `_set_quantity` and the  delta quantity is now zero at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L477-L483

Because `_set_lot_ids` has already created a move line that satisfies the move quantity, `_process_increase` is not called.

Since `_process_increase` is not called, `_set_quantity_done` is never called at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L463-L465

Since `_set_quantity_done` is not called, `_apply_putaway_strategy` is never called within that function at:
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L2565

As a result, the laptop ends up in stock instead of on the shelf.

This issue did not occur in lower versions because the feature to produce multiple lots was introduced in version 19.0 by the following commit: https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e

Before this commit, only `_set_quantity` was called. Since no move line was created because lot_ids were not set in `_post_inventory`, `_process_increase` was called, which then called `_apply_putaway_strategy`, so the putaway rules were applied correctly.

## Solution:
Apply putaway rules in the post-inventory function after the user manufactures a product, ensuring the items are placed in the correct locations and preventing products from being misplaced even when putaway rules are defined.

opw-6517324

Forward-Port-Of: odoo/odoo#288739
Forward-Port-Of: odoo/odoo#287390

Steps to reproduce:
- Send an invoice to the SPV (Romanian e-Factura).
- Once the SPV finished processing it, click "Fetch Status" on the e-Factura document.
- Odoo crashes with binascii.Error: Incorrect padding

Cause of the issue:
_request_ciusro_download_answer extracts the signature file from the SPV zip answer and re-serializes it with etree.tostring(...), which gives plain XML bytes, not base64

But _l10n_ro_edi_fetch_invoice_sent_documents and the 3 other callers that persist that signature still ran it through base64.b64decode() before wrapping it in BinaryBytes (which already expects raw bytes, not base64). Decoding real XML as base64 only "works" by accident when the XML happens to contain a number of base64-alphabet characters that's a multiple of 4 after the invalid ones get silently stripped - otherwise it blows up with "Incorrect padding".

This got introduced by 41fe2ebdb9cc (fields.Binary return BinaryValue), which flipped a base64.b64encode() call to base64.b64decode() at these 4 spots instead of just dropping the base64 call entirely. A previous fix (0750ee145ae2) already fixed the sibling issue on the invoice's own attachment_raw but missed these.

Solution:
Drop the erroneous base64.b64decode around the signature's attachment_raw at the 4 call sites, and fix the tests that were mocking attachment_raw as base64-encoded instead of raw bytes

opw-6562123

Forward-Port-Of: odoo/odoo#288140

Versions
--------
- 20

Steps
-----
1. Create and save a quotation with a combo product;
2. change the pricelist for one giving a different price on that combo product.

Issue
-----
The combo item lines keep the prices given by the previous pricelist.

Cause
-----
Commit e78f729d removed the `Update Prices` button and moved `_recompute_prices` to the `pricelist_id` onchange. The lines are therefore in memory records now, whereas they were stored ones when the recompute was triggered by the button.

`_get_combo_item_display_price` prorates the price of the combo product, computed on the line returned by `_get_linked_line`. As of commit f1e68cc, that method returns `linked_line_id` whenever it is set, i.e. the stored line, whose `order_id` is the stored order, hence still the previous pricelist.

Solution
--------
When the line is an in memory record, look its linked line up among the order lines, by origin, so that the in memory version is returned.

opw-testing-day-v20

Forward-Port-Of: odoo/odoo#288543

## Description

Changing an employee version's working schedule recomputes the internal dates of subsequent time off requests.

The `hr.leave` write override then mirrors these recomputed UTC values back to the request dates. For timezones ahead of UTC, midnight on a non-working day can therefore shift the requested date to the previous day.

This fix marks the schedule-triggered re-computation as an internal fast update, ensuring that the dates selected on the time off request remain the source of truth while still allowing the leave duration to be recomputed according to the new working schedule.

Regression coverage is added to ensure that changing an employee's working schedule:

* preserves the dates selected on existing time off requests;
* correctly recomputes the leave duration according to the new schedule.

## Steps to reproduce

1. Create an employee with timezone Europe/Brussels and a Monday–Friday working schedule. Before creating any leave, set the employment record’s effective date and contract start date to 3 March 2025.
2. Create a full-day time off request from 23 to 26 February 2026. Its duration is initially four working days.
3. Change only the employee’s working schedule to a duration-based Tuesday–Friday schedule, with 7.6 hours per working day and Monday off. Leave the effective date and contract dates unchanged, then save.

**Before the fix:** the request’s start date incorrectly shifts to 22 February.

**After the fix:** the dates remain 23–26 February, while the duration correctly decreases to three working days.

opw-6456107

Forward-Port-Of: odoo/odoo#281385

Purpose:
---------
####  Show agents steps toggler in composer actions

The option to toggle the agents steps is missing in the composer actions.
There were 2 ways of adding composer actions for AI chats (probably after
resolving conflicts).

#### Update tool status when tools are called

The tool status in ai chats is not updated anymore when tools are called.
This happens because `_store_session_fields` is called when the
tool results are sent to the LLM since commit [1]
Therefore, we are sending the tool status which is immediately overridden
by this call to `_store_session_fields`.
This commit fixes it by removing the direct updates, and let `_store_session_fields`
handle this case as well.

This PR also changes the font-weight of the agent header in ai chats to match the one of the other users

#### Always rename ai chats on first message

Since commit 1, AI chats created with a channel title are not renamed
anymore.
This commit restores the previous logic, which is to always rename AI
chats on the first message (to make it easier to find them in the chat
history).

[1] a7523d2e84edb258f42141b3154493a8a8e12e58

Forward-Port-Of: odoo/enterprise#131681

If a client deletes a standard account or tax, its XMLID can no longer be resolved during the post-init hook. In that case, _load_data() may create a new record using only the provided data, e.g.:

```
('l10n_bg_691001', {'l10n_bg_saft_account_code': '624'})
```

This can lead to incorrect records.

Only update records whose XMLIDs still exist, avoiding the creation of new records when the corresponding standard record has been deleted.

```
File "/home/odoo/src/enterprise/19.0/l10n_bg_saft/__init__.py", line 10, in _add_account_saft_code
    Template._load_data({'account.account': Template._get_bg_saft_account_code()})
  File "/tmp/tmpbu1ntr1j/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 37, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5196, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5103, in _load_records_create
    records = self.create(vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1055, in create
    )).create(vals_list_for_company)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 329, in create
    threads = super(MailThread, self).create(vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/tmp/tmpbu1ntr1j/migrations/util/orm.py", line 267, in wrapper
    return f(*args, **kwargs)
  File "/tmp/tmpbu1ntr1j/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
    return super().create(vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4711, in create
    records = self._create(data_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4887, in _create
    cr.execute(SQL(
  File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 440, in execute
    self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "account_type" of relation "account_account" violates not-null constraint
DETAIL:  Failing row contains (734, null, 1, 1, null, null, null, t, f, f, 2026-08-25 08:18:15.751937, 2026-08-25 08:18:15.751937, no, f, null, null, null, null, 411).
```

upg-4611390
tbg-2902

Forward-Port-Of: odoo/enterprise#129145