A date filter (`<filter date="date_start"/>`) filters on a single field: the periods it offers, as well as the relative ones introduced in [1], match the records that *start* in the searched period.

For models describing a range rather than a single date, it is useful to be able to search for records that are ongoing during a given period.

A date filter can now name the field ending that span:

    <filter string="Period" name="period" date="date_start" end_date="date_stop"/>

Its periods and its relative options then match the records overlapping the searched period:

    ['&', ('date_start', '<=', period_end),
     '|', ('date_stop', '>=', period_start),
     '&', ('date_stop', '=', False), ('date_start', '>=', period_start)]

A record with no end date ends when it starts. Each bound is serialized with the type of the field it is compared to, so that a date field and a datetime field can be paired.

Task-6546268

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

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Backport of https://github.com/odoo/odoo/pull/287446
which one is a Forward-Port-Of: https://github.com/odoo/odoo/pull/285915
because freeze v20 meanwhile

Several diff for OXP

[IMP] event: improve A4 foldable badge
-> required for oxp kenya - if you have ticket instruction, use it on badge + add qr code always visible

[IMP] event: don't show tag (question reply) if only one choice
-> fix case of "yes, agree" show on badge as tag "yes"
 
[IMP] website_event_track: typo and make it less verbose 
-> FP quick pass usability

[IMP] website_event_track: replace fa-bell by fa-star 
-> why ? not sure better after... but FP request
-> + add menu whishlist directly in event sub menu

## deploy

```
views = [
	'website_event_track.agenda_main_track',
	'website_event_track.track_card',
	'website_event_track.tracks_search',
	'website_event_track.event_track_aside_other_track',
	'website_event_track.track_widget_reminder',
]


from odoo.upgrade import util

for xmlid in views:
	util.update_record_from_xml(env.cr, xmlid)
```

Forward-Port-Of: odoo/odoo#285915

Forward-Port-Of: odoo/odoo#288790

**Problem:**
Searching on free_qty can be slow when there are many stock.move and stock.quant. The search method uses _compute_quantities_dict() to compute the free_qty based on stock.move and stock.quant, which is expensive.

**Solution:**
A similar field, qty_available, has a faster search method based on stock.quant only. This method can be adapted to support fast searching on free_qty by also aggregating the reserved_qty and subtracting it from the qty_available.

**Perf Table:**
Record: product.template, with ~20k stock.picking and most products w/o moves.

|Record count|Time before|Queries before|Time after|Queries after| 
|------------|-----------|--------------|----------|-------------|
|10k         |2.14s      |214           |370ms     |45           |
|50k         |6.06s      |644           |829ms     |50           |
|100k        |11.42s     |1196          |1.05s     |46           |

opw-6266096

Forward-Port-Of: odoo/odoo#287363
Forward-Port-Of: odoo/odoo#270434

Currently a module with `countries` in the manifest is only installed in case
a company with a matching country exists.

This commit relaxes the constraint: In case we have already installed a module
"from that country" we still install the module.
For this we only consider modules that have a single country set in
the manifest. (To avoid installing "generic" modules with multiple
countries that we do not want.)

The current behavior may cause unexpected behavior in case a module is manually installed
in case such a company does not exist.
(This i.e. causes issues with the runbot tests from time to time)

Consider the following case:
`l10n_XX`: `countries: ['XX']`
`l10n_XX_reports`: `countries: ['XX']`

In case we manually install `l10n_XX` but no company has country `XX`.
Then we would not install `l10n_XX_reports`.

The current workaround is to just not set the `countries` in dependecies
but only in the "root" modules.
But this requires knowledge of this problem. So it is sometimes not done.
So currently we have to do "cleanup" PRs from time to time.

Another issue with the workaround is that the `countries` also gives additional metainformation
about the module that is lost. E.g. the `countries` info is used to display flag icons
for the module in the `Apps` application.

task-None

Prior to this commit, the payroll dashboard could experience high latency 
during load times. This was primarily caused by the heavy use of `safe_eval` 
to compute Python-based warning actions (`evaluation_code`), as well as the 
rigidity of the `button_action` (Many2one) field which limited dynamic UI routing.

