Steps to reproduce
1. Install crm, contact
1. Contacts → open a contact with an opportunity, if not present, create it.
2. From the Opportunities list view, add Studio fields “Next Activity Summary” and “Next Activity Type”.
3. In the opportunity, create an activity and see the list view of opportunity now from Contacts → opportunity.
4. Mark the current activity as done and create a new activity.
5. Observe the list view again: it still shows the old activity summary/type.

Issue
- When opening Opportunities from a Contact, archived (done) activities are included in activity-related fields, so “Next Activity” fields can point to old activities.

Root cause
- Done activity records are now set to archived. The Contact → Opportunities action sets `active_test=False`.  https://github.com/odoo/odoo/blob/9b071683e0eb270811302a4dd0ad10e0baaa0834/addons/crm/models/res_partner.py#L57
Since `activity_ids` had no domain, it included inactive activities, and related fields (`activity_summary`, `activity_type_id`) resolve to archived records.
https://github.com/odoo/odoo/blob/9b071683e0eb270811302a4dd0ad10e0baaa0834/addons/mail/models/mail_activity_mixin.py#L49

Solution
- Instead of passing active_test in context we will pass the domain to prevent the context interfear with activity fields.

opw-5942696

Steps to reproduce:
- Install `l10n_dk` module
- Create the test branches under the `DK Company`
- Add both companies(parent and branch) in `Bank and Cash` account
- Go to Chart of Accounts and try to delete any account

Cause:
This error occurs because users can add multiple companies to a `Bank and Cash` account, although it should be prevented by the `_check_company_consistency` [constrain]. However, the code still allows it because, in this [commit], `depends_context=('uid',)` was set on the `company_ids` field to keep separate sudo/non-sudo caches for the field. As a result, during the validation [check], the user may still have stale cached values, causing the system to detect only a single company.

Solution:
Here, we first clear all cached values for the old record and force the ORM to re-fetch the values from the database, ensuring an updated recordset. So, the validation error is raised when saving multiple companies.

[constrain]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[check]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[commit]: https://github.com/odoo/odoo/pull/220294/changes/5096d083a38968425920aa5bf466b156eebb3dc7

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

Forward-Port-Of: odoo/odoo#260261

## Description

### Problem

[sale_product_domain](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/website.py#367-376) uses `self.get_current_website()` for the website domain
but `self.company_id` for the company domain. This causes two issues:

1. **`company_id` is `False` when called from [models](https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L278)**: Methods like
   [_get_website_accessory_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#198-203) and [_get_website_alternative_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#204-207) call
   `self.env['website'].sale_product_domain()` — an empty recordset where
   `self.company_id.id` evaluates to `False`. The resulting company domain
   [('company_id', 'in', [False, False])](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/controllers/main.py#757-802) filters out all company-owned
   products.

https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L279

2. **Inconsistent website references**: Even when `self` is a real website
   record, `get_current_website()` could return a different website, leading to
   the website domain and company domain referring to different websites.

### Steps to reproduce

1. Add accessory products to a product template
2. Visit the product page on the ecommerce shop
3. Accessory products belonging to the website's company may not appear

### Solution

Store the resolved website in a local variable (`self or self.get_current_website()`),
preferring `self` when it is a real record and falling back to
`get_current_website()` otherwise. Use this single variable for both the website
domain and the company domain.

```diff
 def sale_product_domain(self):
-    website_domain = self.get_current_website().website_domain()
+    website = self or self.get_current_website()
+    website_domain = website.website_domain()
     if not self.env.user._is_internal():
         website_domain = expression.AND([website_domain, [
             ('is_published', '=', True),
             ('service_tracking', 'in', self.env['product.template']._get_saleable_tracking_types()),
         ]])
-    company_domain = [('company_id', 'in', [False, self.company_id.id])]
+    company_domain = [('company_id', 'in', [False, website.company_id.id])]
     return expression.AND([self._product_domain(), website_domain, company_domain])
```


https://github.com/odoo/odoo/pull/260138

Forward-Port-Of: odoo/odoo#263185

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d88c24e795 [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132)
https://github.com/odoo/o-spreadsheet/commit/d854983ab3 [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300)
https://github.com/odoo/o-spreadsheet/commit/49d0b4dffa [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335)
https://github.com/odoo/o-spreadsheet/commit/dd00c1135e [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827)
https://github.com/odoo/o-spreadsheet/commit/e2e096d9cb [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820)
https://github.com/odoo/o-spreadsheet/commit/b24082bd32 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

Forward-Port-Of: odoo/odoo#261521