### Issue:
When a custom button snippet was dropped next to an existing button 
wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in 
a paragraph `<p>` tag. This issue did not occur with standard button 
snippets or when the buttons were wrapped in a `<p>` tag.

### Steps to reproduce:
1. Drag a standard "Button" snippet next to an existing button (e.g., in
   the navbar). The structure is correctly `<a/><a/>`.
2. Save a button as a custom snippet.
3. Drag this new custom button snippet next to a button wrapped in a 
   `<div>` (navbar in our example).
4. Observe the structure: 
   `<div><a/><p><a class="s_custom_snippet"/></p></div>`,
   but it should be like `<div><a/><a class="s_custom_snippet"/></div>`.

### Fix
The logic has been corrected to only wrap a button snippet in a 
paragraph tag if it has no sibling buttons and is not already inside a 
`<p>`. This ensures consistent behaviour between standard and 
custom button snippets. A tour test is also added, ensuring the 
behaviour is correct.

Backport of https://github.com/odoo/odoo/commit/3a8f2cc418510c3b91f8b9086bb4a89a1745e40d

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

Forward-Port-Of: odoo/odoo#241937
Forward-Port-Of: odoo/odoo#224476

The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available.

Refs:
An independent invoice example: https://developer.vertexinc.com/einvoicing/docs/belgium-example-documents

https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1564-L1566

https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1585

Steps To Reproduce:
- Have accounting, account_edi_ubl_cii and contacts installed.
- Create a Belgian company and set the VAT, Company ID and Reference (under Sales & Purchase tab).
- Create a contact and set his eInvoice format in Accounting tab to EU Standard (Peppol Bis 3.0) and make sure to give him a country.
- Go to accounting -> Customers -> Invoices and create an invoice for the contact you created.
- Send the invoice to the contact and download the XML from the chatter and inspect it.
- PartyIdentification/ID shows the partner's ref field value (e.g., "(odoobe)") instead of the company registration number.
- PartyLegalEntity/CompanyID uses the VAT number instead of the company registration number (ondernemingsnummer).


Ticket [link](https://www.odoo.com/odoo/project.task/5418190)
opw-5418190

Forward-Port-Of: odoo/odoo#243143

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#99820

When mapping a datetime value to fields of type boolean or one2many, an error is raised.

Steps to Reproduce:
1) Install CRM
2) Navigate to CRM and upload [this file](https://docs.google.com/spreadsheets/d/1eRhIy3Zt8kD-_sH8Lp2N9IE9zflYB5CX/edit?usp=sharing&ouid=101212513075316114369&rtpof=true&sd=true) 
3) Map 'Created on' with 'Active' and click on Test.

Error-1 :
`AttributeError: 'datetime.date' object has no attribute 'lower'`

If you upload [this file](https://docs.google.com/spreadsheets/d/18xTvxjc9EsXf86N5Y8ekq-AZocQSNwEM/edit?usp=sharing&ouid=101212513075316114369&rtpof=true&sd=true) and click on Test, the following error is raised:

Error-2:
`AttributeError: 'datetime.date' object has no attribute 'split'`

Root Cause:
This type of issue was previously addressed in [commit 1](https://github.com/odoo/odoo/commit/83034f4752fd2a126851d6308a3ad39221dcab6a), but its changes were reverted in [commit 2], which only handled char fields. As a result, cases for `bool` and `one2many` fields were missed. Since the `_parse_datetime_data` check at [1] was removed after [commit 2], the error reappears.

Fix:
Following the logic of [commit 2], this fix extends the handling to bool and one2many fields.

[1]- https://github.com/odoo/odoo/blob/462f620803e22da4a2d08915eb31fcda876ec73e/addons/base_import/models/base_import.py#L1466-L1467

[commit 2]: https://github.com/odoo/odoo/commit/743ae7f6555160415b33ba3afb3de7bc78cede81

sentry-6979678378,6924909613

Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input.

**Steps to Reproduce:**
1. Install the hr_payroll_sale_commission module.
2. Create a user and link to an employee. Set a contract for the employee.
3. Create two commission plans for the same user:
   - Use the same Payslip Input in both plans.
   - Set the Target Frequency to "Monthly" for both.
4. Generate a payslip for the employee.

Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing)

**Error:**
`ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)`

**Cause:**
When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion.

**Fix:**
This commit ensures the currency conversion is applied per commission and prevents the singleton error.

sentry-7187854690

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104299