Steps to reproduce:
- Open any PoS session
- Click on Orders and filter by "Paid" orders
- Select an order and click on "Details"
- Open the "Payments" tab and click on the "View" button of a payment
- Click on the payment method link

Traceback:
OwlError: The following error occurred in onWillStart: "Cannot find key "pos_payment_provider_cards" in the "view_widgets" registry"

Backend views opened from within the PoS UI (order details dialog, drill-down on many2one links, ...) share their arch with the backend, but `point_of_sale._assets_pos` excludes everything under `static/src/backend/`, so widgets defined there (e.g. `pos_payment_provider_cards`, `lna_checklist`,
`point_of_sale_test_epos`) are never registered in the PoS UI. Unlike missing field widgets, which fall back to the default widget with a warning, an unknown `<widget>` node makes the whole view crash since `Widget.parseWidgetNode` reads the registry without a fallback.

Those widgets are backend configuration helpers that are irrelevant in a PoS session, so instead of bundling each of them (and any future one) in the PoS assets, patch `Widget.parseWidgetNode` in the PoS bundle to skip unknown widgets with a warning, like missing field widgets do. This covers the form, list and kanban arch parsers at once.

opw-6382156

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

Forward-Port-Of: odoo/odoo#279823
Forward-Port-Of: odoo/odoo#276912

*:mrp_subcontracting_purchase

Issue before this commit:
========================
- In inter-warehouse transfers with `multi-step delivery` and in multi-step manufacturing flows, demand moves were not correctly counted in the monthly demand.

- Also, direct transfers to customer and subcontracting locations generated from `orderpoint` were also not counted correctly (when checked before move scheduled on the same day). This resulted in lower monthly demand values than the actual demand and could lead to inaccurate purchase planning.

Steps to Reproduce:
=========================
- Install `purchase_stock` module and enable multi-step routes.
- Set the Outgoing Shipments in the warehouse to 2-step/3-step.
- Create a second warehouse and configure it to `resupply from another warehouse`.
- Create a storable product and assign a vendor.
- Create an orderpoint for the product in the second warehouse, set the route to the warehouse resupply route, and trigger the replenishment.
- Go to Purchase → Create RFQ for the vendor and open the catalog.
Observation:
The replenishment transfer demand is not correctly counted in the monthly demand

