**Steps to reproduce on a new db:**
(bug also reproducable on runbot but the impact 
is less easy to compute because of influence of other
existing companies)

- create a new company as company 2 and use the existing 
default company as company 1.
- create a warehouse for both company
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).
- for both comp, in settings for inventory valuation set 
'periodic' and for periodic valuation set 'daily'

From company 1 : 
- create a storable product with standard price method and 
set a cost of 30
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 30 
  - the variation lines have a balance of 30
  - all of this is expected

From company 2 :
- change the cost of the product to 10
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 10 
  - the variation lines have a balance of 10
  - all of this is expected
 
From any company :
- navigate to 'scheduled actions' and select the action 
'Stock Account: Inventory Valuation Closing'
- click on 'Run Manually'
- navigate to 'inventory valuation'

**Current behavior:**
with company 1 selected :
  - the initial balance is now 30 
  - ending stock still 30
  - no variation lines
  - the initial balance was correctly increased by the closing entry

with company 2 selected: 
  - the initial balance is now 40
  - the ending stock is still 10
  - the variation lines credit 30 in stock valuation

In company 2 the closing entry debitted 40 in stock valuation 
instead of 10 which increased the initial balance to 40 instead of 10

If you open the journal items you'll find the closing amls have a 
balance of 40 instead of 10

**Cause of the issue:**
The _cron_post_stock_valuation() method 
calls action_close_stock_valuation() on both companies
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L143-L144

This methods calls _action_close_stock_valuation
with a context modified with only self.env.company.ids
in 'allowed_company_ids'
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L56

This is needed because inside stock_value() we use 
the total value of the product 
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L92
which will be the sum of the values of the product 
for each company inside allowed_company_id
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/product.py#L274
So in case action_close_stock_valuation() was called from 
the 'generate entry' button from the inventory valuation view
we need only the main company selected to be in the
'allowed_company_ids' so that the inventory value is computed 
based only on this company (as is the accounting value).

The problem is that this does not work when calling the 
method from _cron_post_stock_valuation because then
there is no 'allowed_company_ids' in the context (because it was
called from _process_job() with a new env).
so self.env.company will be the company of the user 
which will be company 1.
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/odoo/orm/environments.py#L243

Therefore when _action_close_stock_valuation will be 
called on company 2, in the context, allowed_company_ids 
will be company 1. Then, when computing 'products', with_company() 
will add self (company 2) to the context.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L151-L152
So stock_value will return the sum of the total_value 
of each product for company 1 and company 2 which is 40 (instead 
of 10 for just company 2)
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L242

We then create the closing accounting entry to match the 
accounting value with the stock value, which explains why 
the new initial accounting balance of company 2 is 40.

**fix:**
We set the context using self instead of self.env.companies
This makes more sense as both in the cron use case and 
the generate entry use case the stock value we want is the 
one of the company in self. 
- In cron use case, it's obvious as the method is called 
in a for loop on each company
- In the generate entry use case, self will also be the main 
company, because it's called, in actionGenerateEntry, 
on this.companyId 
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L75
which is computed based on the get_report_values
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L21
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L28-L30
Which returns the main company
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/report/stock_valuation_report.py#L29


Most importantly, this is also aligned with how the accounting 
values are computed.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L103-L105


opw-6237402

Forward-Port-Of: odoo/odoo#269152
Forward-Port-Of: odoo/odoo#266932

Steps to reproduce:
1. Install Knowledge.
2. Create an article.
3. Open the more actions menu.
4. Click "Add Cover".
5. Upload a cover image.

Issue:
- The upload crashes with the following traceback:
`Uncaught Promise > this.props.setAbortUploadsCallback is not a function`