This commit refactors the warning action system to fix these performance 
issues and clear technical debt:
- Replaced the relational `button_action` field with a generic JSON-driven 
  `action_config` text field on `hr.payroll.warning`.
- Migrated all existing data records in `hr_payroll`, `l10n_be_hr_payroll`, 
  and `l10n_be_hr_payroll_account` to use `action_config`.
- Converted several Python-evaluated warnings into pure `domain` warnings 
  by moving static dictionary generation and `group_by` clauses into the 
  JSON configuration, allowing the backend to skip `safe_eval` entirely.
- Improved the separation of concerns: the backend strictly handles ORM 
  detection (`warning_domain`), while `action_config` handles UI routing.
- Set up the infrastructure to support volatile frontend context keys 
  (e.g., for autofocusing fields) without polluting the ORM context.

This commit improves the UI of appointment:

* To improve the readability of the "total_capacity_reserved" field in the records of the kanban view, its background color is lightened.
* The default alarm of the appointment type is set to 1 day.
* The name of the appointment booker is no longer used for the greeting in the confirmation email since it is not set if the appointment is done from the backend. Instead of it, the first of the attendees is used and if they do not exist, the organizer is used.
* The popover is improved. Margins are placed between the buttons in the footer, to avoid having them stuck to each other. A maximal width is set for the videocall_location field, this way it does not impact the size of the popover.
* To avoid a technical label, the default falsy label of CalendarEvent.resource_ids, which is "Undefined Attendee", is replaced by "Unassigned".

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

Task-6566639

Forward-Port-Of: odoo/enterprise#131840

mock- https://link.excalidraw.com/l/65VNwvy7c4X/1BoTHSkGUpa

- Added new warning on payroll dashboard for employees not having allocation.
  Doesn't apply to employees without contract and salary structure dirigeant.
- Added "Not defined" on employee form o-stat-value when there is no allocation.
- Added new button "Grant Time off" on employee Time Off dashboard only visible
  to time off managers and when no allocation. On click-> new allocation request
  form opens.
- Updated fields for New Allocation request form from Time Off Dasboard:-
   - Removed name field.
   - Rename "Ask for" to "Duration" for `number_of_day_display` field.
   - Change time type field to widget time type tags
   - New button "Grant" in place of "Submit Request" directly approves requests.
- Updated the popover form for Time off gantt:
   - Warning message on no allocation shows is in alert-danger class.
   - If there is no enough allocation then "Allocate & Add" appears which
     creates required allocations with leaves.

task-6476239

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

*: point_of_sale

This commit applies the appropriate border-radius adjustments to the <aside/> elements in the related kanban cards.

task-6573555

Requires:
- https://github.com/odoo/enterprise/pull/132125

In `pos.category.kanban`
| Before | After |
|--------|--------|
| <img width="385" height="203" alt="Screenshot 2026-09-18 at 11 10 40" src="https://github.com/user-attachments/assets/67537bf4-0aff-4b94-909f-59c7cf60cb96" /> | <img width="389" height="201" alt="Screenshot 2026-09-18 at 11 10 38" src="https://github.com/user-attachments/assets/a9682a97-2fc2-4104-ae5f-794b267273b0" /> |

In `Product.template.product.kanban` and `Product Kanban`
| Before | After |
|--------|--------|
| <img width="380" height="102" alt="Screenshot 2026-09-18 at 11 13 59" src="https://github.com/user-attachments/assets/6a437efe-d1fd-483b-9f48-35e625dae5d1" /> | <img width="383" height="102" alt="Screenshot 2026-09-18 at 11 14 05" src="https://github.com/user-attachments/assets/bce0285c-2a06-484a-9592-dfde2a908d0d" /> |


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

Forward-Port-Of: odoo/odoo#289138

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

**Steps to reproduce:**
- Open Discuss app
- Open any conversation
- Setup the browser with throttled connection (e.g. Slow 4G)
- Select multiple files to attach but don't send the message
- While some are loading, double click the delete button of one of the loaded attachment preview
- Traceback will appear: `404 Not Found`

**Issue:**
On click the delete button triggers a deletion request on `/mail/attachment/delete`.

Repeatedly clicking the delete button before the first request was completed (and the `AttachmentList` get updated) but after the attachment was deleted, will cause a `404 Not Found` due to the `raise NotFound()` which was added by [1] in `mail_attachment_delete`.

