Opening the customer list with a few hundred partners freezes the UI for several seconds on a slow device (~300ms on a desktop, 5.6s with a 6x CPU throttle in the Chrome profiler).

Each `PartnerLine` instantiates a full `Dropdown` for its "≡" menu. Setting up a `Dropdown` registers about ten lifecycle hooks (`useDropdownNesting`, `useNavigation`, `useDropdownGroup`, `usePopover`, `useEffect`, ...), and each hook registration eagerly allocates two `OwlError` objects to keep a stack trace. Multiplied by hundreds of rows, this dominates the render: ~60% of the click task is spent constructing errors for menus that will never be opened.

Render a plain button per row instead and only mount the `Dropdown`, driven by a `useDropdownState`, once that button is clicked. The `Dropdown` opens its popover on mount when its state is already open and is unmounted again when it closes. The placeholder button keeps the classes the `Dropdown` would add to its toggler so the DOM, the styling and the tour selectors (`button.dropdown`) are unchanged.

opw-6453848

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#287564
Forward-Port-Of: odoo/odoo#285974

When the closing journal entry of a session is unbalanced, `_process_session_validation` in point_of_sale rolls back the transaction and returns the "Force Close Session" wizard action, which `_validate_session` returns to the user so the difference can be posted on a chosen account.

The pos_stock override of `_process_session_validation` calls `super()` without returning its result. The action is dropped, `_validate_session` carries on, and the session is written as `closed` while the rolled-back entry no longer exists: `move_id` is empty, the orders stay in `paid`, `cash_real_transaction` stays at 0 and the cash difference is never posted. The user sees a successful close and nothing in accounting.

Steps to reproduce:
- Use a stock configuration whose costs yield a rounding difference on the closing entry (e.g. AVCO products with a sale and a return whose unrounded costs round differently when split between the expense and valuation lines).
- Close the session from the PoS.
- The session is closed, no journal entry exists, and no wizard was shown.

Return the result of `super()` so the wizard is shown as in 19.0.

opw-6543863

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

Forward-Port-Of: odoo/odoo#287618

Steps to reproduce:
- Create a pricelist "TAKEAWAY" with a fixed price of 10.00 on a product whose sales price is 20.00
- Create a preset "TAKEOUT" and set its pricelist to "TAKEAWAY"
- Add to that product an attribute with variant creation "Never", with a value carrying an extra price of 1.00
- In the POS, switch to the preset "TAKEOUT" and click the product

Issue:
The configurator advertises the attribute value with a "+ $ 1.00" badge, but that extra is charged nowhere: the title of the popup and the resulting order line both stay at the 10.00 of the pricelist.

Cause:
A fixed pricelist rule replaces the whole price of the product, the attribute extra prices included: _compute_price on product.pricelist.item returns fixed_price and never reaches _compute_base_price, the only place where _get_attributes_extra_price is taken into account. getPrice is a faithful port of that and overwrites `basePrice + price_extra` with rule.fixed_price. The configurator, however, rendered its badges out of value.price_extra alone, without ever asking what the pricelist of the order does with it.

Fix:
Only advertise an extra price when the price of the product actually reflects it, the way website_sale already does with the show_extra_price of _get_additionnal_combination_info. Asking getPrice covers more than a fixed rule: a rule based on another pricelist recurses with no extra either, and a full discount leaves nothing of it. Combo items keep their badges, since computeComboItems adds their extras on top of the combo price, like _get_combo_item_display_price does.

opw-6528187


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

Forward-Port-Of: odoo/odoo#287740
Forward-Port-Of: odoo/odoo#286475

Steps to reproduce:
- Give a user PoS Administrator rights and no Accounting rights.
- As that user, open a session with cash control, sell something paid in cash and do a Cash Out.
- Close the register. The closing popup shows the expected cash (opening + cash payments - cash out); enter exactly that amount, the popup shows no difference.
- Open the closed session: its chatter says "Closing difference: -X", X being the cash out amount, and "Closing expected" is the amount before the cash out.

Issue:
The closing control data agrees with the user, but the closing message records a cash difference equal to the cash out.

Cause:
`_compute_cash_balance` sums `statement_line_ids` with the rights of the current user. Cash moves are `account.bank.statement.line` records, which `_inherits` `account.move`, so the account.move record rules apply to them too. For a PoS user the only such rule is `rule_invoice_pos_user` (`pos_order_ids != False`), and a cash move has no PoS order: unless the user is in `account.group_account_invoice`, their own cash moves are filtered out and `cash_register_balance_end` ignores them, while `get_closing_control_data` sums the lines in sudo.

Since da8be203ec32 PoS managers can create cash moves without any accounting group, which made this visible: in 18.0 cash in/out required `account.group_account_invoice`, whose `account_move_see_all` rule makes every move readable.

The values stored at closing are right by accident: `_validate_session` reads the lines in sudo just before, and the one2many cache is shared between the sudo and non-sudo environments of the same transaction. The message posted by `update_closing_control_state_session` runs in its own transaction and gets the filtered sum.

Fix:
Read the cash lines in sudo in `_compute_cash_balance`, as `get_closing_control_data`, `get_cash_in_out_list` and `_validate_session` already do. Users with accounting rights see all lines already, so nothing changes for them.

opw-6521591

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

Forward-Port-Of: odoo/odoo#287741
Forward-Port-Of: odoo/odoo#286308

Issue:
A customer who signs a quotation can delete the chatter entry containing the generated signed PDF. For quotations awaiting a wire transfer, this can remove the only retrievable snapshot of the signed quotation before the order is confirmed.