Cause:
- `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop.

Solution:
- Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded.

Alternative approach: 
- Make ImageSelector tolerate callers that do not provide
  setAbortUploadsCallback by calling it with optional chaining.

opw-6176716

Forward-Port-Of: odoo/enterprise#120467
Forward-Port-Of: odoo/enterprise#116906

When setting the done state on an already done WO, a traceback is raised.

Steps to reproduce the error:

- Install ``mrp_workorder`` module with demo data
- Go to Manufacturing > Open any confirmed MO >
  In Work Orders Tab, Set the status to Done, again set the status to Done

Traceback:
```py
UnboundLocalError:
cannot access local variable 'wo' where it is not associated with a value
```

As long as the MO is not in the done state,
the dropdown for the workorder status remains visible,
allowing users to mark an already done WO as done again.
In this case, the WO is not added to "ids_to_update" list at [1],
so ``action_mark_as_done`` is called on an empty workorder recordset at [2],
For ``self`` containing no records, ``wo`` is never defined,
leading to the above traceback from the following line. https://github.com/odoo/enterprise/blob/3c4f44f316625f3315d176adfad5e1f1a6bea00a/mrp_workorder/models/mrp_workorder.py#L842

[1]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L168-L176
[2]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L184-L185

sentry-7477198216

When setting the done state on an already done WO, a traceback is raised.

Steps to reproduce the error:
- Install ``mrp_workorder`` module with demo data
- Go to Manufacturing > Open any confirmed MO >
  In Work Orders Tab, Set the status to Done, again set the status to Done

Traceback:
```py
UnboundLocalError:
cannot access local variable 'wo' where it is not associated with a value
```

https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/static/src/components/wo_list_view_dropdown/wo_list_view_dropdown.xml#L4-L5
In the commit [1], condition was changed from ``state`` to ``production_state``.
``production_state`` is the related to the state of MO,
So, as long as the MO is not in the ``done`` state, the dropdown remains visible,
allowing users to mark an already done WO as done again.
In this case, the WO is not added to ``ids_to_update`` list at [2].
so ``action_mark_as_done`` is called on an empty workorder recordset at [3],
leading to the above traceback from following line https://github.com/odoo/enterprise/blob/3c4f44f316625f3315d176adfad5e1f1a6bea00a/mrp_workorder/models/mrp_workorder.py#L842

[1]: https://github.com/odoo/odoo/commit/5b1197647b558eacd501fdd816056cfd56f45ced
[2]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L168-L176
[3]: https://github.com/odoo/odoo/blob/afca863b750ec58f5414a5d47e2e2a64e3eba598/addons/mrp/models/mrp_workorder.py#L184-L185

sentry-7477198216

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

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

This commit ensures product images follow their visual order in the
product image viewer when using the grid layout.

Steps to reproduce:
- Open a product page with multiple images (or add Extra Media to the 
  product)
- Change layout mode to "Grid" and click save
- Click any image to open the product image viewer
- Navigate between images

Images do not follow the visual left-to-right order. This regression was
introduced by [commit], which replaced the row-based grid with a
column-first layout. As a result, `querySelectorAll` returns images in
DOM order, which no longer matches the visual order.

To fix this, images are now reordered based on their visual placement in
the grid so navigation matches the order seen by the user. Images are
traversed in visual left-to-right order while also accounting for
varying image heights and multi-column alignment.

[commit]: https://github.com/odoo/odoo/commit/9a3628b9735550bf8ecc2252ea1b7338f68ab966
task-[4364143](https://www.odoo.com/odoo/project/974/tasks/4364143)

Forward-Port-Of: odoo/odoo#270732
Forward-Port-Of: odoo/odoo#254077

**Steps to reproduce:**
* Install the **l10n_cl_edi** module.
* Go to **Accounting → Configuration → CAFs**, create a new CAF, and upload a valid CAF [XML](https://www.odoo.com/mail/message/1097235975) file.
* Create a new **Purchase Journal** with **Use Documents** enabled.
* Create a vendor bill using this journal.
* Set the **Document Type** to **46 - Liquidación-Factura Electrónica**.
* Confirm the vendor bill.

**Observed behavior:**
* The Send button is not visible on the confirmed vendor bill despite the DTE being generated and `l10n_cl_dte_status` being set to `not_sent`.

**Cause:**
* `_compute_display_send_button` in `account` only returns `True` for sale documents (`is_sale_document()`), so the "Send" button — which opens the Send & Print dialog containing the "Send to SII" option — was never shown on vendor bills.
* `_get_move_constraints` in `account.move.send` unconditionally adds a `not_sale_document` constraint for non-sale documents, blocking the Send & Print dialog from processing vendor bills even if the button were visible.
* The cron's `cron_run_sii_workflow` only processes moves with `l10n_cl_dte_status = 'ask_for_status'`, skipping moves still in `not_sent` state.

**Fix:**
* Override `_compute_display_send_button` in `l10n_cl_edi` to also show the "Send" button on posted moves with `l10n_cl_dte_status == 'not_sent'`, matching the pattern used by `l10n_br_edi`.
* Override `_get_move_constraints` in `l10n_cl_edi` to remove the `not_sale_document` constraint for Chilean purchase documents with `not_sent` status, matching the pattern used by `l10n_br_edi`.

**REF**
 During this [refactor](https://github.com/odoo/enterprise/pull/103427/changes/f5617ecf7584cf019897408df94b002622f48d9d), these two methods were inadvertently missed and were not overridden 

opw-6300571

Forward-Port-Of: odoo/enterprise#120818

# How to reproduce
- Create an Event registration
- Add a follower
- Click on the enveloppe icon next to the sender's name in the chatter

# The problem
A traceback appears

# Cause of the issue
When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105

But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing :
https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27

opw-6178443

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

Forward-Port-Of: odoo/odoo#265263

When moving an order (Order A) to a table that already has an order (Order B), the merged order only reprints Order B's products. The products from Order A are missing from the preparation reprint.

Steps to reproduce:
-------------------
* Open a POS session on a Restaurant POS
* Create an order (Order A) for Table 1
* Create a second order (Order B) for Table 2
* Transfer/Merge Order A to Table 2
* Reprint the preparation order

> Observation:
Only the products that were already on Table 2 (Order B) appear on the reprint. Products from Order A are missing.

Why the fix:
------------
mergeOrders correctly transfers kitchen history
(last_order_preparation_change.lines) via handlePreparationHistory, but does not update uiState.lastPrints on the destination order. The reprint button uses lastPrints.at(-1) when there are no pending changes, so it only shows the destination order's last print batch — ignoring the merged lines entirely.

Implementation:
After the merge loop, build a consolidated lastPrints entry from the destination order's last_order_preparation_change.lines (which now contains lines from both orders) and push it onto
destOrder.uiState.lastPrints so that reprint reflects the full merged state.

opw-6060684

Forward-Port-Of: odoo/odoo#270311
Forward-Port-Of: odoo/odoo#256309

*= website_partnership, website_crm_partner_assign 

Currently, an error occurs when users try to access the `/partners` website
page after upgrading database to saas-19.2.

This issue occurs because recent changes introduced in PR [1] added a new
template as id `index_layout`. Inside this template, a `t-call` element was
using a nested `t-set` element to define `additional_title`. We were
referencing this `t-set` element in the XPath of the `index` template to
override the value of `additional_title`.

However, recent changes removed the `t-set` from the `t-call` and replaced
it with a direct variable assignment inside the `t-call`. During the upgrade,
the migration script automatically moves the `additional_title` attribute
into `t-call` and removes the `t-set` from the `t-call` (see the script and
related changes in [2]).

As a result, the XPath expression that targets the `t-set` element fails because
the referenced element no longer exists, which causes the error.

This commit fixes the above issue by adapting the `t-call` element to match
the recent changes introduced in [2]. Instead of relying on a nested `t-set`
element, it now uses the variable directly as an attribute within the
`t-call`, and updates the corresponding attribute child accordingly.


[1]: https://github.com/odoo/odoo/commit/711c3baad58f3e0f1dc39cb90eb8176aba91e9dd
[2]: https://github.com/odoo/odoo/pull/235469/changes#diff-29ae6f0bcf846a2fcaffc38fdd0d3b19ea328c133ff4dfe18cc9725715f34dd9


sentry-7400315548

### **Issue**

Self-orders created through the mobile QR menu or kiosk were not displaying table information in the Order Info section of the payment screen.

### **Root Cause**

The Order Details dialog relied on `order.getTable()` to retrieve table information. However, self-orders only store the table reference through `table_id`, which was not properly handled when rendering the dialog, resulting in missing table information.

### **Solution**

This PR introduces the following changes:

* Add a dedicated `getTableInfo()` helper in `pos_restaurant` to retrieve table information from the order.
* Use `getTableInfo()` when building the Order Details dialog fields.
* Allow self-order flows to provide table information through `table_id`, ensuring table details are displayed correctly.

### **Steps to Reproduce**

1. Enable the following options in POS Configuration:

   * QR Menu & Ordering
   * Service at Table
   * Online Payment
2. Open a self-order from the mobile QR menu
3. Select a table and complete the payment
4. Open the POS session
5. Open the paid self-order
6. Click the **Details** button on the right side

### **Video Reproduction**

https://drive.google.com/file/d/138AoJCTF1HNlCGFgk9BRTb0UTai-uXX7/view?usp=sharing

### **Before**

Table information was not displayed in the **Order Info** section for self-orders.

### **After**

Table information is now correctly displayed for self-orders.


opw-6179516


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

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

Version:
- 19.0

Steps to reproduce:
- Create a sign template with a readonly sign item linked to an auto field.
- Use a reference record where the linked field value is empty or False.
- Send the document for signing.
- Complete the signing flow.

Issue:
- Readonly sign items linked to auto-filled values could not properly handle
  falsy values. Empty values could trigger the error "Some required items are
  not filled" and completed sign requests displayed the sign item placeholder
  instead of the actual auto-filled value.
- completed document generation could fail when rendering falsy values for
  textarea sign items.

Cause:
- Falsy auto-filled values were ignored during constant item population and
  replaced by the sign item placeholder. Additionally, readonly constant items
  were included in required field validation and completed sign requests
  continued to display placeholders when the stored value was empty.
- document rendering assumed sign item values were always strings for textarea
  sign items but when auto field is empty it value can be False.

Fix:
- Preserve falsy values when populating readonly constant items, exclude
  constant items from signer validation, and hide placeholders for empty
  auto-filled constant items when displaying completed sign requests.
- Normalize falsy values to prevent crashes and allow completed documents
  to be generated correctly.

Forward-Port-Of: odoo/enterprise#121009

`qty_available` is by default not computed with sudo, while the `total_value` is. This means that in `_update_standard_price`, the customer configuration can have a negative impact on the standard_price compute.

For example, if a user create a custom rule so that specific users have access to specific warehouses only, compute `total_value / qty_available` can actually mean `global_total_value / partial_qty_available`, which creates an aberrant standard price.

To fix this issue, the _update_standard_price must be done in sudo.

OPW-6243363

---

## Test result without fix
```
2026-06-17 12:24:50,810 47572 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_update_standard_price_with_limited_access_users
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3624, in test_update_standard_price_with_limited_access_users
    self.assertEqual(product.standard_price, 1.0)
