**Steps to reproduce:**
* Install the **account** and **fleet** modules.
* Create a vendor bill with two expense lines using the same tax.
* Assign a vehicle_id to one line but leave the other without a vehicle.
* Confirm the vendor bill.
* Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report.

**Observed behavior:**
* The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.'

**Cause:**
* The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`.
* When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`.
* The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency.

**Fix:**
* Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set.
* If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines.

opw-5956645

Forward-Port-Of: odoo/enterprise#112313
Forward-Port-Of: odoo/enterprise#110616

Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.

Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
    - Enable Lots/Serial Numbers > Create New
- Create a product
    - Barcode 23456789012344
    - Tracked by SN
    - 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details

> The line used the reserved SN

Cause
-----
The existing line gets matched in `_findLine`

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085

because none of the conditions before

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402

get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.

Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).

-----
Ticket:
opw-5216921

Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671

Steps to reproduce:
1. Create a new SO/PO/Invoice and add a product.
2. Add a new section below the product.
3. Open the catalog and click the Remove button for the added product.

Issue:
- The product is not removed from the SO/PO/Invoice.

Cause:
- When removing the product, the 'No section' entry is also removed if it becomes empty.
- As a result, `this.env.searchModel.selectedSection.sectionId` point to the first remaining section in the order.
- Because of this incorrect reference, the wrong `section_id` is passed in the params, and `update_order_line_info` does not update the intended order line.

Fix:
- Use `this.env.selectedSectionId` instead of `searchModel.selectedSection.sectionId` to ensure the correct `section_id` is always passed.

After applying this fix, `test_catalog_vendor_uom` tour was failing because in tour execution the kanban records are mounted before the search panel finishes initializing the selected section. As a result, the initial section state is not yet stabilized when the price is asserted.

To address this:
- Update the tour to explicitly wait until the "No section" entry is marked as selected in the search panel before asserting      the product price, ensuring the catalog is fully initialized.

opw-5960140

Forward-Port-Of: odoo/odoo#250103

**Description of the issue this PR addresses:**
Ensure the `Looking for Help` timer is shown even when the current 
user is already a member of the livechat channel.

**Steps to Reproduce:**
1. Log in as a visitor and as Mitchell Admin (Live Chat operator).
2. From the visitor side, select I have a pricing question.
3. From the admin side, mark the conversation as Looking for Help.
4. The channel appears in the Looking for Help category.
5. Observe that the timer should be visible there (e.g., 1m).

**Current behavior before PR:**
- The timer was hidden when an agent was already a member of the 
conversation, assuming that once an agent joined, the `waiting for help` 
phase was over.

- However, in escalation workflows an analyst may escalate a chat and 
remain a member while the channel returns to the `Looking for Help` 
state for another expert. In this case, the escalating analyst could not 
see the timer needed to track SLA requirements (e.g., creating a 
ticket after 10 minutes).

- Also, the mock server did not recompute
`livechat_looking_for_help_since_dt` when `livechat_status`
changes, leading to incorrect timer values (e.g., showing 2d
instead of < 1m after switching back to Looking for Help).

**Desired behavior after PR is merged:**

- The timer is displayed whenever the channel is in `need_help` 
and `livechat_looking_for_help_since_dt` is set, regardless of 
whether the current user is a member of the channel.
- The mock server now mirrors server-side behavior by updating
`livechat_looking_for_help_since_dt` when livechat_status changes,
prevents missing recomputations and ensuring consistent test
behavior.

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


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

Forward-Port-Of: odoo/odoo#252738

### Issue before this commit:
When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report.

### Steps to reproduce the issue:
1. Create a sales order for product A
2. Deliver product A
3. Create invoice
4. Create credit note by clicking on "Reverse and create invoice"
5. The new invoice correctly remains linked to the Sales order
6. However, the source document disapear on the PDF

### Cause of the issue:
In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked.

### Reason to introduce the fix:
To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF.

opw-6034574

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

Forward-Port-Of: odoo/odoo#256284
Forward-Port-Of: odoo/odoo#254290

## Short functional explanation of the error
When in settings, we click on Manage users, we sometimes get a validation error.

## Reproduction Steps
1. Go to settings.
2. Click on Manage Users.

### Expected behavior
The list of users is displayed.

### Unexpected behavior
Sometimes (around 20% of the time), we get the error:
```
Validation Error

The operation cannot be completed: A user cannot be linked to
multiple employees in the same company.
```

## Origin of the issue
This validation error is triggered due to a psycopg2 constraint error. Indeed, it occurs because the code tries to create an employee for the current user, when an employee for this user already exists:
https://github.com/odoo/odoo/blob/35da8c4d8e86a752cc76d275463a752039465984/addons/pos_hr/models/pos_config.py#L27-L30 In our case, the `group_users` only contains the admin user. This user has an existing corresponding employee in the field `employee_ids`, but not in `employee_id`.

__
opw-6066533






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

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/5416006

Issue:
If a database has products that use the average cost method, and those products have millions of stock moves, a memory error can occur when the inventory valuation report is opened.