Cause of the issue:
=========================
- In [PR](https://github.com/odoo/odoo/pull/244180), the monthly demand move domain was updated to filter out intermediate customer delivery moves using `move_dest_ids.origin_returned_move_id`. However, inter-warehouse replenishment delivery moves also have `move_dest_ids` linked to receipt moves of the other warehouse, but `origin_returned_move_id is not set` since they are not return move Because of this, these valid demand moves were incorrectly excluded from the monthly demand computation.
- Also, in inter-warehouse flows with multi-step delivery, `delivery moves` stay in the `waiting state` since they wait for another operation, so they were also not counted. Additionally, `orderpoint-triggered` moves use a `fixed midday scheduled time`, and since monthly demand was computed using the current timestamp as the limit  date, same-day moves could be excluded if checked before midday.

After This Commit:
=========================
- The monthly demand move domain was updated to correctly count inter-warehouse, manufacturing, and subcontracting resupply demand moves while still avoiding inflated demand from intermediate moves. The move state domain was also updated to `include waiting moves` in multi-step flows, and the limit date now uses the full current day so same day moves are counted correctly.

Enterprise PR: odoo/enterprise#115944
TaskID-5490137

Forward-Port-Of: odoo/odoo#280167
Forward-Port-Of: odoo/odoo#262435

### Steps to reproduce:
- Open CRM app (or any model with chatter)
- Open any record (e.g., an Opportunity)
- Click "Log note"
- Type some text into the input box
- Click the "Full composer" icon to open the mail composition wizard
- Log the note
- Click "Log Note" again
> The note is logged successfully, but the text remains visible inside the small
  inline chatter input box as if it was never sent. (Doesn't happen everytime)

### Cause of Issue:
Composer drafts are auto-saved to IndexedDB via the debounced saveContent()
https://github.com/odoo/odoo/blob/ac2d15c1132af16f00f8955d1be9b43a8626d9bd/addons/mail/static/src/core/common/composer.js#L986-L1003

`clear()`, called from the Full Composer's `onClose` handler after logging a note, only resets in-memory composer state and removes a `localStorage` key — it never deletes the corresponding `IndexedDB` entry.

### Fix:
Have `clear()` also delete the persisted IndexedDB draft via the helper used after a normal chatter post in `_sendMessage()`, so `clear()` fully tears down both in-memory and persisted state.

opw-6354149

Forward-Port-Of: odoo/odoo#275999

Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed.

This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'.

**Steps to reproduce:**
- Install the stock module.
- Open the Transfers list view.
- Add custom group for 'Printed'.
- Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'.
- Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu.
- Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view.

**Expected behavior:**
A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu.
close #235129

Forward-Port-Of: odoo/odoo#276582

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#279356
Forward-Port-Of: odoo/odoo#276211

## Problem

`pttExtensionHookService` registers a global `window.addEventListener("message", ...)`
handler that reads `data.from` without checking that `data` is defined first:

```js
browser.addEventListener("message", ({ data, origin, source }) => {
    const rtc = env.services["discuss.rtc"];
    if (
        source !== window ||
        origin !== location.origin ||
        data.from !== "discuss-push-to-talk" ||   // <- crashes if data is undefined
        (!rtc && data.type !== "answer-is-enabled")
    ) {
        return;
    }
    ...
```

Any same-window, same-origin `postMessage` sent by an unrelated browser
extension (a common content-script <-> injected-script pattern) can carry
`data === undefined`. The `source !== window` and `origin !== location.origin`
checks only filter out cross-window/cross-origin messages, so a same-origin
message from any other extension reaches this handler and crashes with:

```
TypeError: Cannot read properties of undefined (reading 'from')
```

This surfaces as an uncaught client error on any page with Discuss loaded,
after some time, unrelated to what the user is doing. The Discuss
push-to-talk extension itself does not need to be installed to trigger it,
since the crash happens before checking whether the message actually
originated from that extension.

## Solution

Use optional chaining (`data?.from`) so unrelated same-origin messages with
no `data` are safely ignored instead of crashing.

## Verification

- Reproduced against the live production `web.assets_web.min.js` bundle
  (traceback matches exactly).
- Confirmed the bug is still present in the latest `18.0` of both `OCA/OCB`
  and `odoo/odoo` (no newer commit touches this file since
  `dc58ef1ad904`, which fixes an unrelated issue).

Forward-Port-Of: odoo/odoo#280079
Forward-Port-Of: odoo/odoo#279476

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

When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line.

This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and bypassed calling `super()` on them. Consequently, if a line already had an analytic distribution (such as inheriting the project's), the system would skip computing the product's specific distribution rules entirely.

This commit resolves the issue by reverting that change, ensuring the base compute method is always called so product-based rules execute correctly. While this means manual analytic entries added before the compute trigger might be overwritten, there is no perfect solution to prevent losing both manual and product distributions. As concluded with the Product Owner in a similar PR for Purchase Orders, we prioritize keeping the product's automated distribution, as it is much harder to manually reconstruct after its removal.

The corresponding test is also reverted to its original state to reflect this expected behavior. A small test is added to ensure that the analytic distribution results are unchanged when adding a project to the SO.

opw-6279406

**Steps to Reproduce:**

- Accounting > Configuration > Settings > Analytics > enable Analytic Accounting
- Accounting > Configuration > Analytic Accounting > Analytic Distribution Models
  - Create a new model with any product (e.g. “Bolt”) and any Analytic Distribution (e.g. “Production”)
- Create SO, enable “Analytic Distribution” in filters
  - Add any customer, add the above product (e.g. “Bolt”), save
  - Observe that the “Production” Analytic Distribution is automatically populated
- On the same SO > Other Info> Project > add (e.g. “Home Construction”)
  - Then go back to Order Lines and remove the previous SOL and create a new one with the same product > save
  - Observe that the “Production” Analytic Distribution is not added (although “Home Construction” is)


**Current behavior before PR:**

- Product analytic distributions are not automatically applied when the Sales Order is already linked to a project

**Desired behavior after PR is merged:**

- Product analytic distributions are automatically applied even when the Sales Order is linked to a project

**Note:**

This commit basically ports a fix/revert (https://github.com/odoo/odoo/commit/54852978617cfb2d8c5afdcf80adbf6c0605093c) introduced to the project_purchase module for the same issue. Their commit message is quite detailed in explaining the issue. To quote:

>However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic
distribution, as it is much harder to add it again after its removal.
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.

The referenced initial commit is here: https://github.com/odoo/odoo/commit/3dfa98bd3b9d5ababe3a7548d604e22350023799

Forward-Port-Of: odoo/odoo#274893

## Steps to Reproduce:
- Install `website_sale` with demo data.
- Activate the "Mercado Pago" payment provider.
- Website > Shop > Add a product > Go to cart and proceed to Checkout.
- Select the "Card" payment method and proceed.

## Error:
`AttributeError: 'bool' object has no attribute 'lower'`

## Cause:
Before commit https://github.com/odoo/odoo/commit/1ef1b73ee2ec3c1adfdffe32c34bb441b97dfbec, the availability of a payment provider was controlled by the `state` field ('disabled', 'enabled', 'test'). To use Mercado Pago in test mode, users first had to configure an account country (`mercado_pago_account_country_id`).

But after this commit, the `state` field has been replaced by `is_live`. By default, providers are available in test mode when `is_live` is disabled, allowing users to make a test payment. - [1]
During payment processing, the missing account country leads to an error.

## Fix:
Before processing a payment, ensure that an account country is configured and raise a validation error if it is missing.
We have same validation check on account onboarding (Ref): https://github.com/odoo/odoo/blob/ada769dac1deda7dbd89596153f97c6f5887f57a/addons/payment_mercado_pago/models/payment_provider.py#L154-L157

[1] - https://github.com/odoo/odoo/blob/ada769dac1deda7dbd89596153f97c6f5887f57a/addons/payment/models/payment_provider.py#L38-L43

sentry-7638271109

Description of the issue/feature this PR addresses:

  Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled.

  Steps to reproduce:

  1. Enable developer mode.
  2. Go to Settings > Technical > Email > Outgoing Mail Servers.
  3. Create a server and set SMTP Port to `8069`.
  4. Move focus away from the field.
  5. The same issue occurs on an Incoming Mail Server with a port such as `10143`.

  Current behavior before PR:

  Ports are displayed with thousands separators, e.g. `8,069` and `10,143`.

  Desired behavior after PR is merged:

  Mail server ports remain unformatted, e.g. `8069` and `10143`.

  Fixes #275937

  ---
  I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
  
"As a recent Computer Engineering graduate, I made my first open-source contribution to Odoo." :)

Forward-Port-Of: odoo/odoo#278329

Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed.

This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'.

**Steps to reproduce:**
- Install the stock module.
- Open the Transfers list view.
- Add custom group for 'Printed'.
- Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'.
- Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu.
- Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view.

**Expected behavior:**
A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu.
close #235129

Forward-Port-Of: odoo/odoo#276582

*:mrp_subcontracting_purchase

Issue before this commit:
========================
- In inter-warehouse transfers with `multi-step delivery` and in multi-step manufacturing flows, demand moves were not correctly counted in the monthly demand.

- Also, direct transfers to customer and subcontracting locations generated from `orderpoint` were also not counted correctly (when checked before move scheduled on the same day). This resulted in lower monthly demand values than the actual demand and could lead to inaccurate purchase planning.

Steps to Reproduce:
=========================
- Install `purchase_stock` module and enable multi-step routes.
- Set the Outgoing Shipments in the warehouse to 2-step/3-step.
- Create a second warehouse and configure it to `resupply from another warehouse`.
- Create a storable product and assign a vendor.
- Create an orderpoint for the product in the second warehouse, set the route to the warehouse resupply route, and trigger the replenishment.
- Go to Purchase → Create RFQ for the vendor and open the catalog.
Observation:
The replenishment transfer demand is not correctly counted in the monthly demand

Cause of the issue:
=========================
- In [PR](https://github.com/odoo/odoo/pull/244180), the monthly demand move domain was updated to filter out intermediate customer delivery moves using `move_dest_ids.origin_returned_move_id`. However, inter-warehouse replenishment delivery moves also have `move_dest_ids` linked to receipt moves of the other warehouse, but `origin_returned_move_id is not set` since they are not return move Because of this, these valid demand moves were incorrectly excluded from the monthly demand computation.
- Also, in inter-warehouse flows with multi-step delivery, `delivery moves` stay in the `waiting state` since they wait for another operation, so they were also not counted. Additionally, `orderpoint-triggered` moves use a `fixed midday scheduled time`, and since monthly demand was computed using the current timestamp as the limit  date, same-day moves could be excluded if checked before midday.

After This Commit:
=========================
- The monthly demand move domain was updated to correctly count inter-warehouse, manufacturing, and subcontracting resupply demand moves while still avoiding inflated demand from intermediate moves. The move state domain was also updated to `include waiting moves` in multi-step flows, and the limit date now uses the full current day so same day moves are counted correctly.

Enterprise PR: odoo/enterprise#115944
TaskID-5490137

Forward-Port-Of: odoo/odoo#280167
Forward-Port-Of: odoo/odoo#262435

## Problem

`pttExtensionHookService` registers a global `window.addEventListener("message", ...)`
handler that reads `data.from` without checking that `data` is defined first:

```js
browser.addEventListener("message", ({ data, origin, source }) => {
    const rtc = env.services["discuss.rtc"];
    if (
        source !== window ||
        origin !== location.origin ||
        data.from !== "discuss-push-to-talk" ||   // <- crashes if data is undefined
        (!rtc && data.type !== "answer-is-enabled")
    ) {
        return;
    }
    ...
```

Any same-window, same-origin `postMessage` sent by an unrelated browser
extension (a common content-script <-> injected-script pattern) can carry
`data === undefined`. The `source !== window` and `origin !== location.origin`
checks only filter out cross-window/cross-origin messages, so a same-origin
message from any other extension reaches this handler and crashes with:

```
TypeError: Cannot read properties of undefined (reading 'from')
```

This surfaces as an uncaught client error on any page with Discuss loaded,
after some time, unrelated to what the user is doing. The Discuss
push-to-talk extension itself does not need to be installed to trigger it,
since the crash happens before checking whether the message actually
originated from that extension.

## Solution

Use optional chaining (`data?.from`) so unrelated same-origin messages with
no `data` are safely ignored instead of crashing.

## Verification

- Reproduced against the live production `web.assets_web.min.js` bundle
  (traceback matches exactly).
- Confirmed the bug is still present in the latest `18.0` of both `OCA/OCB`
  and `odoo/odoo` (no newer commit touches this file since
  `dc58ef1ad904`, which fixes an unrelated issue).

Forward-Port-Of: odoo/odoo#280079
Forward-Port-Of: odoo/odoo#279476

Description of the issue/feature this PR addresses:

  Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled.

  Steps to reproduce:

  1. Enable developer mode.
  2. Go to Settings > Technical > Email > Outgoing Mail Servers.
  3. Create a server and set SMTP Port to `8069`.
  4. Move focus away from the field.
  5. The same issue occurs on an Incoming Mail Server with a port such as `10143`.

  Current behavior before PR:

  Ports are displayed with thousands separators, e.g. `8,069` and `10,143`.

  Desired behavior after PR is merged:

  Mail server ports remain unformatted, e.g. `8069` and `10143`.

  Fixes #275937

  ---
  I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
  
"As a recent Computer Engineering graduate, I made my first open-source contribution to Odoo." :)

Forward-Port-Of: odoo/odoo#278329

You'll need two users :
	- Internal User A that can create projects
	- User B with a granted portal access

Optionnal third user to compare the flows :
	- Internal User B that can create tasks in a porject

- With User A, create a new project with atleast a single stage
- Go to the project settings
- Make sure that Visibility is set to : "All internal users and invited portal users"
- Click on Share Project
- Add User B as a new Collaborator with the Edit acess mode
- Confirm by clicking on Share Project
- Still in the project settings, click on the blue user icon in the top right to edit the Followers :
	- Make sure you are following the project
	- Click on the edit button and make sure Task Created is checked

 Optionnal for easiness of testing :
 - Go to the User A settings and in Preferences > Notifications : In Odoo

- Log in with User B (in a new incognito tab on the side is best)
- Go to Projects > The project that has been shared
- Create a new task

No notification is sent to User A. If the same flow is done using User C, then a notification is correctly sent.

The fields that determine to which users the notifications are sent to is `message_follower_ids`. In our case, the value of that field does not contain User A, so no notifcation is sent to them.

The method responsible for assigning values to that field is `_message_auto_subscribe()` which adds follower using subtypes parent relationship. The parent subtype of tasks are projects. So, essentially, we look for followers of the parent project, and see if we can add them to our task.

Before proceeding with the assignation, we check that the parent subtype's field was actually edited :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L4778-L4781

So we look that `updated_values` contains "project_id". `updated_values` is created by the the `mail_thread` create method by joining the values in `vals_list` and the context default variables. In our case, this should be enough since `default_project_id` is provided when creating a task :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L340-L344

But, a bit before this, the task create method edits the context to replace 'default_project_id' by 'default_create_in_project_id' : https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/project/models/project_task.py#L1102-L1109

So we do not detect that `project_id` has been changed and don't actually add the followers.

We remove the custom 'default_create_in_project_id` context

opw-6026932

Forward-Port-Of: odoo/odoo#278474
Forward-Port-Of: odoo/odoo#278353

Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed.

This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'.

**Steps to reproduce:**
- Install the stock module.
- Open the Transfers list view.
- Add custom group for 'Printed'.
- Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'.
- Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu.
- Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view.

**Expected behavior:**
A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu.
close #235129

Forward-Port-Of: odoo/odoo#276582

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse deliveries in two steps
- Inventory > Operations > Tranfers > Internal > New
- Set the operation type as Pick, set a partner and add Partner: Bob
- In the sales & Purchase tab of the partner form set a customer location to be a child of the Customers location: Customers/Bob'Stock
- Confirm and validate the Pick for 1 unit of a product P
#### > A ship picking is created but the destination of the related move is still set to the default customer location.

### Note:

If the flow is performed by a sale order, the `property_stock_customer` location will appropriately be used as `location_final_id`: https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L297 https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L306-L309 https://github.com/odoo/odoo/blob/720598d0315dbb91628441078febfd43ffefb431/addons/stock/models/stock_rule.py#L263-L264 So that the bug does not occur in that case. By contrast if the pick move is created manually, we do not set its `location_final_id` and hence do not propagate the info. Even though it looks expected to be set set as location_dest_id of the ship move sas suggested by the `stock.picking.location_dest_id` compute method :
https://github.com/odoo/odoo/blob/fe3aea07a1964cd24f4c8ebf2bc93e483eca6b0b/addons/stock/models/stock_picking.py#L990-L1002

opw-6402483

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

Forward-Port-Of: odoo/odoo#278838

A user with role Inventory/User cannot validate the dropship of a product with an Average Cost (AVCO) Costing Method

Steps to reproduce:
1. Install sale_management, stock_dropshipping and stock_landed_costs module
2. Go to Sales > Configuration > Categories and change Furniture / Office's Costing Method to Average Cost (AVCO)
3. Go to Settings > Users and set Marc Demo's role on Purchase to User
3. Log in as Marc Demo
4. Create and confirm a quotation for customer Acme Corporation with product Large Cabinet (Dropship route and AVCO costing method)
5. Go to the related purchase order and confirm it
6. Go to the related dropship and validate it
7. An access error is raised

Issue:
Validating a dropship recomputes the cost of the product and reads `stock.valuation.adjustment.lines`
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/models/stock_move.py#L11 But only Inventory/Administrator have read access to these records https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/security/ir.model.access.csv#L4

Solution:
Call `_get_landed_cost` with `.sudo()` in order to update the cost even though the user has no landed costs access

opw-6366844

Forward-Port-Of: odoo/odoo#276285

Steps to reproduce
1. Go to Manufacturing > Configuration > Settings and enable By-Products
2. Go to Inventory > Configuration > Locations, find the location with type
   Production and set the Cost of Production account
3. Go to Inventory > Configuration > Product Categories and set the costing
   method to Standard Price and Inventory Valuation to Perpetual (at invoicing)
4. Set the finished product and byproduct as Storable with a non-zero Cost
5. Create a BoM with a component and a byproduct with a Cost Share % assigned
6. Create and complete a manufacturing order
7. Check the journal entries of the MO: the byproduct entry shows $0

Issue
Standard-cost byproduct moves have no price_unit set in either code path
of _cal_price, so their journal entries always show $0.

When the finished product is standard cost, _cal_price returns early at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L66-L68
without iterating byproducts at all, so no price_unit is ever set on them.

When the finished product is FIFO/AVCO, the byproduct loop at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L83-L84
only sets price_unit for FIFO/AVCO byproducts. Standard byproducts are
skipped, giving them $0 even though their cost_share was already deducted
from the finished product, making value disappear from inventory entirely.

For standard-cost products the MO has no influence on their value — they
always use the standard_price from the product form, regardless of cost_share.

Solution
In the early-return branch, iterate byproducts: standard ones get
standard_price, FIFO/AVCO ones get total_cost * cost_share.
In the FIFO/AVCO branch, add the same standard_price fallback so standard
byproducts are no longer left at $0 when their cost_share is set.

opw-6020065

Forward-Port-Of: odoo/odoo#257472

Before this commit, contains() and its variants gave the client 3 seconds, and the bus helpers 2 seconds. The problem is that the first wait after openDiscuss pays for the whole mount, /mail/data and /discuss/channel/messages. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a
  busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

"Reactions are ordered by id" fails 1 run in 60 at 4x for that reason.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the element is there, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

This should also close most of the open runbot errors shaped like:

    Failed to find x of "..." (Timeout of 3 seconds). Found 0 instead.

The element does show up in those, just after the wait gave up.

https://runbot.odoo.com/odoo/error/944188

web companion https://github.com/odoo/odoo/pull/279984

Forward-Port-Of: odoo/odoo#280400
Forward-Port-Of: odoo/odoo#279983

Description of the issue/feature this PR addresses:

  Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled.

  Steps to reproduce:

  1. Enable developer mode.
  2. Go to Settings > Technical > Email > Outgoing Mail Servers.
  3. Create a server and set SMTP Port to `8069`.
  4. Move focus away from the field.
  5. The same issue occurs on an Incoming Mail Server with a port such as `10143`.

  Current behavior before PR:

  Ports are displayed with thousands separators, e.g. `8,069` and `10,143`.

  Desired behavior after PR is merged:

  Mail server ports remain unformatted, e.g. `8069` and `10143`.

  Fixes #275937

  ---
  I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
  
"As a recent Computer Engineering graduate, I made my first open-source contribution to Odoo." :)

Forward-Port-Of: odoo/odoo#278329

Steps to reproduce:

1) Install hr_holidays & hr_attendance.
2) Enable "Display Extra Hours" & "Absence Management" in the Attendance app settings.
3) Make a new employee, in the form view click the "+" button to make a new hr version record for this employee.
4) Set the date to be the first of the last month.
5) In the Attendance app -> New -> Select the new employee.
6) Select the check in and out dates to be from last month, edit the times such that the time worked is between 7 and 8 hours (ex 9:00am to 4:55pm).
7) In the Attendance app -> Reporting -> Attendances -> the test employee should have a negative value for "Worked Extra Hours"
8) Create a new time off type, enable "Deduct Extra Hours" & disable "Requires Allocation" use hours as the Unit of measure.
9) Open the time off smart button menu from the test employee's form view.

