**Problem**:
When clicking "Link" in the toolbar, the link popover opens, but the
toolbar remains visible instead of closing.

**Cause**:
Previously (`saas-18.1`), clicking "Link" created an `<a>` tag and
changed the selection to it. This triggered `updateToolbarVisibility`,
which detected the selection on a link (where `[data-prevent-closing-overlay]`
was `false`), allowing the toolbar to close.

Now, the `<a>` tag is created only when applying link changes.
So `updateToolbarVisibility` is triggered with selection inside the
link popover’s input field (where `[data-prevent-closing-overlay]` is
`true`), preventing the toolbar from closing.

**Solution**:
remove `data-prevent-closing-overlay` from link popover and only close toolbar
if selection is inside link popover using `.o-we-linkpopover` as selector.

**Steps to Reproduce**:
1. Open the toolbar.
2. Click "Link".
   - **Issue**: The link popover opens, but the toolbar remains open.

**opw-4639049**

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

Forward-Port-Of: odoo/odoo#201325

Description of the issue/feature this PR addresses:
This PR is to avoid making unnecessary format validations on manual documents, as well as to improve the error message shown when the validation is done and the user had entered an invalid document number.
A use case for these changes is when the user wants to register an invoice from a foreign supplier that does not have the Uruguayan format, and at the moment of filling the “Document Number” field, an error message appears saying that it does not comply with the Uruguayan number validations.

Current behavior before PR:
Either electronic or manual document numbers format were validated against the electronic documents format.

Desired behavior after PR is merged:
Only electronic document numbers are validated to check if they have the proper format.

Steps to reproduce the error:
1) Install l10n_uy
2) Create an invoice using a manual journal.
3) Set a random document number (for example '1234')
4) Check that a pop up is raised, saying that the format is invalid.

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

Forward-Port-Of: odoo/odoo#198216

… flexible

This commit aims to resolve critical error in time off when the user is
fully flexible.

- get_allocation_data is updated to handle the case when the employee is fully flexible.
- Set duration_hours and duration_days in the dummy attendance to handle
  flexible time off requests and to avoid unintended zero division error in _get_attendance_intervals_days_data.
  P.S: Currently Fully Flexible resources do not support fully time offs,
  so this allows a fallback that prevents error while still setting a valid
  duration of a time off request.

Steps to reproduce:
1. Install hr_holidays
2. Go to Mitchel Admin's employee profile > work information
3. Delete the working calendar > so that the employee is fully flexible
4. Try to open time off module
   -> Prior to this commit, it would raise a zero division error

ticket-id: 4677726


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

Forward-Port-Of: odoo/odoo#204710
Forward-Port-Of: odoo/odoo#203737

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings, activate "SEPA Direct Debit (SDD)"
- Create a contact:
  * Country: Belgium
  * Bank Account: [a Belgian IBAN]
- Go to "Accounting / Customers / Direct Debit Mandates"
- Create a mandate for the created contact
- Validate the mandate
- Create an invoice for the created contact as customer
- Confirm the invoice
- Pay the invoice with "SEPA Direct Debit"
- Print the invoice

**Issue:**
The information explaining that the invoice has been paid using direct debit and that the invoice should not be paid manually is not printed on the invoice.

**Cause:**
This information is printed if "sdd_mandate_id" field of the invoice is set.
"sdd_mandate_id" is a related field to "origin_payment_id.sdd_mandate_id" field.
However, since the refactoring on "account.payment", "origin_payment_id" is not set on an invoice anymore.
It is just set on the journal entry linked to a payment.
Therefore, we cannot rely on that field anymore to print the SDD mandate payment information.

**Solution:**
The "matched_payment_ids" field can be used instead.
It's a Many2many field referring all payments linked to the invoice.
If one of these payments has "sdd_mandate_id" set, the SDD mandate payment information is printed on the invoice.

opw-4672191

Forward-Port-Of: odoo/enterprise#82823

This is more an UX problem rather than a bug.

In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears.

Then, all the background behind the rainbow overlay is disabled, you can no longer edit the filters in the search for instance, and the only buttons available become "All transactions" and "Back to dashboard". Both buttons will make you loose your search filters:
- You loose the "Not Matched" filter which is set automatically when you hit the "x to reconcile" button in the accounting dashboard, and hence you see the already reconciled transactions, while you were actually interested only in the non-reconciled transactions
- If you made a complicated filter, you loose them all and you are good to redo them all.

This revision offers the possibility to have the background behind the rainbow overlay clickable, so you would be able to change the filters, for instance only the last filter, in order to continue your reconciliation where you were, instead of being completely reset.

Before:


https://github.com/user-attachments/assets/4ed7cf41-1fa0-4efe-92a0-171011b4713a


After:

https://github.com/user-attachments/assets/e4f2d580-9dca-4331-9e66-89efeb00edef

Forward-Port-Of: odoo/enterprise#82562