Steps to produce:
---
- Install `website_sale` module.
- Enable ` Units of Measure & Packagings `and `Comparison Price` features from settings.
- Create product > set sales price as 5 and Compare to Price as 12.
- From the sales tab, under Upsell & Cross-Sell > set Packagings as pack of 6.
- Go to the shop page on eCommerce, and add your product via the shop page (this should open the product configurator).
- Change the UOM from the radio.

Issue:
---
- Changing the UOM doesn't change the strikethrough price.

Root cause:
---
- At [1], The `_get_strikethrough_price` method was not receiving the selected uom parameter, causing it to compute the compare_list_price based on the product's base uom instead of the user-selected uom.

Solution:
---
- Pass `uom` parameter from `_get_basic_product_information` to `_get_strikethrough_price`
- Apply uom conversion to compare_list_price when the selected uom differs from the product's base uom.
- Also fix pricelist base price calculation to use the selected uom.
- Update the JS logic to refresh the strikethrough price when the uom
  changes.

[1]https://github.com/odoo/odoo/blob/bfcb22256226ae056e934e2f9e498e8cea4d2f63/addons/website_sale/controllers/product_configurator.py#L101-L154

Before:
---
<img width="974" height="321" alt="image" src="https://github.com/user-attachments/assets/f360d730-bedf-4898-ba22-c47ea8fa1df7" />

After:
---
<img width="977" height="321" alt="image" src="https://github.com/user-attachments/assets/79d66143-959c-4f39-9272-437cb768837e" />


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

Forward-Port-Of: odoo/odoo#263556

### Issue before this commit:
In accrual reports (e.g., "Bill To Receive", "Billed Not Received", "Invoices To Be Issued", and "Invoices Not Delivered"), when grouping the list view by fields such as Vendor, the group header totals for the "Received", "Billed", and "Amount" columns display 0.00 even if the interanl lines of the group are not 0.00.

### Steps to reproduce the issue:
1. Download Purchase Accounting and Sale Accounting
2. Go to one of this pages: Billed Not Received, Bill To Receive, Invoices To Be Issued, and Invoices Not Delivered
3. Ensure the view is in its default grouping (grouped by Vendor or Customer)
4. Observe the group header rows for the Received (or Delivered), Billed (or Invoiced), and Amount columns. They all display 0.00
5. Expand a group that contains records with values greater than zero
6. Observe that the individual records populate correctly, but the aggregated group header row continues to display 0.00.

### Cause of the issue:
The commit ddc1b681656ea8c70f3231cda20b5a58b9ff7dd6 adapted the code to retrieve the new accrual reports but attempted to fetch grouped records using group[0].id as the dictionary key, while the grouped() method actually used the recordset object as the key. This mismatch caused the dictionary lookup to fail, resulting in 0.00 sums. https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/account_accountant/models/analytic_mixin.py#L40-L48

### Reason to introduce the fix:
This fix restores the core analytical utility of the accrual reports, which are crucial for accountants during period-end closings to evaluate totals at a glance.

opw-6232273

Forward-Port-Of: odoo/enterprise#118399

### Issue
When setting the partial deductibility percentage to 99% on a vendor bill line, the system incorrectly treats it as 100% deductible and completely ignores the non-deductible part

Additionally, changing the deductibility percentage on a line with taxes does not trigger an update of the
non-deductible tax journal items, leaving the private part taxes unchanged

### Cause
In the tax recomputation mechanism, `float_compare` was wrongly configured with `precision_rounding=2` instead of `precision_digits=2` when checking the `deductible_amount` field

This rounding error caused 99.00 to be evaluated as equal to 100.00, skipping the creation of the non-deductible line

Furthermore, `_sync_tax_lines` relies on `get_base_line_tracked_fields` to detect modifications that require a tax recalculation

This tracked field list only included price, quantity, and discount. Modifying the deductibility percentage did not trigger any sync, preventing the non-deductible tax lines from adjusting

### Fix
To fix the synchronization, `deductible_amount` is added to the tracked fields for invoices
This straightforward approach is preferred here for simplicity
However, a more restrictive condition may be needed for example only check it on lines with taxes

### Steps to reproduce
- Install `account`
- Create a Vendor Bill  (Price: 1000$, Taxes: 15%, Professional %: 50)
- Check the Journal Items tab to see the Private Part line at 500$ debit and Private Part (taxes) line at 75$ debit
- Change the Professional % field on the invoice line to 75 Before the fix, the Private Part (taxes) line remains at 75$ debit
- Change the Professional % field on the invoice line to 99 Before the fix, the private part lines completely disappear instead of adapting to 1%

opw-6245909

Forward-Port-Of: odoo/odoo#267427