Issue) The value seen in the report from step 7 is not the same as what the user sees in the dashboard.

Notes) This issue can occur when an employee scheduled to work for 8 hours a day only clocks in for 7:55 hours leading to a negative extra time.

The back-end has the correct value stored and sends it to the browser. The issue occurs because the JavaScript function that converts the decimal number of hours into a string (9.5 -> "9:30") does not work with negative input. This PR resolves that issue. 

opw-6417543 

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

Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed.

This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'.

**Steps to reproduce:**
- Install the stock module.
- Open the Transfers list view.
- Add custom group for 'Printed'.
- Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'.
- Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu.
- Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view.

**Expected behavior:**
A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu.
close #235129

Forward-Port-Of: odoo/odoo#276582

Steps to reproduce
1. Go to Manufacturing > Configuration > Settings and enable By-Products
2. Go to Inventory > Configuration > Locations, find the location with type
   Production and set the Cost of Production account
3. Go to Inventory > Configuration > Product Categories and set the costing
   method to Standard Price and Inventory Valuation to Perpetual (at invoicing)
4. Set the finished product and byproduct as Storable with a non-zero Cost
5. Create a BoM with a component and a byproduct with a Cost Share % assigned
6. Create and complete a manufacturing order
7. Check the journal entries of the MO: the byproduct entry shows $0