Explanation:
When the inventory valuation report is opened, the `_run_average_batch` method is invoked on batches of up to 1000 AVCO products at a time. Previously, all matching stock moves for those products were fetched in a single query and kept in cache for the duration of the computation. For large databases, even a single invocation of `_run_average_batch` can exhaust available memory if the products involved have enough stock moves.

Solution:
Moves are now fetched and processed in batches of 50,000 records, with the cache for `stock.move` and `stock.move.line` invalidated between each batch.

For memory:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 280 MB | 274 MB |
| 500 products with 535,250 moves | 983 MB | 301 MB |
| 500 products with 912,405 moves | 1.7 GB | 337 MB |
| 1000 products with 1,447,655 moves | Mem error | 393 MB |

For speed (in m:ss):
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 0:15 | 0:16 |
| 500 products with 535,250 moves | 1:12 | 1:17 |
| 500 products with 912,405 moves | 2:02 | 2:10 |
| 1000 products with 1,447,655 moves | N/A | 3:53 |

opw-5416006

Co-authored by Cooper Spinelli (spco)

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

Forward-Port-Of: odoo/odoo#250526

Step to reproduce:
- setup Restaurant and do the following config
- set "self-ordering" -> "Qr Menu + Ordering"
- set "service At" -> "pickup zone"
- save and print the qr-code ( option is right there below these configs)

Observation:
- in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be.
- QRs do not have table_id

Cause:
- there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone"

Fix:
- we only use table_id when ordering_mode = 'table'.

**Before:** 
<img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" />


**After**
<img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" />


opw-5095607


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

Forward-Port-Of: odoo/odoo#254897
Forward-Port-Of: odoo/odoo#247184

**Issue**:
Billing a PO containing kit with several components can lead to incorrect
valuation of its components

**Steps to reproduce**:
- Create a kit product (by creating a BOM with 2 components) with AVCO valuation
- Create a PO for 1 unit at unit price 10
- Confirm PO and validate the receipt
- Go to the BOM of the kit product and check BOM overview
-> The cost of the two components are 5, which is correct
- Go to Accounting > Vendors > Bill
- Create a new bill by indicating the PO in "Auto-Complete" field and validate
- Go back to the BOM of the kit product and check BOM overview
-> The cost of the two components are 10, which is correct

This also occurs with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314
It checks the value of the Bill:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358
Which relies directly on the AML price of the kit:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170
This ignores the `cost_share` of each BOM component. As a result,
each component receives the full kit value instead of its proportional
share

This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

**Aditionnal note**
The computation of the quantity is also incorrect:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169
since it assumes the quantity of component of the kit is the same than the quantity of the kit itself,
which is not true in the general case.

opw-5924940

Forward-Port-Of: odoo/odoo#252246
Forward-Port-Of: odoo/odoo#249264

Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red.

The color should be the same as the one from "disconnect", but the difference comes from `btn-danger` with or without `.active` that has different shade of red for background: the `.active` version is lighter like in the mute button when active.

`.active` classname is preferred to keep so that the visual is consistent for most discuss actions, including the ones without success / danger which a majority of these buttons have. However, the buttons with danger / success style are intended to preserve their color unchanged as the `.active` aspect is meant to tell whether the button is active or not and the slight change of color shade is not desirable in the context of discuss action list.

This commit uses the same background color for danger / success / primary inline button. Other styles line dropdown and inline buttons without background had already the same colors, so this commit fixes the only case that was missing.

Task-5436990

Before / After

<img width="283" height="38" alt="Screenshot 2026-03-13 at 15 21 22" src="https://github.com/user-attachments/assets/3ebba48c-5b22-43e9-a915-e18a5531e660" /> <img width="270" height="41" alt="Screenshot 2026-03-13 at 15 21 45" src="https://github.com/user-attachments/assets/586d05a4-2a6c-48e0-89c6-bffa85a86e59" />

Forward-Port-Of: odoo/odoo#255282
Forward-Port-Of: odoo/odoo#253923

Versions
--------
- 19.0+

Steps
-----
- Log in on the portal
- Go to "My Account"
- Go to "Addresses"
- In the billing section uncheck "Same as delivery address"
- In the billing section click "Add Address"
- Fill in address details
- Click "Save Address"

Issue
-----
The newly added address is visible in both the delivery and billing sections, and in the backend the address has type "other" instead of "invoice".

Cause
-----
This happens because the "Add Address" url in the billing section contains the parameter `use_delivery_as_billing=True`, which supersedes the parameter `address_type=billing`, creating an address with type "other". This is because the "Add Address" url in the billing section is not dynamically updated when the "Same as delivery address" toggle is toggled like with the url in the delivery section.

Solution
--------
The `use_delivery_as_billing` is completely removed from the url in the billing section, because the button only appears when the toggle is unchecked (i.e. when `use_delivery_as_billing=false`). And by not sending the parameter, it defaults to false in the backend.

opw-5880430

Forward-Port-Of: odoo/odoo#256326