AssertionError: 12.11111111111111 != 1.0
 ```

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

Forward-Port-Of: odoo/odoo#270559

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

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

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

Following steps could be used to reproduce from 18.3.

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

Invoice A payment was sent twice to CFDI

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

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

opw-5432421

Forward-Port-Of: odoo/enterprise#119357

## [IMP] web_gantt: allow setting conditions to display buffer times
This commit allows children to conditionally display buffer times in the
Gantt view.

This is particularly important for Field Service, where buffers do not
make sense if the view is not grouped by resource.

## [IMP] web_gantt: editable specification for get_gantt_data rpc
This commit allows views inheriting from `GanttModel` to modify the
specification passed to the `get_gantt_data` rpc call.

This will become handy for Field Service, where we want to read extra
fields (other than `display_name`) for partners.

## [IMP] planning: check user group before loading data
This commit ensures that the `isManager` boolean value is always fetched
before loading the Gantt view.

## [IMP] planning_field_service: travel time computation in the Gantt view
This commit introduces travel time and distance tracking for field
service shifts. Travel times displayed as buffers on the day-scale gantt
view when grouped by resource.

- Add `travel_time_in/out` and `travel_distance_in/out` fields on
planning slots
- Travel data is reset automatically when the partner, resource, or
datetime changes, and preserved when splitting/undoing splits or undoing
drag-and-drop
- Compute routes using MapBox on gantt load (when all records are stale)
or on demand via a toolbar button (when some are stale)`
- The travel data are computed starting and ending at the resource's
work location (i.e., work, daily interventions, work)
- Hide the buffer-end visually when a subsequent shift exists for the
same resource

