Currently, an error occurs when a user previews a canceled subscription order.

**Steps to Reproduce:**
 - Install `sale_subscription` module.
 - Go to `Subscriptions` and create a `subscription order` with:
    - a `subscription product`,
    - a `recurring plan`,
    - an `Until` (end date) value.
 - `Cancel` the subscription order.
 - Click `Preview`.

`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

When previewing a subscription order, the portal view is rendered. During rendering, the 
subscription portal template is used, which computes tax values and requires calculating the 
next invoice date based on the recurring plan's billing period. However, for canceled 
subscription orders, next_invoice_date is False because it is only set when the order is in 
the sale state. As a result, an error is raised [2].

This commit ensures that only subscription orders in the sale state use the subscription 
portal template. Canceled subscription orders use the default sale order preview, similar 
to orders in the draft and sent states. This is appropriate because canceled subscriptions 
are not correctly displayed in the subscription portal, and they should not attempt to 
render the subscription-specific portal view.

[1]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/controllers/portal.py#L686-L687

[2]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/models/sale_order.py#L2172-L2175

sentry-7579114635

Forward-Port-Of: odoo/enterprise#122287

Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle.

Steps to reproduce:
-------------------
* Open shop
* Make an order using the customer account for a customer, don't invoice it
* Refund one of the order using the customer account, don't invoice it
* Make a new order using the customer account
* In the customer list, find the customer used and select "Settle Orders"
> The 2 orders are present in the list

Why the fix:
------------
Originally the list would only show the orders for chich the customers have due (>0).
https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8

But recently the code we also see the refunds in the list as well.
https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0.

So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal.
* Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer.
* Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s)
and invoice them, either settling the order but that means that now there's money deposited on the customer account.

Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either.

Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out.

We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle.

opw-6170830

Forward-Port-Of: odoo/enterprise#117725

### Steps to reproduce:

- In the settings Enable: Multi-steps Routes, Packages
- Put your warehouse in delivery in 2-steps
- On the Pick operation type in the barcode tab disable: "Allow extra products"
- Create two storable products P1 and P2
- On P2 > On hand > Update Quantity > New
- Create a new line in WH/Output with a package POOK for 1 unit
- Create a new internal transfer for 1 unit of P1 using the pick operation type so that the picking goes WH/Stock -> WH/Output
- Set the quantity of the move to 1 unit and go to the barcode app
- Open the Pick > Scan WH-STOCK > Scan P1 > Scan POOK
#### > An error is raised: This package contains extra products and extra products are not allowed on this operation.
#### Expected behavior:
The package should be set as result package.

### Cause of the issue:

In the `_processPackage`, a check that is done to ensure that the package scan will not add extraproduct to the picking if this operation is not allowed:
https://github.com/odoo/enterprise/blob/5e4c8ecb0c644e21755570ed59cd8f6e9f618c8a/stock_barcode/static/src/models/barcode_picking_model.js#L2024-L2035
Unfortunately, this check is done just before a possible usage of the package as package dest. And, in that case, since we do not try to add any product to the picking the check is irrelevant anyway.

opw-6303969

Forward-Port-Of: odoo/enterprise#122782
Forward-Port-Of: odoo/enterprise#121789

## Issue
When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`)
3. Create a sign request and send it to Marc Demo
4. As Marc Demo, sign the request
5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.**

## Fix
This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed.

## Note to reviewer
The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired.

opw-6251702

Forward-Port-Of: odoo/enterprise#122740
Forward-Port-Of: odoo/enterprise#120740

## Problem
When multiple Default Prompts are configured for the same AI Agent and
interface key, clicking the "Ask AI" button raises a ValueError.

## Cause
The `_get_composer_from_key_and_model` method searches for composers matching
an interface_key and model, but doesn't limit the results. When multiple
Default Prompts exist for the same agent, the search returns multiple records,
causing a singleton error when accessing `ai_agent_id`.

## Steps to Reproduce

