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

Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert:
```python
self.assertEqual(self.product1.qty_available, 15.0)
```
The error message is: `AssertionError: 16.0 != 15.0`

In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15.
Now, the assert sometime fails because in the tour, the last step check the success message is visible:
```javascript
trigger: ".o_notification_bar.bg-success",
```
The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition.

To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it.

[1]: https://github.com/odoo/enterprise/pull/101495

runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692)

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

Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that:
```javascript
return childLocation.parent_path.includes(parentLocation.parent_path);
```
The issue with that is, if locations' id are aligned, they can match even if they are not related.

For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.)

To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location.

Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned.

runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292)

Forward-Port-Of: odoo/enterprise#104350

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

Attempting to fetch pictures for a product via the Barcode Lookup API that has no images causes a traceback.

Steps to reproduce the error:
- Install ``product_barcodelookup`` module and set API Key
- Create a new product > Barcode: ``7896539200843`` > Save
- Actions > Get Pictures from Barcode Lookup > Get Pictures

Traceback:
``AttributeError: 'dict' object has no attribute 'status_code'``

https://github.com/odoo/enterprise/blob/e9bf8ee37d9fde09a1599d64b44f0c6599299cf4/product_barcodelookup/tools/barcode_lookup_service.py#L19-L25
When a product does not have picture in barcode lookup,
``barcode_lookup_request`` method returns ``dict`` instead of ``Response`` object.
This causes a traceback when the code later tries to access ``status_code`` at:

https://github.com/odoo/enterprise/blob/e9bf8ee37d9fde09a1599d64b44f0c6599299cf4/product_barcodelookup/wizard/product_fetch_image_wizard.py#L277-L278

ref: https://github.com/odoo/enterprise/commit/48582d98d6a1bc275a6f6c2baa83431dda085516

sentry-6886021547

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

### Issue:
In a manual follow-up printed as PDF, overdue invoices appear twice.

### Step to reproduce:
- Create a partner and an overdue invoice for this partner,
- Send the invoice,
- go to this Partner then in the "Accounting" sheet,
- Choose follow-up as manual,
- Click on send,
- In the wizard select Print and "Join invoices"

### Current behavior:
The PDF display the reminder, the invoice, the report and the invoice again.

### Expected behavior:
Invoice should appear only once in the follow-up PDF.

### Cause :
When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again.
In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices.

opw-5368870

Forward-Port-Of: odoo/enterprise#102516