## [IMP] planning_field_service: add travel time and distance popover in gantt
This commit adds a popover containing the travel time information for
the intervention, when hovering its buffer time.

It contains the departure time, travel time, and distance. If there is
no previous intervention, the information is relative to the resource's
work location.

task-6200248

Steps to produce:
---
- Install the `Rental` and `Subscription` modules.
- Create a rental product and a subscription product.
- Create a sales order containing both products and set a rental period.
- Confirm the sales order.

Issue:
---
- The rental status badge overlaps the subscription status badge.

Root cause:
---
- The rental status badge uses the position-absolute CSS class to place it at the end of the header. When the subscription status badge is also displayed in the same area, both badges are positioned at the same location, causing them to overlap.
- After [commit], this issue is introduced.

Solution:
---
- Replace position-absolute with float-end so the badges remain right-aligned without overlapping.

[commit]: https://github.com/odoo/enterprise/commit/32ab15dc1f26af0e3d510ec859b1ec428068e9b5

Before:
---
<img width="122" height="64" alt="image" src="https://github.com/user-attachments/assets/e6b47c9e-ed59-4a4b-a95c-0318cc43660e" />

After:
---
<img width="175" height="57" alt="image" src="https://github.com/user-attachments/assets/ea98f7a1-67f6-4b2b-b699-1f2cd3376d8f" />