[[Video](https://drive.google.com/file/d/1yMAmX4RuevS0vH07qex2V0fMAiLrtJBg/view?usp=sharing)]
1. Go to AI > Configuration > Default Prompts
2. Create a new Default Prompt with Odoo Agent
3. Click the Ask AI button in the top-right corner
4. Error: ValueError: Expected singleton: ai.agent(2, 1)



## Fix

Replace the two-step search with a single search using an `OR` domain:

- Search both model-specific and generic Default Prompts in one query.
- Order the results with `focused_model_id desc` so model-specific prompts are preferred over generic ones.
- Return only one record using `limit=1`.

This preserves the previous behavior while preventing singleton errors.

---
opw-6323764

Forward-Port-Of: odoo/enterprise#121609

## Current behavior:
In the Project's app, switch to Gantt chart's view, when changing the deadline of a single task by shrinking its right edge, the server throws `ValueError: max() iterable argument`` is empty when calling end_date = max(candidates.mapped(stop_date_field_name)).

## Steps to reproduce:
1. In version 19.0 and above, install Project app
2. Create a project and only 1 single task
3. Switch to Gantt chart view
4. Try changing the deadline of a task by dragging its right edge
5. Observe that extending the task's deadline by dragging to the right works fine, but shrinking the deadline by dragging to the left will cause server to throw RPC_ERROR: Odoo Server Error and ValueError: max() iterable argument is empty.

## Cause of the issue:
- A task with NO successors will cause candidates gathered via dependency_inverted_field_name to be empty.
- The empty candidates recordset then get called by max(candidates.mapped(stop_date_field_name)), which is the reason causing error message ValueError: max() iterable argument is empty.

opw-6283566

Forward-Port-Of: odoo/enterprise#121517
Forward-Port-Of: odoo/enterprise#120375

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

Forward-Port-Of: odoo/enterprise#122742
Forward-Port-Of: odoo/enterprise#122035

Issue
-----
There are 2 issues with USPS rest:

1. USPS packagings do not have their size UOM displayed. This leads to confusion as users input in inches but the dimensions are treated as feet.

2. USPS returns the same rate regardless of the package type.

Steps to reproduce
-----
- Set USPS up
	- Open the Package Type form > go to its' Dimensions tab

> Issue 1

- Set USPS up (domestic)
	- Select a `Domestic Rating Indicator` (eg LF - Flat Rate Box)
- Create a SO with some product
- Open the delivery widget and add a rate with USPS
	- Discard the changes
- Go to the delivery method and change the rating (eg SP - Single Piece)
- Go back to the SO
- Open the delivery widget and add a rate with USPS

> Issue 2, rate is the same as before

Issue 1
-----
By default, there is no displayed UOM on the form because of

https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/stock_delivery/models/stock_package_type.py#L20-L33

We can change this behaviour for USPS specifically as done in Envia

https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_envia/models/stock_package_type.py#L37-L46

Issue 2
-----
In `usps_rest_rate_shipment`, we request rates for every package of the delivery, which we receive as lists. We then iterate over the list to find the rate matching the `mail_class`. The problem is that this only filters over whether the delivery is domestic or international. We don't filter based on the actual service selected on the carrier (`usps_domestic_rating_indicator` for domestic and `usps_international_rating_indicator` for international).

https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_usps_rest/models/delivery_usps.py#L224-L236

-----
Ticket:
opw-6224918

Forward-Port-Of: odoo/enterprise#120789
Forward-Port-Of: odoo/enterprise#120594

Version: 19.0

`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.

- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.

- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.

- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.

taskid- 6329037

Forward-Port-Of: odoo/enterprise#121878

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

Forward-Port-Of: odoo/enterprise#122157
Forward-Port-Of: odoo/enterprise#120219

Steps to reproduce
1. Create two customer invoices that share the same VAT tax, with a payment term granting an early payment discount.
2. Create one bank statement line whose amount equals the sum of both invoices' discounted totals.
3. From the bank reconciliation widget, select both invoices and validate in a single batch reconciliation.
4. Open Accounting > Reporting > Tax Return, switch the variant to "Group by: Account > Tax".

Issue
The cash-discount expense row shows a Net base column equal to twice the real
discount base. The Tax column is correct.

The bank-statement reconciliation paths (set_line_bank_statement_line,
set_batch_payment_bank_statement_line, _reconcile_payments) loop over each
invoice and call _apply_early_payment_discount one invoice at a time. Each
call writes one discount base line and one discount tax line on the resulting
bank entry, so when two invoices share the same tax the bank entry ends up
with two pairs carrying the same (account, partner, currency,
tax_repartition_line_id, tax_ids).

The SQL that feeds the tax report at
https://github.com/odoo/odoo/blob/d7d0efd39a65bfb6fee307b661cd2523a6b8231d/addons/account/models/account_move_line_tax_details.py#L100
matches every base line of a tax with every tax line of that tax inside the
same move. With two pairs sharing one tax that turns two rows into four, and
SUM(base_amount) doubles. The Tax column does not double because the same SQL
redistributes each tax line's recorded amount across its matched rows so the
totals still add back to the original tax.

The payment register flow does not have this problem because it calls
_get_invoice_counterpart_amls_for_early_payment_discount once with every
invoice, and that helper already collapses duplicates with the merge key at
https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/account/models/account_move.py#L5082-L5093

opw-6199906

Forward-Port-Of: odoo/enterprise#122747
Forward-Port-Of: odoo/enterprise#117743

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

Issue:
Replacing an icon removes style classes applied to the original icon,
such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`.

This issue was introduced by [commit], which stopped preserving
image-specific classes when replacing an image with an icon. This
behavior is appropriate in the backend editor, where icons do not
support these styling options. However, the same logic also affected the
website builder, where icons support the same styling options as images.
As a result, these classes were unnecessarily removed when replacing an
icon.

Steps to reproduce:
1. Add an icon with style classes such as `rounded`, `rounded-circle`,
   `shadow`, or `img-thumbnail`.
2. Replace the icon.
3. Notice that the style classes are removed from the new icon.

Fix:
Preserve these style classes when replacing icons in the website
builder, allowing the newly selected icon to retain the existing visual
styling.

[commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab
task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832)

Forward-Port-Of: odoo/odoo#273598
Forward-Port-Of: odoo/odoo#265496

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

similar fix: https://github.com/odoo/odoo/pull/181220

- On a kanban view, click "New" to open a quick create record;
- On a many2one field, type a value and click "Create and edit...";
- A dialog opens to create the related record;
- From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one;
- Change tab in the browser.

Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user.

This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed.

opw-6357255

Forward-Port-Of: odoo/odoo#274054

Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
   - Apply To: Category
   - Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.

Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.

Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.

This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.

Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.

opw-6346422

Forward-Port-Of: odoo/odoo#273596

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

Steps to reproduce:
----------------------
1. Install `mrp`, create two warehouses A and B.
2. Create a storable product with Track Inventory True.
3. Create a Manufacturing Order for 10 qty with(Miscellaneous tab):
   - Components location = Warehouse A (raw materials)
   - Finished product Location = Warehouse B
4. Confirm the MO.
5. Open the Forecast report for the product.

Issue:
-------
- Warehouse B forecast shows the MO under the replenishment detail
  lines (correctly, via `location_dest_id`) but the header displays
  "0 Incoming", "0 Outgoing", "0 Forecasted".
- Warehouse A forecast incorrectly shows "10 Incoming" in the header,
  even though no finished product is going there.

Cause:
-------
- When we create MO for finished Product move is created
if there no `location_final_id` then it set mo.warehouse_id.lot_stock_id` 
as the `location_final_id`.

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/stock_move.py#L466-L467

which is introduce in this [commit](https://github.com/odoo-dev/odoo/commit/95ce0ed97a160e3465c313ed6b9bef938d61586b)

- The problem is that `mo.warehouse_id` is a related field computed from
`mo.location_src_id.warehouse_id`

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/mrp_production.py#L110

- this warehouse that supplies the **raw materials** (Warehouse A). 
When the user sets `location_dest_id`
to Warehouse B's stock, `mo.warehouse_id` is still Warehouse A, so
`location_final_id` is stamped with Warehouse A's stock location.

- `product.incoming_qty` (used by the forecast header) evaluates non-done
moves using `location_final_id` first (if set), falling back to
`location_dest_id` only when `location_final_id` is False:

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/models/product.py#L331-L335

- Because `location_final_id` is set (to WH-A) and non-False, the
second clause (which would pick up `location_dest_id` = WH-B) is never
evaluated. The result: the move is counted as incoming in Warehouse A
and ignored in Warehouse B.

- The forecast detail *lines* use only `location_dest_id` to classify
moves, so they correctly show the MO as incoming for Warehouse B —
producing the inconsistency the user observes.

https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/report/stock_forecasted.py#L42-L46

Fix:
----
- Replace `mo.warehouse_id.lot_stock_id.id` with `mo.location_dest_id.id`:

- `location_final_id` is meant to track where the product ultimately
ends up when the immediate destination is intermediate. The correct
"final" location for a finished-product move is exactly what the user
chose as `location_dest_id` on the MO — not the stock location of the
warehouse that happens to supply the raw materials.

- For the standard single-warehouse case, `mo.location_dest_id` equals
`mo.warehouse_id.lot_stock_id`, so the behaviour is unchanged. For
cross-warehouse MOs (destination = WH-B), `location_final_id` is now
stamped with WH-B's stock, making `product.incoming_qty` and the
forecast header consistent with the detail lines.

----

opw-6294479

Forward-Port-Of: odoo/odoo#270089

## Steps to Reproduce:
1. Install the sale_margin module.
2. Sales > Configuration > Templates.
3. Create a template with type 'Section', and add a section line.
4. Create a Sales Order, click Add Section, and select the created template.

## Error:
`ValueError: Expected singleton: res.currency()`

## Cause:
The `_prepare_order_line_values()` method mistakenly stores the converted purchase price in the `currency_id` field instead of `purchase_price`. When these values are used to create a sales order line, leaving currency_id unset. - [1] As a result, the onchange later fails when it expects a valid currency. - [2]

## Fix:
Pass the correct field value of `purchase_price` instead of `currency_id`.

[1]: https://github.com/odoo/odoo/blob/f2f656371f81683ee3fe558932df53a2d0c5d374/addons/sale_management/models/sale_order_template.py#L346-L350
[2]: https://github.com/odoo/odoo/blob/f2f656371f81683ee3fe558932df53a2d0c5d374/addons/sale_margin/models/sale_order_line.py#L76

opw-6347869

**Problem:**
On a planned work order, changing only the start date (e.g. in the planning gantt edit dialog) corrupts the expected duration instead of just shifting the end date. The duration drifts to a wrong value, and in some cases (e.g. dependent work orders) collapses to 0.

**Steps to reproduce:**
1. Plan a work order on a workcenter (start, end, expected duration).
2. Open it and change only the start date to a time that is not on a working-hours boundary.
3. The end date updates, but the expected duration is now wrong.

**Expected behavior:**
Changing the start date replans the work order: the duration is kept and the end date is recomputed from it. This is how 19.0 behaves and how dragging the pill in the gantt already behaves.

**Cause of the issue:**
Changing date_start triggers _onchange_date_start, which recomputes date_finished from start + duration via plan_hours. That cascades into _onchange_date_finished, which recomputes duration_expected from the dates via get_work_duration_data. Since the resource calendar refactor in 19.2, plan_hours and get_work_duration_data are no longer exact inverses around the work order's own planned slot, so the round trip drifts the duration.

**Fix:**
Only recompute the duration when the end date was edited on its own. When date_finished already matches the planned end for the current duration, it was merely derived from the start change, so the duration is kept. This keeps the duration authoritative when moving the work order while still recomputing it on a genuine end-date resize.

opw-6231569

Forward-Port-Of: odoo/odoo#271508

discuss_channel_public_tour uploads two files and waits for their attachment cards before clicking Send. The card selectors were not scoped to the composer, and message attachments render the exact same card. The tour runs twice per test: on the second run, the message posted by the first run already displays identical text.txt and image.png cards, so the waits matched immediately and the tour never waited for its own uploads (build logs show the steps passing before the upload requests even reached the server).

Send was then clicked during the upload window. The trigger can catch the button enabled from a render preceding the upload registration, while processMessage checks the live model, still finds an attachment uploading, and silently drops the message. The persistent "cheese" message step then timed out.

Scope the selectors to the composer so the tour genuinely waits for its own uploads; this also makes the guest access token check read the composer image instead of the first run's message image.

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