The link popover previously had multiple buttons, making the link
editing experience less intuitive. This commit unifies actions into
a single wider popover and refactors some logic to improve consistency.

## UI/UX changes:
- Replaced three buttons (copy, edit, remove) with one "Edit" button,
  which opens the link editing view.
   | Before  | After |
   | ------------- | ------------- |
   | ![image](https://github.com/user-attachments/assets/04727aea-fc7b-410b-9159-1ac56e9b42a0)  |  ![image](https://github.com/user-attachments/assets/512628c7-b425-4831-a90e-caa6b1868c3d)  |

- Widened the popover for better readability.
- Removed the copy link feature.

<br/>

## Changes in link editing view:
- Moved the "remove link" button in this view.
  <kbd>![image](https://github.com/user-attachments/assets/4ad69aa4-4edb-4a25-a7b0-f84e76cbcbce)</kbd>

- Updated URL input placeholder to: "Enter URL, /page, or #anchor".
- Auto-focus the URL input when creating a link for selected text.
- Auto-focus the label input when creating new links or editing
  existing links.

task-[4862671](https://www.odoo.com/odoo/project/974/tasks/4862671)

Co-authored-by: adch-odoo \<adch@odoo.com\>

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

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

**Steps to Reproduce:**
1. Install the "**Belgium - Accounting**" (`l10n_be`) module with demo data.
2. Switch to the company - **BE Company CoA**.
3. Remove the "**Tax Payable Account**" from all the tax groups.
4. In setting, under _EU Intra-community Distance Selling_ section, click on "**OSS Tax mapping**".

**Error:**
`ValueError - External ID not found in the system: account.1_oss_tax_group_20_0_SK`

**Note:** If only the "**Tax Receivable Account**" is removed from all tax groups. The following error occurs;
`TypeError: expected string or bytes-like object`

**Cause:**
At [1], the system searches for a tax group with a defined `tax_payable_account_id`.
Also, at [2], the `oss_tax_group_local_xml_id` is created only when the tax group (tg) exists. However, when no tax group is found, the code tries to fetch the missing xml id at [3], resulting in a ValueError.
Similarly, when the receivable account is missing, the execution also fails, leading to a TypeError.

**Fix:**
This commit updated the tax group search condition to include both `tax_payable_account_id` and `tax_receivable_account_id`. Also, added skipping further processing if the related tax group is not found.

[1] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L47-L49
[2] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L115-L146
[3] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L164

sentry-6932155430

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

Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
  also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
  - Such POs should be implicitly considered acknowledged once their receipts
    are done, but they were still shown at the counter.
  - Additionally, unacknowledged POs that were locked were incorrectly excluded
    from the counter.
- For Late Receipt:
  - POs with received products were incorrectly counted as late, even
    though their receipts were already done.
  - Locked POs with late receipts were also excluded from the counter, which was
    an incorrect behavior.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
   Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
   counters and some locked POs that are unacknowledged or have late receipts
   are missing from the counters

Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
  the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
  some locked POs were incorrectly excluded.

After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
  receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
  unacknowledged POs with completed receipts are automatically marked as
  acknowledged and excluded from the Not Acknowledged counter. Locked POs that
  remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
  receipts are completed and Locked POs with late receipts will now correctly
  continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
  acknowledgments and genuinely late receipts, helping users track POs in
  the correct state.

Task ID: 4874116

Forward-Port-Of: odoo/odoo#237305
Forward-Port-Of: odoo/odoo#224180

**Steps:**
- open documents in list view in dark mode
- select and deselect a record

**Observation:**
- the selected record's background becomes white and text was already white
- hence nothing can be seen clearly

**Cause:**
- Commit [1] introduces a scss change for list view, but used hardcoded values for color, which works well for light mode but not in dark mode

https://github.com/odoo/enterprise/blob/f73626fa778fd96de213a0fae61ced6fd5012d36/documents/static/src/scss/documents_views.scss#L29-L36

[1]: https://github.com/odoo/enterprise/commit/009fddcd20b0e7b81b8959f73e39d840d96167c7

**Fix:**
- instead of hardcoding color, we use already available variable, which adjust the color, according to theme.

**Before:**
<img width="1150" height="176" alt="image" src="https://github.com/user-attachments/assets/33d0688c-d9cd-4266-bcc8-189e830bc391" />

<img width="1319" height="203" alt="image" src="https://github.com/user-attachments/assets/cd8fa68e-76ff-411d-8d37-4e61e2ce99e8" />


<br><br>
**After:**
<img width="1028" height="141" alt="image" src="https://github.com/user-attachments/assets/470365b0-c18f-497d-b3b2-11cd8fea371a" />

<img width="996" height="164" alt="image" src="https://github.com/user-attachments/assets/74d6b71b-852e-41ee-acb3-4b58d8eace9e" />


opw-5261669

Forward-Port-Of: odoo/enterprise#100114

**Steps to reproduce:**
- Make a quotation in the Sales module
- Go to PoS, click Quotation/Order and select your quotation
- Select Settle the order
- Go through with the payment
- Go back to the Quotation in the Sales module
The Status widget still shows Quotation instead of Sales Order

**Why the fix:**
Since 18.3, the sale_order.state was not updated anymore when the state changed through the PoS.

This happened because we would only change the sale_order state if there was a downpayment involved. In 18.2, we
always recomputed the sale_order that was linked to the order we are currently settling.

The way it is done now is part of the same way it was done in 18.2 and before, meaning we add the linked sale_order
regardless of downpayments.

In 18.2, we did an action_confirm on the selected  sale_orders, but doing that in 18.3 will create another picking for this sale_order. This is not what we want as the picking is now handled and created by the PoS. 

This fix will just put the related sale orders in the "sale" state, so that users can no longer confirm it in the sales modules, which would create a second picking and create duplicates.

opw-5033979

Forward-Port-Of: odoo/odoo#237213
Forward-Port-Of: odoo/odoo#226008

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

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#100467
Forward-Port-Of: odoo/enterprise#93378

Currently a `ParseError` arises when the user installs the `hr_work_entry_attendance` module after deleting all `Overtime Rules' in the 'Rulesets` Configuration.

Steps to reproduce:
---
- Install `hr_attendance` module(without demo)
- Attendance > Configurations > Overtime Rulesets
- Delete all `Overtime Rules` in `Default Ruleset`
- Now install `hr_work_entry_attendance` module

Traceback:
---
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'

ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_work_entry_attendance/data/hr_attendance_overtime_rule_data.xml:4, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
            <field name="work_entry_type_id" model="hr.attendance.overtime.rule" eval="obj()._get_default_work_entry_type_id()"/>
        </record>
```

The error occurs because the user deleted all `Overtime Rules` and then installed the `hr_work_entry_attendance` module. which requires particular records.

This commit solves the above issue by using `noupdate="1"`and `forcecreate="0"` to skip the creation of record if it doesn't exists.
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366

sentry-7023182659

Currently, an error occurs when a user sets the partner on a statement line.

**Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)):
 - Install the `account_accountant` module.
 - Go to `Invoices` and create `two invoices` with the `same partner` and the `same total amount` by adding 
    an `invoice line`.
 - Go to the `Dashboard` and click `Last Statement` under the `Bank journal`.
 - Create a `new statement line` with the `same amount` as the `invoice amount`.
 - Click `Set Partner` and select the `same partner` used in the invoices.

`TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'`

After [this commit], when a user sets the partner on the statement line, the system attempts to automatically reconcile the line. It then searches for a single invoice matching the statement line amount [1] and tries to select the one with the closest prior or equal date. However, draft invoices have not an invoice_date, and when the system attempts to filter on this field, and the error is raised [2].

This commit ensures that the comparison between invoice date and statement date occurs only when the invoice date is present.

[this commit]: https://github.com/odoo/enterprise/pull/98269

[1]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L585

[2]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L249

sentry-7063516380

Steps:
- Install studio
- Open any list view
- Make sure multi_edit is enabled (or edit the view with debug menu)
- Add a new selection field to the list view with studio with several values
- Get back to the list view, select at least two record and edit the new
selection field
- Put any value, it will edit all selected record correctly
- select at least two record and edit the field again
- Try to clear the value (to have it empty)
- Traceback

Since this change https://github.com/odoo/odoo/pull/214422, selection
fields no longer display “empty” values, to be consistent with many2one
fields.
Now, to set a selection field to a null value, you have to clear it,
just as you would clear a many2one field.
The problem arose because when you clear an input, `onInputClear` is
called and triggers an onchange with the value `null`, but the
`selection_field` code expects to receive a `false` if there is no value
otherwise it searches for the value in the list of possible choices
which is why the traceback is raised when `null` is received, because it
is not in the list of choices.

This comimt change the onchange of `selection_field` to change the value
to `false` if it is equal to `null`.

opw-5226200

When a snippet containing a `<form>` (e.g. “Contact us” form) is dropped
inside an existing form element, the inner form is invalid HTML
(see [1]).

Steps to reproduce:
===================
1- Go to a Shop page and open a Product page.
2- Drag and drop a “Contact us” form snippet inside the existing product
form (e.g. in description_ecommerce, which is an HTML field with
`sanitize_form=False`).
3- Save the page, re-enter edit mode.
4- Click on any field of the inserted “Contact us” form.
→ traceback.

Cause:
======
HTML does not support nested `<form>` elements.
As soon as the browser parses the dropped snippet inside an existing
`<form>`, it normalizes the DOM and strips or moves the inner `<form>`
tag, keeping only its contents. The inner form therefore loses its
attributes (action, method, data-model_name, etc.).
When editing a field, `fetchAuthorizedFields` needs the form’s model it
used to rely directly on `formEl.dataset.model_name`, which is missing
in this broken structure, causing a crash.

Solution:
========
Prevent dropping the snippets that contain a form inside another form,
by filtering out the `selectorSiblings/Children` (which are used to make
the dropzones appear) that are in forms, when they are dragged.

This commit also uses the `getModelName(formEl)` helper wherever we need
the form model instead of accessing `dataset.model_name` directly.

[1]: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/How_to_structure_a_web_form

opw-5256576