Issue
-----
When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour.

Steps to reproduce
-----
- Enable packages
- Create a product AAA tracked by SN
	- product category removal strategy set to "Smallest number of packages"
- Create a reception for 5 units
	- Generate serials
	- Put last line in pack
- Confirm reception
- Create delivery for 2 units of AAA
	- Mark as Todo
	- Change the quants taken: instead of SN 5, take SN 3 (so take SN 3 & 4)
- Create a delivery for 3 units of AAA
	- Mark as Todo

> Quantity reserved is one, it only reserved SN 5

Cause
-----
The problem arises in `_run_least_packages_removal_strategy_astar`. Because there is an available quant inside a package, we continue past

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

We end up at

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L724

The `generate_domain` function has a problem: if there sin't enough products inside packages to satisfy the demand, it searches for items not in packages to take from.

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L701-L705

This search is flawed, because it does not take into account the fact that the quant might already be reserved. So it expands the domain with an `AND` on quant ids that are not available.

This leads to `quants` in `_get_reserve_quantity` containing unavailable quants

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L866

This later gets "caught" in `available_quantity`

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L897

and the quants don't get reserved a second time thanks to

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L912-L914

but this also means the reservation is incomplete.

Note that calling `action_assign` a second time will correctly reserve the remaining quantities, as there is no package left to reserve in stock, so we do go in

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

and avoid the faulty logic.

Solution
-----
Ideally, we would use the value of `available_quantity` in our search domain. However, the field is not stored

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L88-L91

Our options are:
- make the field stored (not stable)
- add a search function
- filter reserved quants out of `single_item_ids`

First option is not stable. Second option requires subqueries to compare `quantity` and `reserved_quantity`. Third option is the least bad one, with only a very situational performance loss.

-----
Ticket:
opw-5972350

Forward-Port-Of: odoo/odoo#261568
Forward-Port-Of: odoo/odoo#256106

## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**

## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.

https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286

Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.

## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.

opw-6143128

Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#261935
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some strict validators, such as the German XRechnung validator, reject generated documents because the `EmbeddedDocumentBinaryObject` contains leading and trailing whitespace

### Cause:
Before 18.4, `_postprocess_invoice_ubl_xml()` used f-strings to generate the XML content

With this formatting, the result of:
`base64.b64encode(attachment_values['raw']).decode()` was indented together with the XML block, introducing unwanted whitespace and line breaks inside `EmbeddedDocumentBinaryObject`

### Steps to reproduce:
- Install `l10n_de` and switch to the DE Company
- In Settings, enable Peppol and Activate Electronic Invoicing
- Create and confirm an Invoice (Customer: DE Company, any product line with tax)
- Send the invoice via Peppol
- Check the generated XML attachment

### Before the fix:
The XML contains formatted content such as:
```xml
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf">
	content
</cbc:EmbeddedDocumentBinaryObject>
```
This formatting introduces leading/trailing whitespace and may be rejected by strict validators.

### After the fix:
The XML is generated without extra whitespace:
```xml
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf">content</cbc:EmbeddedDocumentBinaryObject>
```

opw-6121616

Forward-Port-Of: odoo/odoo#262472

Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner many2one (e.g. customer/vendor on an invoice) still used the old path: calling an IAP suggestion `iap_partner_autocomplete_add_tags`

Steps to reproduce:
-------------------
* Open a customer invoice (draft).
* On Customer, search a company name and pick a Partner Autocomplete line to create a new company.
* Save the quick-create dialog.

> Observation:
The new contact still had Partner Tags populated from DnB industry data (UNSPSC), unlike contacts created or enriched from the contact form autocomplete.
(see video on ticket to avoid using more IAP credits)

Why the fix:
------------
Align `res_partner_many2one` with `field_partner_autocomplete`: do not call `iap_partner_autocomplete_add_tags`.
From task-5373200, industries from DnB must no longer be added as Partner Tags.

opw-5972360

Forward-Port-Of: odoo/odoo#260078

**Steps to reproduce:**
* Install `l10n_in` module.
* Go to Accounting > Settings.
* Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username
* Uncheck `Registered Under GST`.
* Try to modify any setting and save.

**Observed behavior:**
* A `Missing Required Fields` error is raised even though no visible field is missing a value.

**Cause:**
* The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`.
* However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`.
* Since both features default to enabled, the field remained required even when invisible, blocking any settings save.

**Fix:**
* Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled.

opw-6133001

Forward-Port-Of: odoo/enterprise#114423

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.

opw-6074833

Forward-Port-Of: odoo/odoo#262334
Forward-Port-Of: odoo/odoo#258370

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

Forward-Port-Of: odoo/enterprise#113845
Forward-Port-Of: odoo/enterprise#112041