Steps to reproduce:
- Create a quotation requiring an online signature and payment.
- Sign it from the customer portal and select wire transfer.
- Delete the "Order signed by ..." entry from the portal communication history.

Cause:
The signing endpoint posts the generated PDF as a regular customer authored comment. Portal chatter allows customers to update their own comments, and deleting one clears its attachments, so the signed PDF is physically removed.

https://github.com/odoo/odoo/blob/e479111294b11058038defc31505cc81ac1f1821/addons/sale/controllers/portal.py#L348-L358

Solution:
Classify the signed document entry as an automated comment. This keeps it visible and attributed to the customer while ensuring that both the portal interface and backend message rules treat its content and attachment as immutable. Regular customer comments keep their existing behavior.

opw-6466029

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

Forward-Port-Of: odoo/odoo#286578
Forward-Port-Of: odoo/odoo#283595

Steps to reproduce:
- German PoS with Fiskaly TSS configured
- Set a customer that is an address contact (type invoice/delivery/other) on an order; such a contact has no name of its own, it is displayed with its parent's
- Close the session

Issue:
Closing crashes with "TypeError: 'bool' object is not subscriptable" and the session cannot be closed at all.

Cause:
_get_dsfinvk_cash_point_closing_data builds the DSFinV-K buyer block from partner.name, which is only guarded by "if partner := o.partner_id". res.partner.name is not required: the res_partner_check_name constraint only enforces it for type='contact', so an address contact stores NULL there and partner.name reads as False, which cannot be sliced.

Fix:
Fall back on complete_name - what the UI displays for those contacts, "Parent Company, Delivery" - and on a literal when even that is empty, since the buyer name is mandatory in the export. Reading name first leaves the exported value untouched for every partner that has one.

opw-6518336

Forward-Port-Of: odoo/enterprise#129709

Issue:
---
The ministock feature is not showing correct forecast on sale order lines due to miscalculation from different uom.

Steps:
---
1- Install `Sale` and `Purchase` apps without `stock`.
2- Create a product. Enable the track inventory.
3- Add `Pack of 6` to product's sale packagings.
4- Create a purchase order with 12 units. Confirm and receive.
5- Create a SO. Add a line with quantity = 3 and UOM = `Pack of 6`.

As you see the availability icon is green, which is not correct.

Also, by setting different uom for the product, the forecast quantities are calculated wrongly.

Cause and Fix:
---
1- Inside purchase implementation of `_compute_forecasted_without_stock()` all quantities are converted to `product.uom_id`. However `product_uom_qty` is already in product uom and shouldn't be converted again to product uom. This causes wrong forecast if product has a uom set and purhcase line use different.

2- In `QtyAtDateWidget.initCalcData()` `leftToDeliver` is based on line uom, however, `virtual_available_at_date` is based on product uom itself, causing wrong `forecasted_issue` calculation.

3- Also in the template, the uom name is not fetched correctly, which should be product uom name.

opw-6384812

Problem:
A time off request is saved with a duration of 0 days instead of 1 day
as soon as an automation rule on Time Off has an action that creates an
activity.

Cause:
`_compute_field_value` runs the actions while the fields of the
computation it wraps are still protected and not written yet. On
`hr.leave` the actions run from a computation nested in
`_compute_date_from_to`, so `date_from` is empty when the activity
notification reads `display_name`, and `_compute_duration` stores 0.
Setting `date_from` afterwards does not mark `number_of_days` to compute
again since it is protected.

Solution:
Extract the snapshot `_filter_pre` already does into `_keep_to_compute`
and wrap the post filter and the actions with it, so the fields
depending on the running computation stay to compute. Same treatment as
488419a5ca49 (odoo/odoo#243611) on the pre filter.

Steps to reproduce:
- Enable the developer mode.
- Go to Settings > Technical > Automation Rules and create a rule on the
  Time Off model with the trigger On create and edit.
- Add an action of type Create Activity, set its Responsible to another
  user, and save.
- Go to Time Off > New, pick an employee and a time off type, and
  request one working day.
- Observe that the request shows a duration of 0 days.

Ticket [link](https://www.odoo.com/odoo/project.task/6498783)

opw-6498783

Forward-Port-Of: odoo/odoo#287536
Forward-Port-Of: odoo/odoo#286791

Issue:
Colombian child contacts linked to a NIT company are displayed with their standalone name instead of "Company, Contact". Searching Contacts by the company name consequently returns the company but not its child contacts.

Steps to reproduce:
- Create a Colombian company with NIT
- Add a child contact or address to that company
- Filter Contacts by the company name
- Observe that the child is displayed separately and is not returned

Cause:
The Colombian `is_company` computation classifies every partner with a Colombian NIT and qualifying obligations as a company: https://github.com/odoo/enterprise/blob/911686a31d5d3c1539d0dff7d16edf1ce9b101ca/l10n_co_edi/models/res_partner.py#L43-L53

Those fiscal values are commercial fields and are propagated to child contacts. Without checking that the partner is its own commercial entity, children are therefore classified as companies, preventing the standard display name logic from prefixing their parent name.

Solution:
We need to restrict the Colombian company classification to partners that are their own commercial partner. This preserves the NIT and obligation rules for actual companies while keeping their inherited child records as contacts, restoring both the combined display name and parent name search behavior.

opw-6470958

Forward-Port-Of: odoo/enterprise#130373
Forward-Port-Of: odoo/enterprise#128986