Issue
Standard-cost byproduct moves have no price_unit set in either code path
of _cal_price, so their journal entries always show $0.

When the finished product is standard cost, _cal_price returns early at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L66-L68
without iterating byproducts at all, so no price_unit is ever set on them.

When the finished product is FIFO/AVCO, the byproduct loop at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L83-L84
only sets price_unit for FIFO/AVCO byproducts. Standard byproducts are
skipped, giving them $0 even though their cost_share was already deducted
from the finished product, making value disappear from inventory entirely.

For standard-cost products the MO has no influence on their value — they
always use the standard_price from the product form, regardless of cost_share.

Solution
In the early-return branch, iterate byproducts: standard ones get
standard_price, FIFO/AVCO ones get total_cost * cost_share.
In the FIFO/AVCO branch, add the same standard_price fallback so standard
byproducts are no longer left at $0 when their cost_share is set.

opw-6020065

Forward-Port-Of: odoo/odoo#257472

A user with role Inventory/User cannot validate the dropship of a product with an Average Cost (AVCO) Costing Method

Steps to reproduce:
1. Install sale_management, stock_dropshipping and stock_landed_costs module
2. Go to Sales > Configuration > Categories and change Furniture / Office's Costing Method to Average Cost (AVCO)
3. Go to Settings > Users and set Marc Demo's role on Purchase to User
3. Log in as Marc Demo
4. Create and confirm a quotation for customer Acme Corporation with product Large Cabinet (Dropship route and AVCO costing method)
5. Go to the related purchase order and confirm it
6. Go to the related dropship and validate it
7. An access error is raised

