Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome turns out to have pretty extensive debug logging facilities which are somewhat valuable: https://www.chromium.org/for-testers/enable-logging/

For instance if the oomkiller decides to nuke a chrome tab (example selected for no reason whatsoever), the debug log will have an entry along the lines of

    [...:WARNING::chrome/browser/ui/sad_tab.cc:256] Tab Killed: http://127.0.0.1:8069/

which is a much more helpful hint than just being told a test timed out (to say nothing of being told that chrome was not able to do dbus stuff when we never asked for that).

Because it can be useful for all sort of debugging, this log is saved not just when chrome fails to start, but also when a Chrome completes, successfully or unsucessfully (in the latter case it's logged as RUNBOT to be available from the runbot UI).

The chrome logging facilities are controlled by a new envvar `ODOO_BROWSER_LOG_VERBOSITY`, it can be set to `-1` to disable logging, or a strictly positive integer for ever increasing amounts of logging. At `1` chrome will log every network request it attempts which can be useful for debugging some races but is already extremely noisy.

Forward-Port-Of: odoo/odoo#255117
Forward-Port-Of: odoo/odoo#255054

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

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

Description of the issue/feature this PR addresses:
When using the loyalty module with Chilean localization and a sale in UF or Dollars, an error occurs when calculating the promotion amount.

When the system evaluates whether a promotion is applicable, it appears to be taking the value of the sale line after applying the company currency rounding instead of the sale order currency rounding. In the case of Chile with the peso currency, where rounding is applied to the unit, if the value of a line is less than 0.50 UF, the system rounds it to 0. By interpreting the line value as zero, the promotion engine does not recognize the existence of valid products and the "Promotions/Reward" button does not display any available options, even though the program conditions are met.

The root cause of the problem is that the `compute_all` method of taxes is being called without specifying the currency, which causes it to use the company currency instead of the sale order currency.

Current behavior before PR:
- Create a Promotions program (Discount & Loyalty) that applies, for example, a 10% discount without complex minimum restrictions.
- Create a Sales Order and add a product line whose unit price is less than 0.50 (e.g. 0.34 UF).
- Click on the "reward" button. Result: No available promotions are shown or it does not apply if there is only one active promotion.

Desired behavior after PR is merged:
- Create a Promotions program (Discount & Loyalty) that applies, for example, a 10% discount without complex minimum restrictions.
- Create a Sales Order and add a product line whose unit price is less than 0.50 (e.g. 0.34 UF).
- Click on the "reward" button. Result: The button now detects the promotion and allows it to be applied.




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

## 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

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

**Problem:**
When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment.

**Steps to reproduce:**
1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe.
2) Change the company currency to euro.
4) Create a manual invoice for that customer.
5) Pay the invoice using the pre-configured Stripe SEPA token.
6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending".
7) When Stripe confirms the transaction, the payment stays canceled.

**Cause:**
In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled.

**Solution:**
- Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process.

opw-5934381

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

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

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