Before this commit:
-------------------
When a user added an existing signature field to a view, Studio automatically assigned the default binary widget.
The expected signature widget did not appear in the widget selection list. As a result, users could not configure the field as a signature input.
<img width="1920" height="938" alt="image" src="https://github.com/user-attachments/assets/35893235-2541-4bd5-a7a5-4feab562acb2" />

Cause:
-----
Studio builds the dropdown of available widgets by computing a [widgetKey](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/utils.js#L132) based on the field type.
Because the signature widget did not declare binary as a supported field type, it was always filtered out for fields of type binary. Thus Studio treated the field like any normal binary field and excluded the signature option.

After this commit:
------------------
The signature widget is correctly exposed as a supported widget for fields of type binary.
When adding an existing signature field to the view (with developer mode enabled), Studio now shows signature in the widget list.
<img width="1917" height="934" alt="image" src="https://github.com/user-attachments/assets/079e0a17-ff5a-4dc6-a12d-e02b9cad013e" />


Why this fix is needed:
----------------------
Signature fields are stored as binary, but they require the dedicated signature widget to render correctly.
By marking binary as a supported field type for the signature widget, Studio can
 properly detect and offer the widget during field configuration.
Given that this widget is very domain-specific and not intended for general binary fields, it was not added to
[web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js) though this may be reconsidered
after this fix the option is accessible only when the debugger mode is on, if want to show this widget 
to all the binary type fields even when the debugger mode is off the we'll have to add it to this file.

OPW : 5260188


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

Forward-Port-Of: odoo/odoo#237287

Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.

Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
     contenteditable="true">
  text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.

Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.

Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.

opw-5184309

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

Forward-Port-Of: odoo/odoo#234905
Forward-Port-Of: odoo/odoo#232910

When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the
`viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late.

This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message.

In addition, there are two other minor fixes:
- In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error).
- The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva.

opw-5226966

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

Forward-Port-Of: odoo/odoo#237411
Forward-Port-Of: odoo/odoo#236454

- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF.
This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by default.
As a result, those invoices returned no attachments, leading to blank pages or missing files in the ZIP download —
since the invoices weren’t sent and no fallback was allowed.

**Steps to reproduce:**
**1:** Go to Invoices
**2:** Try to use Export ZIP for any non-sent invoice → you’ll see a blank page

**What this patch does:**
- It limits the Export ZIP option to the list view only. This doesn’t fix the missing PDF issue, but it makes sense — having “Export ZIP” on every single invoice form view isn’t useful.

**Possible improvements to consider:**
**1:** Restrict Export ZIP so it’s only available for sent invoices. This would improve performance since sent invoices already have PDFs stored in the filestore.

**2:** Allow a fallback for invoices that haven’t been sent, so their PDFs are generated when exporting — but this may cause performance issues if too many non-sent invoices are processed at once.

**3:** Instead of showing a blank page for non-sent invoices, show a user-friendly
 error message. (I noticed this was in the original commit
odoo/odoo@c81ab09d0404cc57f48c202360361a1700f060db where this was
 introduced but was later removed — not sure why.)

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

Same issue already fixed for 18.4+ here:
https://github.com/odoo/odoo/pull/231399

Issue:
When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank.

Repro Steps:
1- Create invoice for romanian localization.
2- Link payment account to invoice.
3- Add bank to payment account.
4- Confirm and send invoice with "Send E-Factura SPV" checked.

Cause:
The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank.

Fix:
The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly.

opw-5362000

(cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93)

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

Forward-Port-Of: odoo/odoo#237615