Issue:
Validating a dropship recomputes the cost of the product and reads `stock.valuation.adjustment.lines`
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/models/stock_move.py#L11 But only Inventory/Administrator have read access to these records https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/security/ir.model.access.csv#L4

Solution:
Call `_get_landed_cost` with `.sudo()` in order to update the cost even though the user has no landed costs access

opw-6366844

Forward-Port-Of: odoo/odoo#276285

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

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

Forward-Port-Of: odoo/odoo#258038

Doing an euclidean division on floats with the native operators is unreliable: because of IEEE-754 representation errors, `value1 % value2` can return a spurious remainder (e.g. `50.4 % 16.8 == 16.799999999999997` instead of 0.0) and `int(value1 / value2)` can truncate the quotient one step too low (e.g. `int(0.3 / 0.1) == 2` instead of 3). `float_div` returns the `(quotient, remainder)` pair free of those errors.

The key is to never run a lossy `%` or `//` on the raw floats. Instead both operands are first snapped onto the precision grid with `float_round` and then scaled to integers: since a grid-snapped value is a multiple of `rounding`, dividing it by `rounding` counts how many grid steps it spans. That division is still noisy (`4.35 / 0.05 == 86.99999999999999`), so the result is passed through `builtins.round` to coerce it to the exact integer step count. The euclidean division itself is then a plain integer `divmod`, which is exact, and the remainder is scaled back to real units. This is why the correction is applied to the inputs and not to the output: rounding the result of a native `%` would only round an already-corrupt value, and would still misreport the quotient in the corner cases the util exists to handle.