opw-6295212
---

Forward-Port-Of: odoo/enterprise#120660

## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />

## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
    - Any name
    - Model: *Contact*
    - Rule:
        - Field to Clean: *Name (Contact)*
        - Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**

## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:

https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23

This causes the IDs to be summed up and appear in the group headers.

## After

<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />

related: https://github.com/odoo/odoo/pull/265163

opw-6166623

Forward-Port-Of: odoo/enterprise#115492

### Steps to reproduce:

- Enable `Lots & Serial Numbers` and `Packages` in the settings
- Create a product tracked by SN and add SN001 and SN002 to stock
- Create and confirm a delivery for 2 units
- Open the Barcode app and open the delivery
- Scan the product > Scan SN001
- Click `Put in Pack`

### Current behavior:

The created package is not displayed anywhere. Clicking Put in Pack again nests the package into another package without any visible indication to the user.

### Cause of the Issue:

The GroupedLineComponent cannot display neither the source or destination package:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.xml#L4-L21
However, our case the grouped line contains only a single line and prevents the users from viewing the sublines since the `Show Reserved Lots` is disabled on the operation type and only one lot (with additional demand) was scanned:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L75-L77 https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L44-L55

opw-6237834

Forward-Port-Of: odoo/enterprise#119114

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#121075
Forward-Port-Of: odoo/enterprise#119255

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `mrp`
- Create a Manufacturing Order
- In the `Work Orders` tab, add a work order with an `Expected Duration` of 15 seconds (00:15)
- Confirm the Manufacturing Order
- Start the work order timer
- Let it run for 19 seconds and pause it
- Open the Productivity report through the `external link` icon

Issue:
------
The time split between productive time and reduced-speed time is off by
one second when the elapsed duration exceeds the expected duration.

Example:
Observed:
- Fully Productive Time: 14 s
- Reduced Speed:        5 s

Expected:
- Fully Productive Time: 15 s
- Reduced Speed:        4 s

Cause:
-------
When click into `Pause` button it trigger `button_pending` -> `stop_employee` -> `_close`
In  `_close()` computes the boundary between productive and performance
time by subtracting the excess from the end
of the timer:

https://github.com/odoo/odoo/blob/b1a6682896a4f113799340a768ec2eb2b8bdc69d/addons/mrp/models/mrp_workcenter.py#L594