# How to reproduce
- Go into any form view of a model with a chatter (e.g. Quotation)
- Add multiple long log notes. You need to be able to scroll enough to not see the last log note
- Click edit on the last log note
- Scroll down to the bottom

# The problem
An empty rectangle is displayed next to the log note in edit mode.

# Cause
The rectangle comes from the NavigableList Component, which is the list that displays suggestions when typing things like "@" or "#" : https://github.com/odoo/odoo/blob/1fd44c3bb11a79d5b6aa72bf7de5a83e6c45be46/addons/mail/static/src/core/common/composer.xml#L137

This components uses the `usePostion()` hook, which purpose is to try to find the most appropriate place to put the element. It will try different postions (e.g. on the left, below, above, etc.) and will pick the most appropriate one. It will then adjust the element's style to position it correctly. It is possible to ask for a preferred position using the options given to the hook. This position will be prioritized over the others if it is suitable. In the case of the NavigableList of the chatter, we give it either 'bottom-fit' or the 'top-fit' positions, wich means it will prefer to be displayed above or below the message : https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/mail/static/src/core/common/composer.js#L449-L459

But in our case, when we scroll back up, the position of the rectangle stays on the left, even though the below space is available. That is because of this commit that introduced a memorization of the last solution :
https://github.com/odoo/odoo/commit/b2b8d2dbb8396d86492a3089db9b1b1545c8f13b https://github.com/odoo/odoo/blob/f2434aac74324a65ccd81aa18c7b0e8318e59fde/addons/web/static/src/core/position/position_hook.js#L59-L61

This means that when we scroll down, the bottom positions fails and so the left one is defaulted to. Since the position is memorized, it stays on the left. The issue with this left position is that another commit introduced some logic that made it so if the position is not "top" or "bottom", then we set the element's height to some value : https://github.com/odoo/odoo/commit/702748e2c8e895d372d07f9aeff273282d1b1a99 https://github.com/odoo/odoo/blob/f2434aac74324a65ccd81aa18c7b0e8318e59fde/addons/web/static/src/core/position/utils.js#L120-L124

And setting the height of the NavigableList makes it so it displayed even when there are no suggestions inside, because the hiding mechanism of the suggestion list relies on the fact that when there are no suggestions, the div is empty and has no height, so it is hidden.

# Propose solution
We introduce a settings in the options that will allow to skip the memorization of the last position. Since the left position will never be set in the options, no height will be defined.

opw-6172407

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

### Steps to reproduce:

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

### Current behavior:

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

### Cause of the Issue:

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

opw-6237834

Forward-Port-Of: odoo/enterprise#119114

Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased.

For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`.

However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision.

This is inconsistent with sales: sale order lines preserve very small unit prices correctly.


**Current behavior before PR:**

A product with `standard_price = 0.001235` keeps that value on the product form.

When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost.

The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line.

**Desired behavior after PR is merged:**

Purchase order lines preserve the computed unit price precision, just like sale order lines already do.

A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision.

---

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

Forward-Port-Of: odoo/odoo#267941

### Steps to reproduce:
- Download "Website" app
- In the portal's "/my/account" address form, enter a "Company Name"
- Click "Save" to submit the form
- Reload the page and check if the company name was saved
> Company name isn't updated

### Cause of Issue:
`_create_or_update_address()` method was passing the 'parent_name' field directly through the main `partner_sudo.write(address_values)` call.
https://github.com/odoo/odoo/blob/391cec39b6048ad4f49015fd67888895dc176ee5/addons/portal/controllers/portal.py#L564-L571 Since `parent_name` is a readonly related field (related to `parent_id.name`), the write operation would fail silently to update it, creating orphaned changelog entries instead of properly updating the parent company entity.

### Fix:
Since the update of contact forms in v19.1, we can't just edit the "Company Employer" field without assigning an actual partner (existing or create new). The solution here was to add a case to account for when the portal user is an individual adding a "Company Name" for the first time.

opw-6115158

In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors.

This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow:
1. Add the unmodified source page directly to the `PdfFileWriter`.
2. Retrieve the newly created, writable output page.
3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page.

[^1]: https://github.com/py-pdf/pypdf/pull/3638
[^2]: https://github.com/py-pdf/pypdf/pull/3669

Forward-Port-Of: odoo/odoo#268865
Forward-Port-Of: odoo/odoo#267958

In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors.

This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow:
1. Add the unmodified source page directly to the `PdfFileWriter`.
2. Retrieve the newly created, writable output page.
3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page.

[^1]: https://github.com/py-pdf/pypdf/pull/3638
[^2]: https://github.com/py-pdf/pypdf/pull/3669

Forward-Port-Of: odoo/enterprise#119694
Forward-Port-Of: odoo/enterprise#119239

When a calendar event has multiple attendees, `_get_contact_details_description` picks the first non-organizer partner from a set-based recordset to render under "Contact Details" in the event description. The recordset is built from `partner_ids_from_attendees`, a set whose iteration order depends on Python's hash seed, so the displayed contact is effectively random and not controllable from the UI.

Restrict the "Contact Details" block in `_get_contact_details_description` to events with exactly one non-organizer attendee (1-on-1 meetings). For group meetings the block is omitted entirely, since any single attendee picked from a larger group is arbitrary by construction.

Steps to reproduce:
1. Go to Calendar > New
2. Add 3+ attendees (e.g. Alice, Bob, Charlie)
3. Save the event
4. Check the Notes tab in the event form

=> One random attendee's contact info appears under "Contact Details"

Ticket [link](https://www.odoo.com/odoo/project.task/6035192)
opw-6035192

Forward-Port-Of: odoo/odoo#258901

Currently, error occurs when user removes date on Accrued Expense Entry wizard.

Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.

Error:
```
  File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
    if not record.reversal_date or record.reversal_date <= record.date:
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'