```py
attachment = request.env["ir.attachment"].browse(int(attachment_id)).exists()
if not attachment or not attachment._has_attachments_ownership([access_token]):
    request.env.user._bus_send("ir.attachment/delete", {"id": attachment_id})
    raise NotFound()
```

**Fix:**
Prevent concurrent deletion requests for the same attachment by keeping track of attachments currently being deleted.

[1] https://github.com/odoo/odoo/commit/50f45dd436b97027cb1461410efeee7057dad4e8#

opw-6499125

Forward-Port-Of: odoo/odoo#288884
Forward-Port-Of: odoo/odoo#285060

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

*: hr_referral, esg

This PR applies the appropriate border-radius adjustments to the <aside/> elements in the related kanban cards.

About ESG, the default Kanban card only supports an aside on the left. However, in the Database Kanban view, the aside is positioned on the right, which causes issues with the card border radius and margins.
This PR adds module-specific customizations to handle this case.

task-6573555

Requires: 
- https://github.com/odoo/odoo/pull/289138

In `ai.agent.kanban`
| Before | After |
|--------|--------|
| <img width="389" height="220" alt="Screenshot 2026-09-18 at 11 17 22" src="https://github.com/user-attachments/assets/f887d40e-8b61-498f-9f24-dd6601721993" /> | <img width="387" height="222" alt="Screenshot 2026-09-18 at 11 17 28" src="https://github.com/user-attachments/assets/f013f743-a249-40de-9d85-6e78ce626f28" /> |

In `hr.referral.reward.employee.referral.backend.kanban`
| Before | After |
|--------|--------|
| <img width="386" height="136" alt="Screenshot 2026-09-18 at 11 19 36" src="https://github.com/user-attachments/assets/e853a646-1288-4c1a-806e-147edc9774f0" /> | <img width="384" height="129" alt="Screenshot 2026-09-18 at 11 19 25" src="https://github.com/user-attachments/assets/cc4f0137-e402-4486-8f5a-7af54ca8fd99" /> |

In `hr.referral.reward.employee.referral.backend.kanban`
| Before | After |
|--------|--------|
| <img width="386" height="136" alt="Screenshot 2026-09-18 at 11 19 36" src="https://github.com/user-attachments/assets/e853a646-1288-4c1a-806e-147edc9774f0" /> | <img width="384" height="129" alt="Screenshot 2026-09-18 at 11 19 25" src="https://github.com/user-attachments/assets/cc4f0137-e402-4486-8f5a-7af54ca8fd99" /> |

In ESG/Configuration/Databases
| Before | After |
|--------|--------|
| <img width="386" height="167" alt="Screenshot 2026-09-18 at 11 20 57" src="https://github.com/user-attachments/assets/acfe0958-95ae-4e80-903e-8590a1804a06" /> | <img width="390" height="180" alt="Screenshot 2026-09-18 at 11 21 00" src="https://github.com/user-attachments/assets/a2c33ec5-84e8-4119-8625-f8411a7b609a" /> |

Forward-Port-Of: odoo/enterprise#132125

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

### Problem

`l10n_ar_edi` reports WSFEX / WSBFE line quantities (`Pro_qty`) truncated to 2 decimals in 19.0, no matter what precision the database has configured.

`_get_line_details()` reads the precision like this:

```python
uom_precision_digits = min(self.env['decimal.precision'].precision_get('Product Unit of Measure'), 2)
```

In 19.0 that `decimal.precision` record was renamed to **`Product Unit`** (`uom/data/uom_data.xml`, `decimal_product_uom`), so the lookup matches no record. `precision_get` does not raise in that case, it falls back to a default of 2 (`base/models/decimal_precision.py`: `return res[0] if res else 2`), so `min(2, 2) = 2`.

The rename was applied everywhere else — `account.move.line.quantity` already declares `digits='Product Unit'`. Only this lookup kept the old name.

### Impact

A quantity of `0.042` is sent as `0.04`. ARCA rejects the invoice with **error 1815** (item math inconsistency: `unit price x quantity - discount` no longer matches the item total), which blocks export invoicing completely.

It only shows up after upgrading to 19.0: on 18.0 the record still had the old name, so the lookup worked and the configured precision was used.