`wo.duration` is the sum of all productivity record durations, each
stored as `round((date_end - date_start).total_seconds() / 60, 2)`.
For 19 elapsed seconds: `round(19 / 60, 2) = 0.32` min, so:

    excess  = 0.32 - 0.25 = 0.07 min = 4.2 s
    productive_date_end = T+19s - 4.2s = T+14.8s   ← fractional second

`_compute_duration` then strips sub-second precision via
`.replace(microsecond=0)`, truncating T+14.8s to T+14s. 

https://github.com/odoo/odoo/blob/b1a6682896a4f113799340a768ec2eb2b8bdc69d/addons/mrp/models/mrp_workcenter.py#L542

As a result:
  - Record 1 (productive): T → T+14s  → 14 s = 0.23 min  (wrong)
  - Record 2 (performance): T+14s → T+19s → 5 s = 0.08 min (wrong)

The rounding of `wo.duration` from the true value (0.3166… min) to
0.32 min shifts the computed boundary by 0.8 s, which `.replace
(microsecond=0)` then truncates, silently stealing one second from
productive time and adding it to reduced-speed time.

Fix:
---
Compute the productive/performance boundary using actual elapsed seconds
instead of rounded float durations.

For the common single-timer case `remaining_expected_seconds = 0.25 * 60
= 15.0` (exact), so `productive_date_end = T+15.000000s` — no fractional
part, nothing for `.replace(microsecond=0)` to truncate.

  - Record 1 (productive): T → T+15s  → 15 s = 0.25 min  ✓
  - Record 2 (performance): T+15s → T+19s → 4 s ≈ 0.07 min ✓

The multi-timer case (e.g. pause → resume → pause) is also handled
correctly

---

opw-6302745

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

## Description of the issue/feature this PR addresses:
Setup plus video
1. Go to settings, enable "Automatic Valuation" and "Storeable Locations".
2. Navigate to Product Categories.
3. Create a new product category with the costing method Standard Price and the inventory valuation Automatic.
4. Navigate to Products, click into any product.
5. Add the new product category to this product under General Information.
6. Add any tax in the purchase tax field.
7. In the Accounting tab of the product, add any account to the Price Difference Account field.

https://drive.google.com/file/d/1i2DHEt0g9G5Edad_QB3QaFkOT49cbMAZ/view?usp=sharing

Instructions to reproduce error
1. Navigate to Purchase.
2. Add a customer, then add the configured product.
3. Add a tax to the line. Ensure that the tax and price_unit are nonzero.
4. Confirm the order.
5. Receive the product.
6. Create the bill.
7. Edit the tax on the vendor bill, then save the changes. Notice that the changes are kept.
8. Select Confirm. Notice that the changes to the tax line are not kept, and that the COGS lines appeared (with taxes applied to them).
9. Reset the bill to draft.
10. Click into the configured product and remove the product category.
11. Repeat steps 7-8 . No COGS lines, and the tax line is the manually set value.

## Current behavior before PR:
COGS lines with taxes have no net effect on any tax lines as they cancel each other out. However, their creation triggers the recalculation of all tax lines, undoing any manual adjustments to tax lines.

## Desired behavior after PR is merged:

This commit ensures that COGS lines are not considered base tax lines, so that their creation does not trigger the recalculation of other base tax lines.

opw-5387248


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

Steps to reproduce:
-------------------
- Install `purchase`, and `quality_control`
- Enable Multi-Step Routes in Inventory settings
- Create a storable product tracked by lot
- Create a Quality Point:
  - Operation Type: Internal Transfer
  - Control Per: Quantity
  - Configure a failure location
- Enable the 3-Step Incoming route for the warehouse
- Duplicate the Internal Transfer operation type and name it `Internal Transfer 2` Configure the operation types:
- Internal Transfer:   <-- this is original one
  - Source Location: WH/Input
  - Destination Location: WH/Quality Control
- Internal Transfer 2:
  - Source Location: WH/Quality Control
  - Destination Location: WH/Stock