Dividing by `rounding` is meaningful for any precision, not only powers of ten: the grid step can be `0.05`, `0.25`, `0.5`, `0.03`, ... and `value / step` counts the steps in every case. This mirrors the normalize/denormalize scheme `float_round` already uses internally.

The util shares `float_round`'s inherent limitation: the scaled step count must stay representable as an exact `float` integer, so exactness is lost past ~2**53 grid steps (extreme magnitudes at a fine precision). This is the IEEE-754 double-precision ceiling and is well outside any realistic quantity or price range.

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

Forward-Port-Of: odoo/odoo#277160

Steps to reproduce:
- Install 'Sales', 'Accounting' and 'l10n_sa_edi'
- Settings > Accounting > Rounding Method > Round Globally
- Create an invoice whose per-line tax base is fractional (e.g. a price-included 15% VAT, 3 lines at 10.00 -> base 8.6957 each)
- Generate the ZATCA UBL document

Issue:
The exported document is internally inconsistent and is rejected by ZATCA (BR-CO-13): cbc:LineExtensionAmount (BT-106) = 26.10 while cbc:TaxExclusiveAmount (BT-109), and thus the QR / PayableAmount (BT-115), = 26.09. This is the same 0.01 discrepancy reported for 100% down-payment invoices under global rounding.