On our hosted fleet we identified **67 Argentinian databases** that use WSFEX or WSBFE and have a unit precision above 2. Eight of them already run 19.0 and are affected today; the rest will hit the same rejection as they upgrade.

### Fix

Use the current record name, and raise the cap to **6**, the maximum `Pro_qty` accepts according to the WSFEX developer manual ([V3.1.1](https://www.afip.gob.ar/ws/documentacion/manuales/WSFEX-Manualparaeldesarrollador_V3.1.1_ARCA.pdf), p. 15).

### Test plan

`l10n_ar_edi/tests/test_fex.py` adds `test_ar_edi_wsfex_pro_qty_decimal_precision`, covering three cases:

| `Product Unit` | quantity | expected `Pro_qty` |
|---|---|---|
| 3 | 0.042 | `0.042` |
| 2 | 0.042 | `0.04` |
| 8 | 0.1234567 | `0.123457` (capped at 6) |

It does not go through the ARCA mock: it calls `_get_rounded_base_and_tax_lines()` and `_get_line_details()` directly.

### Note

Supersedes #130582 by the same author, which carried the same one-line fix without a test. Please review this one instead.

### Left out on purpose

`price_precision_digits` in the same method caps the unit price at 3 digits, which does not come from the specification either. That lookup still uses a record name that exists (`Product Price`), so there is no regression, and we have no rejection reported because of it. Changing it would widen the scope of a fix that has a concrete incident behind it, so it is left untouched here.

Forward-Port-Of: odoo/enterprise#131457

Before this PR:
================
In several places, text is difficult to read due to the `bg-secondary` class used for styling.

<img width="350" height="200" alt="image" src="https://github.com/user-attachments/assets/5d24038e-a63c-457a-a457-91bc75dc615b" />                              <img width="350" height="200" alt="image" src="https://github.com/user-attachments/assets/30e78d9d-af1b-4281-bf52-57292ac9dd9f" />
<img width="350" height="200" alt="image" src="https://github.com/user-attachments/assets/45501029-2810-4907-82d0-6356c690e3db" />




After this PR:
===============
Replace the `bg-secondary` class with `bg-300` in the affected places, providing better
contrast between the text and its background and improving readability across the
Barcode and MPS views.

<img width="350" height="200" alt="image" src="https://github.com/user-attachments/assets/dc9e242b-1f60-42d3-8e58-b8a4f2b6fc2f" />                              <img width="350" height="200" alt="image" src="https://github.com/user-attachments/assets/d8c8ffa0-51b5-4b72-b092-e21b9dd56088" />
<img width="350" height="200" alt="image" src="https://github.com/user-attachments/assets/c3dbfebb-b348-4dee-8933-76acef8e1636" />




Community PR:- odoo/odoo#288498

Forward-Port-Of: odoo/enterprise#131741

### Issue before this commit:
When generating a Nilvera e-invoice in a foreign currency (e.g., EUR), the amount written in words inside the <cbc:Note> tag contained a mix of languages. While the numbers were correctly translated to Turkish, the currency subunit label was fetched using the customer's language. This resulted in a partially translated string (like "... SIFIR CENTS") instead of the expected fully Turkish text (like "... SIFIR SENT").

### Steps to reproduce the issue:
1. Download Accounting and l10n_tr_nilvera_einvoice
2. Create an API KEY: https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0#heading=h.e6i8a29lff5t
3. Go to a turkish client on the Accounting tab and click on 'Verify' for the Nilvera status
4. Go to currencies and activate EUR (be sure there is also the translation for currency subunit)
5. Go to invoices, create one for the Turkish customer you already verified setting the currency as EUR and send it with Nilvera
6. See that current output is <cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR CENTS</cbc:Note> (Turkish numbers with English subunit)
but the expected output is
<cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR SENT</cbc:Note> (Fully Turkish text)

### Cause of the issue:
The issue occurs because the currency_subunit_label field is not translated but fetched using the language of the customer in the invoice.

### Reason to introduce the fix:
To ensure that the amount in words inside the <cbc:Note> tag is completely formatted in Turkish, complying with Nilvera and local e-invoicing requirements, regardless of the customer language.

opw-6523794

Forward-Port-Of: odoo/enterprise#131873

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