```

Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.

Solution:
- Added a conditional check for `date` before the date comparison.

[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67

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

Forward-Port-Of: odoo/odoo#265997
Forward-Port-Of: odoo/odoo#262568

The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations:

1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order

2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000.

3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans.

Benchmark (page 1 load):

_prepare_tasks_values (milestone + count, excludes lazy main search):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.294s    | 0.230s   |
| 1,500,000 |      2,000 | 0.511s    | 0.222s   |
| 3,000,000 |     12,000 | 1.129s    | 0.258s   |
| 6,000,000 |     24,000 | 2.388s    | 0.261s   |
| *6,000,000|     24,000 | 2.015s    | 1.976s   |

*6M measured while navigating last page (full count triggered).

Main search query (ORDER BY fix):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.525s    | 0.013s   |
| 1,500,000 |      2,000 | 0.685s    | 0.017s   |
| 3,000,000 |     12,000 | 1.479s    | 0.040s   |
| 6,000,000 |     24,000 | 3.121s    | 0.043s   |
| *6,000,000|     24,000 | 7.562s    | 3.781s   |

Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5
Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b
*6M measured while navigating last page (high offset).

- opw-5478903

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5

Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised

Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
    - Clear the Warehouse field (set it to False)

- Create a purchase order:
    - Set "Deliver To" to the operation type with no warehouse
    - Add any product
    - Try to confirm the PO

Problem:
A traceback is triggered:
```   return self.parent_path.startswith(other_location.parent_path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```

`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False

Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).

opw-6253817

Forward-Port-Of: odoo/odoo#268317

## Issue
When using a prefix containing a time-based placeholder (`%(h24)s`, `%(h12)s`, `%(min)s`, `%(sec)s`) with *Subsequences per date\_range*, the time information are missing and consistently set to 0 when interpolating the prefix.

## Steps to reproduce
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, update the `sale.order` sequence:
    - Prefix: `S/%(y)s/%(month)s/`
    - Suffix: `/%(h24)s/%(min)s/%(sec)s`
    - Tick the *Use subsequences per date_range* checkbox and set a range for the current month
3. Create and confirm a SO
4. **The name of the SO correctly contains the Quotation date in the prefix, but the suffix is set to /00/00/00, even though the quotation date contains time information.**

## Cause
Commit https://github.com/odoo/odoo/commit/f7c330d83cc3 sets the `ir_sequence_date` to a `datetime.date` object in `IrSequence._next`. This leads to the time information missing from the interpolation dict:

https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/addons/base/models/ir_sequence.py#L211-L214

## Fix
The context key `ir_sequence_date` should be set to a `datetime.datetime` object to correctly interpolate the time information in the prefix/suffix of a sequence. To do so, the `tzinfo` needs to be drop for the date to be interpretable by the `fields.Datetime.from_string` method:

https://github.com/odoo/odoo/blob/d58f4ed332af35f6de26a93f07adf05368731e20/odoo/orm/fields_temporal.py#L239-L244

The time is not cast to a specific timezone (e.g., UTC) before dropping the tzinfo, as doing so would lead to incoherent time information from the user's perspective. For example, creating a SO at 13:00 in Brussels (UTC+2) would result in  `11` being used as the hour to interpolate the `%(h24)s` placeholder.

opw-6104485

Forward-Port-Of: odoo/odoo#260782

**Step to reproduce**
Reproducible in single app

The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
            "product_id": no_variant_product_tmpl.product_variant_id.id,
            "name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant: https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174 Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634 that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126

**Additional information**
Since this [commit](https://github.com/odoo/odoo/commit/b8ebb26553f8170061debc7532606fd4777f0fcd#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R90) product_no_variant_attribute_value_ids was directly added in the purchase module.

breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265 
runbot-242362

Forward-Port-Of: odoo/odoo#268016