Cause:
LineExtensionAmount was built by summing account.move.line.price_subtotal, which is always rounded per line (8.70 x 3 = 26.10), whereas TaxExclusiveAmount is built from the aggregated base_amount_currency, which follows the company rounding method and is rounded globally (26.087 -> 26.09). Under 'round_globally' the two diverge by a cent.

This is the base-amount counterpart of commit 3d398789, which aligned the prepaid tax amount to global rounding but left the line net amount on per-line rounding.

Solution:
Derive the line net amount from the globally-rounded aggregated base (taxes_vals['base_amount_currency'])
https://github.com/odoo/odoo/blob/c7c361e6af4da43dc1f9653703067ffe6500a046/addons/account/models/account_tax.py#L1529 instead of the per-line rounded
price_subtotal, consistent with total_amount_sa on the same line. The whole document now stays on a single rounding basis, so the sum of the line net amounts equals the TaxExclusiveAmount and BR-CO-13 is satisfied.

opw-5881564

Forward-Port-Of: odoo/odoo#275093

Steps to reproduce:
-------------------
1. Install `hr` module
2. Create two employees (e.g., emp1 and emp2) and assign
   emp1 as the manager of emp2
   → emp2 is now a direct subordinate of emp1
3. In the employee list view, apply the custom filter
   "Direct subordinates is set" (child_ids != False)
   → emp1 appears in the results as expected
4. Archive emp2
5. Apply the same filter again
   → emp1 still appears in the results even though it has
   no active subordinates

Issue:
------
When an employee (e.g., `emp2`) is archived, their manager (`emp1`) should no longer appear in the "Direct subordinates is set" (child_ids != False) filter — since `emp1` no longer has any active subordinates.

However, `emp1` still appears in the search results after `emp2` is archived, because the underlying EXISTS subquery checks all subordinates regardless of their active state.

