When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email.
This fix changes the order to generate the DDT number before sending the email.

Steps to reproduce:
- Create a database with an Italian company and the `l10n_it_stock_ddt` module installed
- Turn on `Settings > Inventory > Shipping > Email Confirmation`
- Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates`
- Edit the `Shipping: Send by Email` template
- Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`.
- Create a SO, validate it
- On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery.
- In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name.
- If you open the report, the title of the PDF is also missing the DDT name.

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

Forward-Port-Of: odoo/odoo#243492

**Description of the issue this PR addresses:**
------------------------------------------------
When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users.

For portal users, this resulted in unnecessary toast notifications and chat window pop-ups.

**Current behavior before PR:**
---------------------------------
- The inviter is notified when any invited user connects for the first time.
- This includes portal users.
- Unnecessary notifications and chat pop-ups are shown for portal user connections.

**Desired behavior after PR is merged:**
-----------------------------------------
- The inviter is notified **only when an internal user** connects for the first time.
- Portal users no longer trigger first-connection notifications.
- The notification message is updated to:  “[Username] just connected for the first time. Wish them luck!”

**Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780)

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

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

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 support of post check capabilities
* 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) in 'readonly'
  computation in frontend and in controllers;
* 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#233725

When creating an event in Odoo that syncs to Outlook, a timeout or network error during the response from Microsoft can leave the system in an inconsistent state, leading to duplicate events in both Odoo and Outlook during subsequent synchronizations.

### Steps to reproduce

1. Create a calendar event in Odoo with Outlook synchronization enabled.
2. Simulate a network timeout (currently set to `3 seconds`) after Microsoft processes the creation request but before Odoo receives the response (e.g., by mocking a timeout in `_microsoft_insert`).
3. Observe that the event exists in Outlook but the Odoo record lacks the `microsoft_id`.
4. Run the synchronization manually.
5. A duplicate event is created in Outlook (due to retry) and/or a duplicate event is created in Odoo (fetched from Outlook as "new").

### Root Cause

The synchronization logic in
`microsoft_calendar/models/microsoft_sync.py` relies on receiving a successful response from the Microsoft Graph API to link the Odoo record with the created Outlook event.

Specifically, in the `_microsoft_insert` method, the call to `microsoft_service.insert` sends the creation request. If Microsoft successfully processes this request and creates the event, but the network connection times out while waiting for the response, the subsequent line `self.write({'microsoft_id': event_id, ...})` is never executed.

At this point, the Odoo record remains with `microsoft_id=False` and `need_sync_m=True`, even though the event actually exists in Outlook.

During the next synchronization:

1. `_sync_odoo2microsoft` identifies the Odoo record as unsynced (`microsoft_id=False`) and sends a new insertion request, creating a second event in Outlook.
2. `_sync_microsoft2odoo` fetches the original event from Outlook. To match Outlook events back to Odoo records, the logic in `MicrosoftEvent._load_odoo_ids_from_db` searches for Odoo records having a matching `microsoft_id` or `ms_universal_event_id` (a global ID provided by Microsoft). Since the Odoo record was never updated with these IDs, the match fails. Odoo treats the incoming event as a new external item and creates a duplicate record in Odoo.

### Fix Rationale

To resolve this, we utilize the `transactionId` property of the Microsoft Event resource. The `transactionId` is an optional, client-provided string that Odoo can attach to an event during creation. This ID is stored by Microsoft and remains accessible in the event's properties, allowing the client to identify the event independently of the server-generated IDs.

1. We now generate a deterministic `transactionId` for each insertion using the format `<database.uuid>_<record.id>`. This ID is unique to the Odoo record and remains stable across synchronization retries.
2. This `transactionId` is included in the payload of the event creation request within the `_microsoft_values` method of the `calendar.event` and `calendar.recurrence` models.
3. The matching logic in `MicrosoftEvent._load_odoo_ids_from_db` is extended with a fallback mechanism. If an incoming Outlook event cannot be matched by its server-generated IDs, the code checks for a `transactionId`. If the `transactionId` matches the current database UUID and contains a valid Odoo record ID, Odoo identifies the record it originally intended to create and links them.

This ensures that if an insertion response was previously lost due to a timeout, Odoo can still find and link the existing Outlook event during the next synchronization instead of creating a duplicate.

opw-5031073

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

Versions
--------
- 18.0+

Steps
-----
1. Enable the `Lock Confirmed Sales` option from settings
2. Create a new quotation and add a customer
3. Add a product that includes a document that has its visibility set to `Inside quote pdf`
4. Modify which documents (header, product document, etc) are attached to the quotation and their custom fields from the `Quote Builder` tab
5. Confirm the quotation and notice that the sale order is now locked

Issue
-----
Although the sale order is locked, you are still able to add/remove the documents, and you can also modify the custom fields. Adding/removing the headers and footers work as expected, however if you try to add or remove a product document it will look like your modification has been successful, but if you refresh the page you will discover it hasn't actually been saved. Even though you can't add or remove a product document, you still can modify the custom fields for these product documents.

Cause
-----
You are allowed to edit the headers, footers, and custom fields because there are no checks to stop you from doing so if the sale order is locked. The reason that adding or removing product documents doesn't work is that these are saved on the sale order line, which becomes read only when the sale order is locked.

Solution
--------
When the sale order is locked, disable adding/removing documents or modifying custom fields. It is only disabled from the frontend similarly to other fields in the locked sale order.

opw-5182258

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

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