Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377).

In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`).

When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass.

In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors.

To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present.

runbot-error-id~242235

Forward-Port-Of: odoo/enterprise#117075
Forward-Port-Of: odoo/enterprise#112486

__
## Short functional explanation of the error
When we set the departure of an employee. The version is retrieved using the dismissal date. However, employees can work after their dismissal date, until their departure (in the case of a notice, for example). Therefore, the departure date should be chosen instead.

## Reproduction Steps
1. Go to Employees and create a new employee. In the Payroll tab, set a start date for their contract. Hit save.
2. This will create a version. You can see it top right, with the contract date. Click on the '+' next to it and set a date later.
3. Click on the cog in the top left and click End of Collaboration. Set an End Reason. Set the Dismissal Date to occur during the first version and the Departure Date to occur during the second version. Then, click Schedule.

### Expected behavior
The Departure tab should appear when clicking on the second version, top right.

### Unexpected behavior
The departure tab appears on the first version.

## Origin of the issue
To select the version on which the departure occurs, we use this line of code:
https://github.com/odoo/odoo/blob/be8b1bbad757fda27df579ce36cbc97324f58f62/addons/hr/models/hr_employee_departure.py#L117 `departure_date` should be used instead.

__
opw-6079675

Forward-Port-Of: odoo/odoo#264667

* = hr_holidays

Before this commit, when displaying the IM status icon for employees on leave of companies the user does not have access to, we would not display the `fa-plane` icon or the "Back on" indicator.

Steps to reproduce:
- Create a new company X
- Create a new employee Y (with user) in company X
- With a user who does not have access to company X open the General channel member list -> no leave icon, open the avatar card -> no icon

This happens because since [1] the leave IM status icon is computed client side using the employee information, rather than computed on the `im_status` field itself.
This however causes problem in a multi-company context due to the field `employee_ids@ResUsers` having a field-level domain restricting to the requesting user's active companies.

This commit fixes the issue by fetching all of the user's employee_ids regardless of active company.

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

task-6191367

Forward-Port-Of: odoo/odoo#263024

# Setup
Have 2 companies : A & B

# How to reproduce
- Set your website's company to Company B
- Create product X :
	- Company : Company A
	- Published
	- Name : xyz
- Go to Users > Any User > Acces Rights > Allowed Companies => leave only Company A
- Connect as that user on the website
- Go to the Shop tab and search xyz

# The problem
The product X is displayed, even though we currently use the company B's website and the product is limited to company A. 
This causes problem later when Sales Order are created using that product.

If you set the Allowed Companies of the user to both Company A and Company B, then the product is correctly hidden

# Why
When you search something in the search bar, the server does a `_search_with_fuzzy()` that ends up calling a simple `model.search()`.
In our case, this search should not return product X because there is an `ir.rule` that hides product not in the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/product/security/product_security.xml#L34-L38

But the `website` module has some particular rule about setting the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/website/models/ir_http.py#L249-L261

So, in our case, since the user does not have company B in its allowed companies, then
`allowed_company_ids` = Company A. So `('company_id', 'parent_of', company_ids)` is trucy and the product is displayed

# Proposed solution
Doing the search with `with_company` raise an AccessError because the company is not present in the allowed_companies. Chaging the allowed companies logic seems risky because it
may lead to unintended side effects.

We instead enforce the website's company in the search's domain

opw-6115647

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

Forward-Port-Of: odoo/odoo#262635
Forward-Port-Of: odoo/odoo#260138

Steps to reproduce
1. Enable "Batch Account Move Lines" in the Payroll settings.
2. Configure two employees' versions with an analytic distribution on the
   same analytic account but with different percentages (e.g. {acc: 50}
   for the first employee and {acc: 70} for the second).
3. Generate a payslip run containing both employees and validate it.

Issue
The generated account move aggregates the two payslips into a single
line whose analytic_distribution matches only the last employee being
processed; the other employee's percentage is silently lost.

`_get_existing_lines` decides whether an incoming line can merge into an
already accumulated one. When the incoming line has an analytic
distribution, the merge condition delegates to
`_check_partially_matching_accounts`:

https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L254-L271
https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L273-L283

That helper returns True as soon as any analytic account of the new
line appears anywhere in the existing line's distribution dict, without
comparing percentages. Two distributions such as {acc: 50} and
{acc: 70} share the same account, so the helper returns True, the
lines are merged, and whichever distribution ends up on the merged line
overwrites the other — the total amount is correct but the analytic
split is wrong.

The logic introduced in commit https://github.com/odoo-dev/enterprise/commit/e40a3166286a6bc546e9543b935233d2a110dc52 successfully addressed merging for rule-level distributions
with composite keys (e.g., {'13,7,12': 40}). However, that implementation is overly inclusive for employee-specific distributions.
It fails to differentiate between cases where the same analytic account is utilized across various employees but with different percentage allocations.
Because it only checks for an account overlap rather than a perfect distributional match, it incorrectly aggregates distinct financial dimensions into a single journal line

Solution
Compare the full analytic_distribution dict by strict equality. Lines
merge only when the distribution is identical (same keys AND same
percentages), keeping the batch feature anonymizing identically
configured employees while preserving one line per distinct
distribution.

opw-6102508

Forward-Port-Of: odoo/enterprise#114156

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount.

This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`.