- Open the warehouse's 3-Step Incoming route
- Locate the push/pull rule whose source location is `WH/Quality Control`
- open that and Change its operation type from internal transfer -> `Internal Transfer 2`
- Create and confirm a Purchase Order for 20 units of the product
- Open the generated receipt
- Validate 12 units using Lot-1 and create a backorder
- Open the Internal Transfer (where source is that PO and there operation type
is internal transfer that original one)
  - Demand: 20
  - Reserved Quantity: 12
- Click into detail button on stock move and split the move line into:
  - 9 units from Lot-1
  - 3 units from Lot-1
- save
- Open the Quality Check
  - Pass 9 units
  - Fail 3 units
- Validate the transfer and create a backorder
- Open the internal  transfer whose operation type `Internal Transfer 2`

Issue:
------
`Internal Transfer 2` contains two stock moves:
- Move 1:
  - Demand: 20
  - Quantity: 9
  - This is correct.
- Move 2:
  - Demand: 8
  - Quantity: 0
  - This move should not exist.

Expected behavior:
------------------
`Internal Transfer 2` should contain only the move corresponding to the successfully passed quantity:

- Demand: 20
- Quantity: 9

No additional move with demand 8 and quantity 0 should be generated.

Cause:
--------------------------
A 3-step route pre-creates the whole chain at confirm time: Receipt -> Internal Transfer -> Internal Transfer 2, each linked through move_dest_ids/move_orig_ids. Both fields are the two sides of a single many2many relation (stock_move_move_rel), so removing the relation from either side drops it entirely.

When the user confirms the failure on the quality check, the wizard calls quality.check._move_line_to_failure_location() (quality.py). Because the failure location differs from the next operation's source location, it runs

https://github.com/odoo/enterprise/blob/3a5e30f0bb7c1660827fd209cd74ef3bcd538213/quality_control/models/quality.py#L386

and `_break_mto_link()` then does unlink of `orig_location_id`
```py
    self.move_orig_ids = [Command.unlink(parent_move.id)]
    self.procure_method = 'make_to_stock'
```
**This is intentional** : it switches Internal Transfer 2 to `make_to_stock` so its `_action_assign()` reserves only what is physically present at Quality Control, instead of chain-reserving the 3 failed units that were rerouted to the failure location.

The side effect is that, because the relation is shared, unlinking parent_move from Internal Transfer 2's move_orig_ids also empties the Internal Transfer move's move_dest_ids.

- when the picking is validated and the backorder is created

When the picking is later validated, `_action_done()` splits off the remaining, never- reserved demand into a backorder move via `_split()` -> `_prepare_move_split_vals()`,
 which copies `move_dest_ids` from the original move. but that's already empty,
 because of the break at the time of failed quality check.
So the backorder is created with no `move_dest_ids` even though its 8 units have nothing to do with the quality failure they simply haven't
 been reserved/processed yet.

https://github.com/odoo/odoo/blob/6feedc18b7873bfde62047ece1a5de882319bc21/addons/stock/models/stock_move.py#L1955

Then action_done trigger ` _action_confirm()` it calls `_push_apply()`.

https://github.com/odoo/odoo/blob/6feedc18b7873bfde62047ece1a5de882319bc21/addons/stock/models/stock_move.py#L966-L967

` _push_apply()`  only skips a move if it already has `move_dest_ids` since the backorder has none, it doesn't skip — it searches for an applicable push rule from WH/Quality Control, finds the very same rule that already produced Internal Transfer 2
 the first time, and creates a brand new Internal Transfer 2 move for its own demand (8)
 via `rule._run_push()`. That new move has quantity 0,

Fix:
--------------------------
Before pushing a move that has no destination, `_push_apply()` now first checks whether a failed, diverted quality check (same product, same upstream chain via move_orig_ids) already exists for it. If so, this move is just a leftover backorder of a transfer that already had its link broken for quality reasons, and the existing destination move already covers it — so the push is skipped instead of creating a duplicate.
 Nothing about the quality check wizard or the existing link-breaking
logic was changed; this only stops that breakage from leaking into a later, unrelated backorder.

----

opw-6298637