Message access is notably based on related document, given their
(model, res_id) pair. Model may customize the required access on
it in order to access their message. For example, you generally
need write access to create a message (post) but on some models
you can post when you can read. Calendar events message access depends
on calendar privacy settings.

This is controlled via '_get_mail_message_access'. However currently
it is "globally called", for all documents. It should be done on a
per-document basis, as each document could define different access
check.

Keep code somewhat optimized by doing access checks in batch for a
given operation.

Make _search and read symmetric. Reading documents should be allowed
on search results, and search results should match what is available
for reading.

Portal users have some specific domains applied when accessing
messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for
'website_message_ids' domain, mail controllers, ...). However there
are still some cases where search and read are not coherent with
portal users. This is not really annoying as most messages are accessed
using sudo and correctly tailored domains via controllers but let
us try to have a more correct code.

Fix discuss display of chatter-related buttons
* not taking into account '_get_mail_message_access' to check if
  user has right to post (generally used to indicate users can
  post on readonly records, but not limited to that);
* not adding the same check on Activities button as on Send message
  and Log note. We consider generally that rights should be aligned
  and UX should match that behavior;
* not adding the same check on attachments buttons, currently limited
  to write access (or always accessible). This is a preliminary work
  for attachments, further fixes are probably incoming;

Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 .

Task-5138368
opw-4785878

Forward-Port-Of: odoo/odoo#244009
Forward-Port-Of: odoo/odoo#233725

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

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

When combo choices associated with products are deleted and
the user attempts to load sample data in the Furniture PoS, a traceback occurs.

Steps to reproduce the error:
- Install ``point_of_sale`` module without demo data
- Go to Point of Sale > Click on Furniture > Open Register > Load Sample > Close register
- Go to Point of Sale > Products > Combo choices > Delete all combo choices
- Go to Settings > Restrict Categories > Unset all categories > Save
- Go to Point of Sale > Dashboard > Furniture > Open Register > Load Sample

Traceback:
```py
ParseError: while parsing /home/odoo/src/odoo/19.0/addons/product/data/product_demo.xml:905
A combo product must contain at least 1 combo choice.
```

https://github.com/odoo/odoo/blob/c81e50d3b8f0ffc0297c97b06afd77e2c92ad508/addons/point_of_sale/models/pos_config.py#L1025
When clicking Load Sample button in the Furniture PoS,
the ``_load_onboarding_furniture_demo_data`` method loads the ``data/product_demo.xml`` file.
If the combo choices linked to products have been deleted,
loading the following record triggers the above traceback.

https://github.com/odoo/odoo/blob/c81e50d3b8f0ffc0297c97b06afd77e2c92ad508/addons/product/data/product_demo.xml#L664-L671

Solution:
Restrict deletion of combo choices if they are linked to any products.

sentry-6943167929

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

The system will crash when user try to load sample data in appraisal.

**Steps to produce:-**
- Install `Appraisals` and `Recruitment` module.
- Make a new user with access right of administrator to `only Appraisals`.
- Login with new user.
- `Appraisals > Load sample data`.

**Error:-**
```py
AccessError: You are not allowed to create 'Job Position' (hr.job) records.

This operation is allowed for the following groups:
	- Recruitment/Officer: Manage all applicants

ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside <record id="job_consultant" model="hr.job" forcecreate="1">
            <field name="name">Consultant</field>
            <field name="no_of_recruitment">5</field>
            <field name="contract_type_id" ref="hr.contract_type_interim"/>
            <field name="description">We are currently looking for someone like that to join our Consultant team.</field>
        </record>

ValueError: ParseError('while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside\n<record id="job_consultant" model="hr.job" forcecreate="1">\n            <field name="name">Consultant</field>\n            <field name="no_of_recruitment">5</field>\n            <field name="contract_type_id" ref="hr.contract_type_interim"/>\n            <field name="description">We are currently looking for someone like that to join our Consultant team.</field>\n        </record>') while evaluating
'action = model._load_demo_data()'
```

**Root Cause:-**
- When a user is granted access rights only for the Appraisal module and attempts to load sample data for it, an error occurs. This happens because the sample data at [1] includes the `creation of records` related to the `Recruitment module`. Since the user does not have the required access rights for Recruitment, the system raises a permission error.

**Solution:-**
- In this commit, we resolve the issue by using `sudo()` while loading the data.

[1]: https://github.com/odoo/odoo/blob/fabfeb55c56fbc7136bd1c3a72e9d6ee99f39714/addons/hr/data/scenarios/hr_scenario.xml#L21-L26

**sentry-6795776877**

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

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

In **l10n_ec**, negative lines are not accepted in the XML.
They must be dispatched as discounts on positive lines.
The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased.

## Steps to reproduce

With **l10n_ec**:
1. Change the decimal accuracy to 6 digits.
2. Set the rounding method to *global rounding*.
3. Create an invoice with the following lines:

| Quantity | Price    | Taxes     |
|-----------|----------|-----------|
| 20        | 1.4235   | VAT 0% G  |
| 20        | 1.6425   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.4235   | VAT 0% G  |
| 6         | 3.747768 | VAT 15% G |
| 6         | 3.747768 | VAT 15% G |


In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`.

This happens due to rounding differences in how the `descuento` is computed in the
`common_details_info_template` from **l10n_ec_edi**:

format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount'])

where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere.

This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**.
Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed.

opw-5128612