This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time.

[1]: odoo#169264
[2]: odoo#154349

Forward-Port-Of: odoo/odoo#263860

**Description of the issue this PR addresses:**
Previously, when a livechat conversation ended, it was never automatically 
marked as read. The existing `mark_as_read` mechanism depends on the 
composer being focused, but ended livechat conversations hides the composer, 
and the chat window does not focus the thread automatically 
(focus only happens on explicit click).

This made it impossible for the read state to be triggered through the normal 
path, leaving agents with persistent unread indicators on closed livechat 
conversations.

**Desired behavior after PR is merged:**
- Focus the composer when present.
- Focus the conversation otherwise.

This ensures the read state is correctly triggered when the conversation
is effectively in focus.

task-[5900038](https://www.odoo.com/odoo/project/1519/tasks/5900038)

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

Forward-Port-Of: odoo/odoo#263607
Forward-Port-Of: odoo/odoo#253609

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#117232
Forward-Port-Of: odoo/enterprise#112724

# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account

# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears

# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :

```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```

When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.

Why is that field set to NULL ?

Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id

When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.

Take for exemple the following Analytic Line :

```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```

When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :

```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```

So, we need to adapt to search so that it uses the right plan's name.

opw-5897037

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

Forward-Port-Of: odoo/odoo#263652
Forward-Port-Of: odoo/odoo#248236

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#263114
Forward-Port-Of: odoo/odoo#257342

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

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

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264586
Forward-Port-Of: odoo/odoo#241827

# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account

# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears

# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :

```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```

When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.

Why is that field set to NULL ?

Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id

When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.

Take for exemple the following Analytic Line :

```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```

When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :

```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```

So, we need to adapt to search so that it uses the right plan's name.

opw-5897037

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

Forward-Port-Of: odoo/odoo#263652
Forward-Port-Of: odoo/odoo#248236

Issue:
----------------------------------------
In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours.

Steps to reproduce:
----------------------------------------
- Open Planning
- Remove the default group by resources
- Have at least a planning slot for a non-flexible employee
- The total row doesn't take the working schedule into account

Cause:
----------------------------------------
Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678))

Solution:
----------------------------------------
In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars.

opw-5507063

Forward-Port-Of: odoo/enterprise#116824
Forward-Port-Of: odoo/enterprise#112522

When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines.

Steps to reproduce:
-------------------
* Install timesheet_grid and project_mrp_account
* Create product A, storable
* Create product B with a cost of 20 and also storable
* Update the available quantity of product B
* Create a BoM for product A, it should only require one product B
* Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver
* Create a first MO for 1 product A and produce it
* Create a second MO for 1 prodcuct A but just confirm it
* Login as Marc Demo and try to scrap the component of the second MO
> Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95

opw-5954989

Forward-Port-Of: odoo/odoo#261588
Forward-Port-Of: odoo/odoo#255824

# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account

# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears

# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :

```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```

When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.

Why is that field set to NULL ?

Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id

When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.

Take for exemple the following Analytic Line :

```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```

When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :

```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```

So, we need to adapt to search so that it uses the right plan's name.

opw-5897037

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

Forward-Port-Of: odoo/odoo#263652
Forward-Port-Of: odoo/odoo#248236

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#117450
Forward-Port-Of: odoo/enterprise#115085

### Issue before this commit:
In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Go to Tax Report and visualize the Annual Tax Report (IT)
3. Go to VF VAT Report
4. See the VF25 is mixing taxes and balances

### Cause of the issue:
The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24).
https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299

It's just a typo in this commit: https://github.com/odoo/odoo/pull/164064/changes/f292ba119d6376dbfb3c1fac4960c9c56a74d938

### Reason to introduce the fix:
From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : 

> Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13.

opw-6172791

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

Forward-Port-Of: odoo/odoo#264379

When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.

`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.

The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.

The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.

Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown

=> Archived teams appear in the dropdown

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

Forward-Port-Of: odoo/odoo#261300

Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
    - Kit bom
    - Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery

> Error message: "You are trying to reconcile some entries that are already reconciled."

/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.

Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.

When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.

However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.

Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.

This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.

https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225

-----
Ticket:
opw-5722072

Forward-Port-Of: odoo/odoo#263418
Forward-Port-Of: odoo/odoo#258013

Cause:
======
Commit [1] kept model-required fields enabled when conditionally hidden so their default value is still submitted (needed e.g. for the "Create an Opportunity" action where the Subject field has to reach the server).

The Subject field of the "Send an Email" form was incorrectly flagged as `modelRequired`, but `mail.mail.subject` is not actually required on the server. As a side effect of the above commit, hiding the Subject field through visibility conditions left the empty input enabled, which then triggered the client-side "Please fill in the form correctly" error (when no default value was set) or sent an empty subject.

Solution:
=========
Mark the field as `required` instead of `modelRequired`: it stays required for the user when visible, but when conditionally hidden it is disabled like any other non-model-required field and excluded from submission.

Steps to reproduce:
===================
1. Drop a Form snippet on a page (default action: Send an Email).
2. Edit the Subject field, set a visibility condition that is not met.
3. Save and submit the form.

=> "Please fill in the form correctly".

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

opw-6199682

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

**Steps to reproduce:**
- Accounting > Configuration > Settings > Default Accounts > Product Accounts
- Change the default expense account (and income account)
- Create a new product category
- category still proposed the old accounts

Affected versions: from 18.2 till 19.2

**Cause:**
`ir.default` for `product.category` (`property_account_expense_categ_id` and `property_account_income_categ_id`) was not updated when `res.company.expense_account_id` / `income_account_id` changed, so new categories kept using stale defaults.

and in 19.0
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L490
and
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L753
calls
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L1136-L1139

However, when stock_account is installed

https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/stock_account/models/res_company.py#L361-L366

this gets called, without calling super, that's why it didn't work although the fix is there, we will need to adapt another fix in 19.0+

**Solution:**
Call `_set_category_defaults()` in `res.company.write()` so `ir.default` stays aligned with the company's current product default accounts.

opw-6145491

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

Forward-Port-Of: odoo/odoo#261594

### Issue before this commit:
In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Go to Tax Report and visualize the Annual Tax Report (IT)
3. Go to VF VAT Report
4. See the VF25 is mixing taxes and balances

### Cause of the issue:
The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24).
https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299

It's just a typo in this commit: https://github.com/odoo/odoo/pull/164064/changes/f292ba119d6376dbfb3c1fac4960c9c56a74d938

### Reason to introduce the fix:
From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : 

> Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13.

opw-6172791

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

Forward-Port-Of: odoo/odoo#264379

## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#263792

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

[ADD] l10n_om_hr_payroll: base setup for Oman payroll localization
[ADD] l10n_om_hr_payroll: accrual plan, SPF, Overtime, & EOS salary rules

Introduce the foundational setup for the Oman payroll localization based on Oman's Labor Law. This serves as the base for subsequent enhancements and related tasks.
The setup includes demo data, a standard working schedule, and an Omani salary structure with standard and specific rules aligned with local requirements.

The goal of this change is to establish an initial framework for the Omani localization, enabling consistent development and functional testing. Providing demo data for the company and employees facilitates immediate use and demonstration of payroll features, while the defined 9–5 working schedule (Sunday–Thursday, Asia/Oman timezone) reflects local business practices.

Technical summary:
- **Added demo company:** “My Omani Company”.
- **Added demo employees:** Linked to the company with localized education and contract data.
- **Defined standard working schedule:** (9:00–17:00, split morning/afternoon, Sunday–Thursday, Asia/Oman timezone).
- **Introduced salary structure “Oman: Monthly Pay”:** Includes standard salary rules and the following additions:
    - **Bonus:** Added as an Other Input.
    - **Other Allowance:** Salary input at employee level with a corresponding rule under category “Allowances”.
    - **Total Wage:** New parent category grouping “Allowances” and “Basic Salary”.
    - **Expenses Reimbursement:** Added as an Other Input.
    - **Renamed “Taxable Salary” to “Gross”:** To align with local terminology.
- **Social Protection Fund (SPF):** Added fields and logic for Employee and Employer contributions covering Old Age, Disability and Death , Unemployment, Work Injury, Sick Leave, and Maternity.
- **End of Service (EOS):** Introduced an EOS eligibility toggle on the employee record and a "Provision Payout" salary rule category.
- **Leave Accrual:** Added an "Oman Employee Plan" with a monthly accrual of and annual sick leaves.
- **Overtime Rules:** Defined rules for Daytime, Nighttime, and Rest Day overtime within the attendance and work entry.

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

**Container, Mixin & Generation**
* 281_xx is now the single entry point for all 281.xx reports.
* Introduced a shared mixin (`l10n_be.281.mixin`) to centralize common logic (employee validation, payslip filtering) and enforce a standard structure across all 281.xx forms.
* Child reports (281.10, 281.45) are systematically created and linked to the container.
* Forms are only generated for employees who require them (e.g., skipping 281.45 if the employee has no IP).
* XML generation is centralized at the container level: subreports provide data, while the container defines header-level information.
* Record names are adapted to include the year and a suffix sequence (e.g., `YEAR_281_suffix`).

**UI & View Simplification**
* Removed dedicated 281.10 and 281.45 form views, consolidating them into a unified container using tabs instead of smart buttons.
* Updated list view to display the year as the first column, and expose reference, form types, sending type, treatment type, and state.
* Introduced a shared employee declaration list view used across all 281 report types.

**Sequence, Error Handling & Finalization**
* The container holds the state (Draft, Error, Ready, Done). Draft state allows generating test XML; Ready state corresponds to final XML.
* Validation errors from subreports are aggregated and set the container to an "Error" state, blocking the XML generation.
* Confirmation wizard sets the final Belcotax reference, triggers the PDF generation, and sends the documents to the employees.

Task: 5911065

*=l10n_eu_oss_reports

This commit introduces the VAT Control Statement report (Kontrolný výkaz DPH)
as required by the Slovak Financial Administration.

The report covers all eight sections of the KVDPH:
- A.1: standard issued invoices to registered entities
- A.2: domestic reverse-charge sales (§69) with commodity codes
- B.1: reverse-charge purchases (EU acquisitions, triangular, imports)
- B.2: standard domestic purchases with VAT deduction
- B.3.1/B.3.2: simplified invoices (split by €3,000 threshold)
- C.1/C.2: corrections to issued/received supplies (credit & debit notes)
- D.1/D.2: e-KASA aggregates and other supplies (manual entry)

Each section uses a custom SQL engine that handles grouping by move,
partner, tax rate, and commodity tag depending on the section context.
Sections A.2 and C.1 resolve product commodity codes (TK) and goods
types (TD) from account tags defined in XML data.

Also adds:
- XML export following the KVDPH_2025 XSD schema
- `l10n_sk_is_bad_debt` field on `account.move` for bad debt flagging
- `l10n_sk_uom` selection on account.move.line for KVDPH unit of measure
- product tag data for 54 commodity codes and 2 goods types
- views to expose the new fields on invoices, journal items and products
- Added dedicated return type and submission wizard with direct XML download

Documentation: https://www.financnasprava.sk/sk/podnikatelia/dane/dan-z-pridanej-hodnoty/kontrolny-vykaz-dph

Related: https://github.com/odoo/odoo/pull/241860
Related: https://github.com/odoo/upgrade/pull/9102

task-5213902

Problem: When opening the Studio XML editor when Website is installed, the
translation terms corresponding to the Default Language of the first
website in the database are used. This behavior should only be applied
to the HTML/CSS Editor in Website.

Purpose: Modify Website's override of get_related_views to only return
translated views when called with a specific website in context.
This is done here by adding a context flag, as to not interfere with
customizations made in stable versions. This will be changed for master.

Steps to Reproduce in Runbot:

1. Activate a non-English (US) language.
2. Add this language to the Website with the lowest ID in the database,
then set it to the Default Language of the Website.
3. While in debug mode, enter Studio and navigate to a view that has
   translation terms (ex. Sale Order Form view), then open the XML
editor.

opw-5136124

Foward Port of https://github.com/odoo/enterprise/pull/110418

Forward-Port-Of: odoo/enterprise#116771

Implement the Belgian Registered Cash Register (Caisse Enregistreuse Certifiée) v2 specification as required by FPS Finance for certified POS restaurant systems.

The implementation is split into a core module and five bridge modules:

l10n_be_pos_blackbox (main module):
- FDM (Fiscal Data Module) communication layer that signs every fiscal
  event by sending a structured message to the blackbox device and
  receiving a hash + VSC counter in return.
  M110 (sale), M111 (refund), M112 (partial refund), M121 (order),
  M122 (cost-centre change), M123 (pre-bill), M130 (money in/out),
  M131 (drawer open), M140/M141 (work in/out), M150 (invoice),
  M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z
  report), UC230 (sale correction).
  M160 (copy), M180/M181 (X/Z turnover report), M182/M183 (user X/Z
  report), UC230 (sale correction).
- Input generator that encodes all line-level fiscal data (PLU hash,
  VAT groups, price rounding, grouping IDs) according to the spec.
- Fiscal receipt template (XML) that renders the blackbox hash,
  VSC counter, POS system identifier, and event sequence number on
  every printed receipt.
- X/Z daily report views with fiscal totals per VAT category.
- Training-mode support: activates the FDM training flag so the
  device does not count test transactions.
- Inspect popup (debug) for examining raw FDM messages.
- Error/warning popup system with traceback messages from the device.
- LocalStorage queue to replay pending mutations after a network
  outage.
- pos_config / pos_session overrides: enforce blackbox constraints
  (only EUR, no rounding, mandatory restaurant mode, etc.),
  manage device pairing, and accumulate per-session fiscal counters.
- Extensive unit-test suite: >6 000 lines covering the input
  generator's grouping-ID logic, price-consistency rules, and every
  mutation type against golden JSON fixtures.
- Browser tour tests (oracle + regression tours).

l10n_be_pos_blackbox_hr:
- Clock-in / clock-out flows for employees trigger M140/M141 work
  in/out mutations; employee INSZ/NISS number is required and stored
  on hr.employee; pos_session accumulates per-employee work records.

l10n_be_pos_blackbox_loyalty:
- Gift-card and discount reward lines are mapped to the correct MPV
  fiscal codes (UC260/UC261); loyalty products are flagged so the
  input generator can calculate their contribution to the signed
  total correctly.

l10n_be_pos_blackbox_self_order:
- Intercepts self-order confirmation on kiosk screens to sign the
  order with the FDM before the confirmation page is shown; adds a
  controller to expose the required blackbox data to the kiosk
  frontend.

l10n_be_pos_blackbox_settle_due:
- Handles the "settle due" payment flow: products used to represent
  deferred payments are flagged and treated as zero-VAT lines in the
  signed message.

l10n_be_pos_blackbox_urban_piper:
- Patches the Urban Piper ticket-screen and pos_store so that online
  orders routed through Urban Piper are also signed before finalisation.

task-id: 5864870

community PR: https://github.com/odoo/odoo/pull/229692

Steps to reproduce
1. Create a Combo Product with some combo items.
2. Open Odoo on a mobile device or simulate mobile view (isSmall=true).
3. Create a new Quotation and add the Combo Product via the "Add product"
   button in the order lines kanban.

Issue
The combo product is added directly to the order lines with a price of
0.00, and the Combo Configurator dialog never opens.

On mobile, the 'product_id' field in the 'sale.order.line' inline form
view uses the generic 'many2one_barcode' widget. This widget is a
standard Many2one with barcode support but lacks the specific logic in
'SaleOrderLineProductField'
(https://github.com/odoo/odoo/blob/d1ab74aebc356537dd2a7df43fb40150580802ea/addons/sale/static/src/js/sale_product_field.js#L74-L92)
that detects combo/configurable products and opens the appropriate
configurator dialog. On desktop, the 'sol_product_many2one' widget
handles this, but it was not used on mobile because it lacks barcode
scanning features.

Solution
The inline form view now uses 'sol_product_many2one' with
options="{'can_scan_barcode': True}" instead of 'many2one_barcode'.
This leverages the existing 'can_scan_barcode' option on Many2OneField
(https://github.com/odoo/odoo/blob/7ba46d2cea7f522e17ffe04c4051469fb0320a76/addons/web/static/src/views/fields/many2one/many2one_field.js#L390),
giving the field both configurator logic and barcode support. The fields
needed for combo state ('selected_combo_items', 'virtual_id') are also
added to the mobile views.

opw-6062731

Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)

Those colors are a bit special (see full discussion on the opw)

    Their existence is described in module web
    Their CSS definition is implemented in module html_editor
    Reports don't use them at all We probably don't want reports' style
    to be influenced by the presence or lack thereof of the html_editor
    module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

see odoo/odoo#251446
backport of https://github.com/odoo/enterprise/pull/109206
opw-6167143


community: https://github.com/odoo/odoo/pull/264917

## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#263792

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118