Cause:
--------
Before this commit 5ef007a, `osv.expression`, filtering on a One2many field would automatically
search against [active co-records ](https://github.com/odoo/odoo/blob/5f65e92d7fa341193df53f5aba1620b596f9a1ec/odoo/osv/expression.py#L1260-L1265)only by default.

After that commit, the `condition_to_sql` method in `_RelationalMulti` constructs the comodel with [active_test=False](https://github.com/odoo/odoo/blob/463ca4cf867812890c17d1e1abf7640b04f70ad0/odoo/orm/fields_relational.py#L672-L686) when resolving relational field conditions. This causes the EXISTS subquery generated for `child_ids != False` to compare against all subordinates. (including archived ones rather than active ones only).

Solution:
---------
Added a callable `domain` attribute on the `child_ids` field definition so that only active subordinates are considered by default. This ensures [get_comodel_domain()](https://github.com/odoo/odoo/blob/2d8b24a791b6fe6bb214c32d4fb58b3d46eca70b/odoo/orm/fields_relational.py#L75-L85) returns a server-side domain that filters out archived subordinates, making the `child_ids != False` filter behave as expected.

**NOTE:**
> The ORM uses the **active_test** flag when doing searches. Having in [1, 2, 3] in domains bypasses the search method because we suppose that we already searched to find these ids.
For hierarchical resolution, we bypass rights and active_test.
The result is that inactive records are considered in the result.

confirmed with the framework team, and it is intended behaviour.
However, this is not the expected behaviour for the direct subordinates case in `hr`.
The fix is therefore applied at the field level by explicitly declaring
a domain on `child_ids` to filter out archived subordinates.

ORM commit: https://github.com/odoo-dev/odoo/commit/12eae5c85fa7facb299f0f1bf1fdd62e3ff82aa5



opw-6193104



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

## Issue
When logging timesheet from the *Recorded* smart button on a Sale Order containing multiple service items, the recorded hours will be added to the first sale order line, regardless of the task ID set on the timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P:
    - *Product Type*: Service
    - *Create on Order*: Task
    - *Project*: Any
3. Create a SO:
    - *Customer*: Any
    - Add the product P on two different lines and give them two different descriptions D1 and D2
    - Confirm the SO, this will create two tasks with the names D1 and D2
4. On the SO, click the *Recorded* smart button and create two entries:
    1. Task D1, 2 hours spent
    2. Tsk D2, 3 hours spent
5. **Back on the SO, there are 5 hours registered for the first SOL (with the description D1), which does not match the entries we created from the smart button.**

It is worth noting that when we create the Timesheets entries from the project itself (instead of the SO's smart button), the hours are correctly distributed among the different SOLs.

## Cause
The SOL linked to the timesheet entry (`account.analytic.line`) is computed by `_compute_so_line`:

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/hr_timesheet.py#L79-L82

This method sets the correct SOL under the condition that `is_so_line_edited` is False and `_is_no_billed()` returns True.

When opening the *Recorded* smart button from a SO, the `is_so_line_edited` is set to True by default, even if no SOL was modified.

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/sale_order.py#L113-L117

As that value is never set to False, when trying to compute the SOL for the timesheet entry, the entry is skipped and the default SOL (which is the first one) is used instead.

opw-6133473

### Steps to reproduce

1. Install *Sales* and *Timesheets*
2. Create a service product: Invoicing Policy = *Based on Timesheets*, Create on Order = *Task*
3. Create a sale order for it (quantity 1) and confirm it
4. On the generated task, log **4.5 h on 15/06** and **3.5 h on 23/07**
5. *Create Invoice* with no timesheet period → 8 h, and post it
6. On that invoice: *Reverse* → *Partial Refund*, set the quantity to **3.5 h** and post it → 4.5 h invoiced
7. Log **1 h on 31/07** → 9 h delivered
8. *Create Invoice* again, with a **Timesheets Period of 01/06 → 31/07**

### Current behavior

The invoice bills **9 h**: the 4.5 h that were invoiced and not credited are billed a second time.

### Expected behavior

The invoice bills **4.5 h** — the quantity delivered minus the quantity invoiced.

### Cause of the issue

Posting a partial credit note clears `timesheet_invoice_id` on every timesheet the reversed invoice
had linked (`sale_timesheet/models/account_move.py`, `action_post`), because a credit note carries a
quantity and never a set of timesheets, so there is no way to tell which hours it credited.

All of those hours therefore become candidates again in `_recompute_qty_to_invoice`, which assigns
their sum to `qty_to_invoice` without comparing it to what is still due on the line.

### Fix

Timesheet links cannot express a partially invoiced timesheet, so they are used only to select the
hours a period concerns, while the quantity that may still be billed is
`qty_delivered - qty_invoiced`. The period lookup is capped by that remainder, and kept at zero or
above so that an over-invoiced line is corrected by a deliberate credit note rather than as a side
effect of invoicing a period.

### Tests

Five tests are added to `addons/sale_timesheet/tests/test_sale_timesheet.py`.

Three of them fail without the fix:

| test | without the fix |
| --- | --- |
| `test_period_invoice_does_not_rebill_refunded_invoice_hours` | `9.0 != 4.5` |
| `test_period_invoice_after_refund_is_computed_per_line` | `4.0 != 1.5` |
| `test_period_invoice_after_refund_of_an_over_invoiced_line` | `8.0 != 1.0` |

The other two cover behaviour that is not exercised today and that the fix must not break: an
over-invoiced line (which must be left out rather than credited, and must not prevent the other
lines of the order from being invoiced) and the reversed invoice's own `invoice_date`, which must not
influence the quantity billed for a period.

The full `sale_timesheet` suite passes (86 tests).