Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

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

Forward-Port-Of: odoo/odoo#248142

## Issue before this commit:

Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error:

> *"The operation cannot be completed: Missing required account on accountable line."*

This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied.

## Steps to Reproduce:

1. Install the `point_of_sale` module.
2. Go to POS Configuration → Settings:

   * Enable **Cash Rounding**
   * Set a **Rounding Method**
   * Enable **Only on cash methods**
3. Create a product:

   * Sale Price: 260
   * Tax: 6%
4. Open a POS session.
5. Add the product to an order.
6. Apply a discount (e.g., 1.123).
7. Pay using a **non-cash payment method** (journal not marked as cash).
8. Enable **Invoice** and validate the order
   *(or create the invoice later from the Orders menu)*

## Cause of the Issue:

While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration.

This leads to a mismatch where:

* No rounding configuration is set on the invoice
* Rounding logic still attempts to create/update rounding lines
* Required accounts (profit/loss) cannot be determined
* A validation error is raised due to missing account on the generated line

## With This Commit:

The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`.

This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing)

opw-6005320
opw-5951991
opw-6036870

Forward-Port-Of: odoo/odoo#254844

Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed successfully 2/ try to reset the invoice to draft inside of Odoo, then cancel it. This would fail with an error since account moves protected by a hash cannot be reset to draft.

The result is a blocked database where the invoice cannot be altered in Odoo while its status doesn't match the status in ticketBAI.

In this commit, we propose to check for the secure hash before sending the invoice over to ticketBAI. The invoice is not altered yet at that stage to account for potential ticketBAI errors in the normal flow.

While this option is not great from a usability perspective (preventing secure hashes with ticketBAI is probably best), we believe the current solution offers the best compromise in the context of a bugfix.

The issue does not seem to be reproducible outside of production as the core of the problem is a mismatch in state between ticketBAIand Odoo.

opw-5912848

Forward-Port-Of: odoo/odoo#250886

Steps to reproduce
==================

- Install contacts,web_studio
- Login as admin
- Go to contacts
- Open any record
- Open studio
- Click on any field
- Add the "Role / Portal" group
- Toggle the "Show invisible Elements" checkbox
- Click on the same field

=> The field is marked as invisible

- Add an invisible condition

=> The invisible condition is lost (but still applied on the view)

Cause of the issue
==================

In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups).

The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled.

But this causes the actual value of the invisible attribute to be lost.

Note that this also applies to the column_invisible attribute.

Solution
========

If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute.

We then use that value in the editor, when present.

opw-6026971

Forward-Port-Of: odoo/enterprise#111610
Forward-Port-Of: odoo/enterprise#111299