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

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

[FIX] html_builder: prevent crash on legacy image shapes
When the Website Editor encounters an image shape that does not exist
in the registry, it fatally crashes upon saving (`TypeError: Cannot
read properties of undefined`), blocking the user from saving the page.

While an upgrade script exists to remap these shapes
([commit https://github.com/odoo/odoo/commit/f348be018f5740a31754494c905ea2b61bb718be](https://github.com/odoo/upgrade/commit/f348be0dcbc63c1f74f742b562509f81767564c0)),
timeline gaps leave SaaS databases vulnerable. For example, if a client
upgraded their database to 17.0 in Feb 2024, they bypassed the migration
script merged in Dec 2024. This leaves the legacy shape permanently
orphaned inside their modern views.

This commit adds a `getImageShape` fallback. Instead of crashing,the
editor now defaults to standard values and renders "None" in the UI,
allowing the user to select a new shape and save their work.

Steps to Reproduce:
1. Install Website.
2. Go to Site -> HTML / CSS Editor.
3. Add `data-shape="web_editor/basic/bsc_organic_2"` to an <img> tag.
4. Click "Edit" to open the Website Builder.
5. Click the image, OR click "Save".
6. JS traceback.

[opw-6286044](https://www.odoo.com/odoo/my-support-tasks/6286044?debug=assets)
[opw-6291591](https://www.odoo.com/odoo/my-support-tasks/6291591?debug=assets)

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

Forward-Port-Of: odoo/odoo#278686
Forward-Port-Of: odoo/odoo#270356

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

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

**Steps to reproduce:**
- Go to any view where you can send mails (eg sale orders)
- Send a first mail to multiple recipients so they are added automatically on the next mail.
- Open a new mail, confirm that the recipients are present, add a selectable attachment (eg a PDF), then click on it.
- Remove any amount of recipients then send the mail.
- You will see that the recipients are added back and the mail is sent to them.

**Behavior:**
Currently whenever a user clicks on an attachment in a mail composer, the systems considers that the user might be trying
to leave the page and will trigger an `urgentSave()`, and further down the line a `web_save()`.

The behavior when a web_save() is triggered is to create a record if there isnt currently one, and otherwise to write the modified values onto the record, using commands.

The recipients for the mail are added by default, which is represented by a list of `[4, id]`add commands, that will be written on the record created in the first `web_save`, however this list is not correctly emptied after the first `_save()`.

If the list is present within `this._changes` then it is correctly cleared, but in the case where no changes were made, the within `this._values['partner_ids']` still contains the commands.
So when we later assign `this.data = { ...this._values };`, `this.data['partner_ids']` now contains our uncleared list of commands.

https://github.com/odoo/odoo/blob/f3e407c6a58abd2ddba42f26fcbd1928da63cb63/addons/web/static/src/model/relational_model/record.js#L1222-L1230

And when we compute changes['partner_ids'] in our next iteration, we find ourselves with our command list again.
https://github.com/odoo/odoo/blob/f3e407c6a58abd2ddba42f26fcbd1928da63cb63/addons/web/static/src/model/relational_model/record.js#L1317-L1322

So when we then try to remove a recipient tag, the new delete command `[3, id]`
just gets canceled out with the already present add command.
And the `write()` in `web_save()` only writes add commands of already present partners, which doesn't do anything.

----

This commit adds a line to ensure commands inside `_values` are cleared

opw-6304713

Forward-Port-Of: odoo/odoo#278876

### Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not updated

### Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664
Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`, `workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629
However, many other changes can and are actually relevant.

### Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Starting from saas-19.1, the fix conflict with commit https://github.com/odoo/odoo/commit/5c4cf2e0fcc3ed5bef77380bb65f356c56b5dac4 That is, the `action_update_bom`, now replan's workorders:
https://github.com/odoo/odoo/blob/3412253211daf13d50755fdce7edd9ed9c4400df/addons/mrp/models/mrp_production.py#L1207-L1217
However, the `_link_bom` now unlinks the obsolete and re-creates the still valid workorders (possibly unplanned). In particular, both the computation of `is_planned` and of the new `duration_expected` might differ from the expected checked in the `action_update_bom`. Note that to ensure everything goes as planned, we need to unlink the obsolete workorders before creating the new workorders which would be incorrectly replanned. Other than that, the check on the `duration_expected` in the `action_update_bom` needs to be updated accordingly.

Enterprise: https://github.com/odoo/enterprise/pull/120709

opw-6285878
opw-6261738

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

Forward-Port-Of: odoo/odoo#269747

**Steps to reproduce:**
1. Install Accounting and l10n_be and switch to the Belgian company
2. In the settings, set the discount account (`708000`) on Customer Invoices under "Default Accounts" and enable analytic accounting
3. Go to [Accounting -> Configuration -> Analytic Accounts] and create 4 new accounts with "Project" plan (i.e 1,2,3,4)
4. Create a new invoice with two lines, each having 2 of the analytic accounts with 50% each.
5. Set the price to 1000 and a 10% discount for each line then save.
6. Edit the second line and set the discount to 20%.
7. Open the Journal Items tab

**Issue:**
 - When an invoice contains multiple lines with analytic distributions, changing the discount percentage on any line other than the first fails to correctly update the analytic distribution percentages on the corresponding discount journal items.
- The analytic account distribution splits the percentage evenly across both accounts event if they are not split 50/50

**Why this happens:**
- This occurred because `_compute_discount_allocation_needed` iterated over `self` to populate target changes. When only one line was modified, `self` contains that line only which is correctly updated with the new analytic distribution. Later in the execution in `_sync_dynamic_line`, particularly in https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move.py#L2263-L2274 The first line in `computed_needed` is what gets set in res, and subsequent lines only modify the field if it's monetary. So if the second invoice line is the one  updated, it will never override the `analytic_distribution` with the updated values, leaving stale values in that field.
- The code iterated directly over `line.analytic_distribution` dictionary keys (the account IDs) rather than its `.items()`. This caused it to ignore the individual percentage value splits (e.g. 60/40), accumulating the un-weighted full discount amount to each account ID. https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move_line.py#L1044-L1052

**Fix:**
- Change the processing loop  inside `_compute_discount_allocation_needed` from `self` to `self.move_id.line_ids` to calculate the correct `analytic_distribution` across all records.
- Applying the factored weight ratio (`amount * (percentage / 100.0)`) to `distribution_totals`

opw-6362084

Forward-Port-Of: odoo/odoo#279977
Forward-Port-Of: odoo/odoo#275070

Steps:
- Install sale_management
- Make sure you have 100 quotations with 1 activity each
- Open activity view
- Default pager displays `1-100/100`
- Activity count display `To-do 80`

ActivityController uses `useModel` which passes the raw `component.props` to
`model.load()`, including the limit from `ir.actions.act_window` (default 80).
This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`,
overriding `ActivityModel.DEFAULT_LIMIT` (100).

The records list was not affected because `RelationalModel._getNextConfig` never
reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100
records correctly. But `fetchActivityData` used 80, causing a mismatch between
the records shown and the activity counts in the column headers.

```js
export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"];
```

The fix strips `params.limit` in `ActivityModel.load()` before passing params to
`fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager
`onUpdate` handler calls `fetchActivityData` directly with its own `params.limit`
and is not affected.

However, `ActivityController` never forwards `limit` to the model. This
is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking
into account actions's limit. To fix this we have to add the limit via
`this.props.limit`, as `ListController`.

`useModelWithSampleData` already had the correct behavior by calling
`model.load(getSearchParams(props))` which filters out non-search params like
limit. In 19.0 useModel was updated to do the same, so the issue does not
exist there.
Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697

opw-6281125

**Steps to reproduce:**

- Install l10n_pl_edi and enable Allow KSeF integration from 
  **Accounting** settings. 
- Switch to a Polish company.
- Create an EU customer with a valid VAT number.
- Create a sale order containing a service product taxed 
  with 0% Steel (or any tax that has a tag of K11).
- Confirm the sale order and create a down payment invoice. 
- Send the invoice to KSeF and inspect the generated XML. 

**Observed behavior:**

The generated KSeF XML does not contain the `P_13_8` field. 

**Cause:**

For invoices involving the tax of tag `K11` (mainly these taxes are used for the supplies 
that are outside the territory of Poland), the value corresponding to `P_13_8` was not 
being assigned during XML generation, causing the tag to be omitted from the exported 
KSeF document.

**Fix:**

Populate the value of `P_13_8` during KSeF XML generation for invoices, ensuring the 
field is correctly included in the exported XML. 

This PR updates the computation of tag `P_13_10` with its test case to ensure consistency 
with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

**opw**-6294181

When a product carrying a multi-select (no_variant) attribute is added to an order by scanning its barcode, the extra price of the selected attribute value was dropped and the product was added at its base price.

The order line total is computed from `price_unit` alone. The `price_extra` of a no_variant attribute is never included in the variant price (a "multi" attribute requires create_variant="no_variant"), so it only reaches the total once folded into `price_unit`. `addLineToOrder` did that fold-in only when the product was not scanned (`!isScannedProduct`).

That guard was added to avoid counting the extra price twice when scanning an "always" variant barcode, whose extra is already part of its price. Since then, the extra price reaching this block is filtered to no_variant values only, both in the configurator and in the direct-variant branch, so an "always" extra can no longer reach it and the guard now only drops legitimate no_variant surcharges.

Remove the guard so the no_variant extra price is always applied.

Steps to reproduce:
- Create a product with a multi-checkbox attribute whose value has an extra price, and give the product a barcode.
- Open the PoS and scan the barcode.
- Pick the attribute value in the configurator and validate. => The extra price is not added to the order line.

opw-6413924

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

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