Sending marketing cards from an event can target the wrong event when the selected campaign was designed on a record belonging to another event.

### Steps to reproduce


1. Create a marketing card campaign on model "Event Track". Its "Preview On" record belongs to event A.
2. Open event B and click "Send Cards".
3. Select the campaign.

The recipient domain initially targets event B, but after selecting the campaign it is rebuilt using event A from the preview record. The mailing therefore sends cards to the wrong event.

### Cause


"Send Cards" opens a `mailing.mailing` form. The event the action was started from is only stored in the context through `default_mailing_domain`; it is not stored on the mailing record.

Selecting a campaign recomputes `mailing_domain`, which rebuilds it from the target model default domain, so the event the domain carried is lost. The current code then rebuilds the event restriction using `card_campaign_id.preview_record_ref.event_id`, but this record only represents the campaign preview. It does not represent the event the user is sending cards for, and campaigns can be reused across events.

### Fix


Read the event out of the mailing domain before the super call rebuilds it, and restrict the rebuilt domain to that event. The event then stays with the mailing on any later recompute, without the caller having to pass it.

When the domain restricts no event, which is the case when the mailing is created directly from a campaign, fall back to the preview record event.

opw-6431427

Forward-Port-Of: odoo/odoo#280073

**Steps to reproduce:**
1. Install Accounting and l10n_be and switch to the Belgian company
2. In the settings, set the discount account (`708000`) on Customer Invoices under "Default Accounts" and enable analytic accounting
3. Go to [Accounting -> Configuration -> Analytic Accounts] and create 4 new accounts with "Project" plan (i.e 1,2,3,4)
4. Create a new invoice with two lines, each having 2 of the analytic accounts with 50% each.
5. Set the price to 1000 and a 10% discount for each line then save.
6. Edit the second line and set the discount to 20%.
7. Open the Journal Items tab

**Issue:**
 - When an invoice contains multiple lines with analytic distributions, changing the discount percentage on any line other than the first fails to correctly update the analytic distribution percentages on the corresponding discount journal items.
- The analytic account distribution splits the percentage evenly across both accounts event if they are not split 50/50

**Why this happens:**
- This occurred because `_compute_discount_allocation_needed` iterated over `self` to populate target changes. When only one line was modified, `self` contains that line only which is correctly updated with the new analytic distribution. Later in the execution in `_sync_dynamic_line`, particularly in https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move.py#L2263-L2274 The first line in `computed_needed` is what gets set in res, and subsequent lines only modify the field if it's monetary. So if the second invoice line is the one  updated, it will never override the `analytic_distribution` with the updated values, leaving stale values in that field.
- The code iterated directly over `line.analytic_distribution` dictionary keys (the account IDs) rather than its `.items()`. This caused it to ignore the individual percentage value splits (e.g. 60/40), accumulating the un-weighted full discount amount to each account ID. https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move_line.py#L1044-L1052

**Fix:**
- Change the processing loop  inside `_compute_discount_allocation_needed` from `self` to `self.move_id.line_ids` to calculate the correct `analytic_distribution` across all records.
- Applying the factored weight ratio (`amount * (percentage / 100.0)`) to `distribution_totals`

opw-6362084

Forward-Port-Of: odoo/odoo#280302
Forward-Port-Of: odoo/odoo#275070

**Steps to reproduce:**
1. Install Accounting and l10n_be and switch to the Belgian company
2. In the settings, set the discount account (`708000`) on Customer Invoices under "Default Accounts" and enable analytic accounting
3. Go to [Accounting -> Configuration -> Analytic Accounts] and create 4 new accounts with "Project" plan (i.e 1,2,3,4)
4. Create a new invoice with two lines, each having 2 of the analytic accounts with 50% each.
5. Set the price to 1000 and a 10% discount for each line then save.
6. Edit the second line and set the discount to 20%.
7. Open the Journal Items tab

**Issue:**
 - When an invoice contains multiple lines with analytic distributions, changing the discount percentage on any line other than the first fails to correctly update the analytic distribution percentages on the corresponding discount journal items.
- The analytic account distribution splits the percentage evenly across both accounts event if they are not split 50/50

**Why this happens:**
- This occurred because `_compute_discount_allocation_needed` iterated over `self` to populate target changes. When only one line was modified, `self` contains that line only which is correctly updated with the new analytic distribution. Later in the execution in `_sync_dynamic_line`, particularly in https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move.py#L2263-L2274 The first line in `computed_needed` is what gets set in res, and subsequent lines only modify the field if it's monetary. So if the second invoice line is the one  updated, it will never override the `analytic_distribution` with the updated values, leaving stale values in that field.
- The code iterated directly over `line.analytic_distribution` dictionary keys (the account IDs) rather than its `.items()`. This caused it to ignore the individual percentage value splits (e.g. 60/40), accumulating the un-weighted full discount amount to each account ID. https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move_line.py#L1044-L1052

**Fix:**
- Change the processing loop  inside `_compute_discount_allocation_needed` from `self` to `self.move_id.line_ids` to calculate the correct `analytic_distribution` across all records.
- Applying the factored weight ratio (`amount * (percentage / 100.0)`) to `distribution_totals`

opw-6362084

Forward-Port-Of: odoo/odoo#280302
Forward-Port-Of: odoo/odoo#275070

### Issue before this commit:
When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F".

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company
3. Activate ZUGFeRD from settings
4. Go to settings and click on Configure Document Layout and insert something like <a href="mailto:info@company.de_skr03example.com"> info@company.de_skr03example.com</a> into the footer
5. Create an invoice to Bloem GmbH and send it through ZUGFeRD
6. Download PDF and upload it on https://www.portinvoice.com/
7. See error: An annotation dictionary does not contain the key F. With the exception of annotation dictionaries whose subtype value is Popup, all annotation dictionaries must contain the key F.

### Cause of the issue:
The underlying PDF generation engine creates hyperlinks as PDF annotations but omits the /F (Flags) key. During Odoo's PDF/A conversion process, these annotations were left unmodified. This violates the strict PDF/A specification, which mandates that all non-Popup annotations must explicitly define the /F key.

### Reason to introduce the fix:
This fix ensures full PDF/A compliance by iterating through all page annotations and injecting the missing /F key for any annotation that is not a Popup. This allows users to safely include clickable links in their invoice templates without breaking electronic document validation.

opw-6388212

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

Forward-Port-Of: odoo/odoo#279024

Currently, users encounter a traceback when attempting to print the traceability report for a manufacturing order.

## Steps to produce:
- Install Manufacturing without demo data.
- Enable Lots & Serial Numbers in Settings.
- Create two products: Car and Engine.
- Configure Engine to use Unique Serial Number tracking (Inventory →Traceability).
- Set the on-hand quantity of Engine to 1 with serial number 0001.
- Create a BoM for Car using Engine as a component.
- Create and confirm a manufacturing order for Car.
- Click `Consumed` for the component and click Produce All.
- Navigate to Lots & Serial Numbers → Engine → 0001 → Traceability.
- Click the arrow next to the manufacturing order reference, then click Print.

## Observed Behavior:
An `Arbitrary Uncaught Python Exception` traceback is raised, resulting in a 404 error.

## Root Cause:
This issue occurs because, when the user clicks the arrow button in the traceability report, the template [1] invokes the `onClickUpDownStream` function.

This function adds the URL `/stock/output_format/stock/active_id` to the context , as shown in [2]. Later, when the user clicks the Print button, `onClickPrint()` [3] constructs the print URL using the `controllerUrl` value by replacing the active model and active ID placeholders with values from the context.

However, the URL stored in the context contains `/active_id` instead of `:active_id`. As a result, the placeholder replacement does not occur, leaving the URL unchanged. This causes the print action to use an invalid URL, ultimately resulting in a 404 error.

As shown in [4], `controllerUrl` is assigned directly from the context.

[1]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.xml#L52-L56 [2]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L105-L118 [3]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L120-L131 [4]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L53-L55

## Solution:
Pass the correct URL in the context so that the active ID placeholder can be replaced correctly during the print action. This ensures that the generated print URL is valid, allowing the user to print the report without encountering any errors.


opw-6372834

Forward-Port-Of: odoo/odoo#279844
Forward-Port-Of: odoo/odoo#276449

Steps to reproduce
------------------
1. Install `l10n_pe_pos`.
2. Create a contact with the identification type DNI and a number.
3. Sell a product to this contact and print the receipt. -> the receipt shows "RUC" in front of the number, even though the number is a DNI and not a RUC.

Why it's happening
------------------
Since `aeaca097ae39` the number of the contact is printed with a label in front of it, before there was no label at all. This label is the `vat_label` of the country, so "RUC" for Peru. But in Peru each contact can have a different identifier, and the type is on the contact in `l10n_latam_identification_type_id`.

The fix
-------
In `l10n_pe_pos` we set `partner_vat_label` with the name of the identification type of the contact. If the contact has no identification type we keep the number alone.

Before vs After for a customer identified with DNI
-------------------------------------------------
<img width="465" height="203" alt="Capture d’écran 2026-07-30 à 14 45 17" src="https://github.com/user-attachments/assets/85c921df-c1fd-430b-b4e6-341bc183bd61" />

<img width="467" height="253" alt="Capture d’écran 2026-07-30 à 14 49 36" src="https://github.com/user-attachments/assets/3ac243c6-04fe-47a4-a662-c59b88276db7" />





opw-6422619

Issue:
The MyInvois payload computed `cbc:PrepaidAmount` as `amount_total - amount_residual`, treating every reconciled payment as a prepayment. A payment made on or after the invoice date is an ordinary settlement, not a deposit, but the code recognized it as one anyway. The values reported for `PrepaidAmount` were wrong regardless of the invoice date, and for a fully paid invoice this also collapsed `PayableAmount` to 0.00, which LHDN rejects.

Root Cause:
LHDN only considers a reconciled payment a genuine deposit if it was received before the invoice date. The code applied no date condition at all, so any payment reconciled against the invoice was added to `PrepaidAmount` and reduced `PayableAmount` accordingly.

Fix:
Only sum reconciled payment partials whose date is strictly earlier than the invoice date as prepaid, so regular payments are no longer misclassified as deposits. As a safety net, if the valid prepaid sum still covers the full invoice amount (e.g. a full advance payment), reset it to 0 so `PayableAmount` always reflects the full amount_total instead of being reported as 0. Also omit the `PrepaidPayment` node entirely when there is no genuine prepayment, rather than emitting it with a 0.00 amount.

[Task-6404296](https://www.odoo.com/odoo/my-tasks/6404296)

Forward-Port-Of: odoo/odoo#280569
Forward-Port-Of: odoo/odoo#278010

Steps to reproduce:
- From the website editor, open the Theme tab.
- Upload a custom font.
- Open the media dialog and go to the "Documents" tab.

Issue:
The uploaded font files appeared in the Documents tab. When a zip file was uploaded, every font it contained appeared individually, along with the generated "CSS font face" attachment.

Cause:
Fonts uploaded through `/website/theme_upload_font` are created as public attachments. The Documents tab of the media dialog lists every public attachment that is not an image or an asset, so the font files (mimetype `font/...`), their font face declaration (mimetype `text/css`) and googleFontMetadata (server caches it as public attachment) were listed.

Fix:
Exclude those attachments from the Documents tab domain:
- whose mimetype starts with `font/`,
- whose description matches the font face declarations created in `snippets.options.js`.
- whose name equals "googleFontMetadata".

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

Forward-Port-Of: odoo/odoo#280563
Forward-Port-Of: odoo/odoo#275838

**Steps to reproduce:**

- Install l10n_pl_edi and enable Allow KSeF integration from 
  **Accounting** settings. 
- Switch to a Polish company.
- Create an EU customer with a valid VAT number.
- Create a sale order containing a service product taxed 
  with 0% Steel (or any tax that has a tag of K11).
- Confirm the sale order and create a down payment invoice. 
- Send the invoice to KSeF and inspect the generated XML. 

**Observed behavior:**

The generated KSeF XML does not contain the `P_13_8` field. 

**Cause:**

For invoices involving the tax of tag `K11` (mainly these taxes are used for the supplies 
that are outside the territory of Poland), the value corresponding to `P_13_8` was not 
being assigned during XML generation, causing the tag to be omitted from the exported 
KSeF document.

**Fix:**

Populate the value of `P_13_8` during KSeF XML generation for invoices, ensuring the 
field is correctly included in the exported XML. 

This PR updates the computation of tag `P_13_10` with its test case to ensure consistency 
with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

**opw**-6294181

Forward-Port-Of: odoo/odoo#280830
Forward-Port-Of: odoo/odoo#276887

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

Forward-Port-Of: odoo/odoo#279716
Forward-Port-Of: odoo/odoo#276485

Steps to reproduce:
- From the website editor, open the Theme tab.
- Upload a custom font.
- Open the media dialog and go to the "Documents" tab.

Issue:
The uploaded font files appeared in the Documents tab. When a zip file was uploaded, every font it contained appeared individually, along with the generated "CSS font face" attachment.

Cause:
Fonts uploaded through `/website/theme_upload_font` are created as public attachments. The Documents tab of the media dialog lists every public attachment that is not an image or an asset, so the font files (mimetype `font/...`), their font face declaration (mimetype `text/css`) and googleFontMetadata (server caches it as public attachment) were listed.

Fix:
Exclude those attachments from the Documents tab domain:
- whose mimetype starts with `font/`,
- whose description matches the font face declarations created in `snippets.options.js`.
- whose name equals "googleFontMetadata".

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

Forward-Port-Of: odoo/odoo#280563
Forward-Port-Of: odoo/odoo#275838

**Steps to reproduce:**

- Install l10n_pl_edi and enable Allow KSeF integration from 
  **Accounting** settings. 
- Switch to a Polish company.
- Create an EU customer with a valid VAT number.
- Create a sale order containing a service product taxed 
  with 0% Steel (or any tax that has a tag of K11).
- Confirm the sale order and create a down payment invoice. 
- Send the invoice to KSeF and inspect the generated XML. 

**Observed behavior:**

The generated KSeF XML does not contain the `P_13_8` field. 

**Cause:**

For invoices involving the tax of tag `K11` (mainly these taxes are used for the supplies 
that are outside the territory of Poland), the value corresponding to `P_13_8` was not 
being assigned during XML generation, causing the tag to be omitted from the exported 
KSeF document.

**Fix:**

Populate the value of `P_13_8` during KSeF XML generation for invoices, ensuring the 
field is correctly included in the exported XML. 

This PR updates the computation of tag `P_13_10` with its test case to ensure consistency 
with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

**opw**-6294181

Forward-Port-Of: odoo/odoo#280830
Forward-Port-Of: odoo/odoo#276887

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

Forward-Port-Of: odoo/odoo#279716
Forward-Port-Of: odoo/odoo#276485

Steps:
- Install l10n_co module.
- Set `CO company` on user.
- Go to address page on portal address.
- Set `Company Name`, `ID Type` and `ID Number` on the address page.

Issue:
- Not able to save address without any error message on the address page and in logger it raise validation error.

Cause:
- In address we actually do vat validation before creation/updation and if there is any issue with vat number then add it into invalid_fields instead raising any validation error, so here when user set `Company name` on address it try to create parent company and again do vat validation and it raise validation error because `ID Type` on customer is not propagated to parent when creating parent company from portal.

Fix:
- Skip vat validation on parent company creation from address.

To-do: We also need to pass `ID type` and other accounting related values when creating parent company from customer or make them dependent like `Vat`.

Issued PR: https://github.com/odoo/odoo/pull/264356

opw-6434127

### Issue before this commit:
When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F".

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company
3. Activate ZUGFeRD from settings
4. Go to settings and click on Configure Document Layout and insert something like <a href="mailto:info@company.de_skr03example.com"> info@company.de_skr03example.com</a> into the footer
5. Create an invoice to Bloem GmbH and send it through ZUGFeRD
6. Download PDF and upload it on https://www.portinvoice.com/
7. See error: An annotation dictionary does not contain the key F. With the exception of annotation dictionaries whose subtype value is Popup, all annotation dictionaries must contain the key F.

### Cause of the issue:
The underlying PDF generation engine creates hyperlinks as PDF annotations but omits the /F (Flags) key. During Odoo's PDF/A conversion process, these annotations were left unmodified. This violates the strict PDF/A specification, which mandates that all non-Popup annotations must explicitly define the /F key.

### Reason to introduce the fix:
This fix ensures full PDF/A compliance by iterating through all page annotations and injecting the missing /F key for any annotation that is not a Popup. This allows users to safely include clickable links in their invoice templates without breaking electronic document validation.

opw-6388212

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

Forward-Port-Of: odoo/odoo#279024

**Steps to reproduce:**
1. Install Accounting and l10n_be and switch to the Belgian company
2. In the settings, set the discount account (`708000`) on Customer Invoices under "Default Accounts" and enable analytic accounting
3. Go to [Accounting -> Configuration -> Analytic Accounts] and create 4 new accounts with "Project" plan (i.e 1,2,3,4)
4. Create a new invoice with two lines, each having 2 of the analytic accounts with 50% each.
5. Set the price to 1000 and a 10% discount for each line then save.
6. Edit the second line and set the discount to 20%.
7. Open the Journal Items tab

**Issue:**
 - When an invoice contains multiple lines with analytic distributions, changing the discount percentage on any line other than the first fails to correctly update the analytic distribution percentages on the corresponding discount journal items.
- The analytic account distribution splits the percentage evenly across both accounts event if they are not split 50/50

**Why this happens:**
- This occurred because `_compute_discount_allocation_needed` iterated over `self` to populate target changes. When only one line was modified, `self` contains that line only which is correctly updated with the new analytic distribution. Later in the execution in `_sync_dynamic_line`, particularly in https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move.py#L2263-L2274 The first line in `computed_needed` is what gets set in res, and subsequent lines only modify the field if it's monetary. So if the second invoice line is the one  updated, it will never override the `analytic_distribution` with the updated values, leaving stale values in that field.
- The code iterated directly over `line.analytic_distribution` dictionary keys (the account IDs) rather than its `.items()`. This caused it to ignore the individual percentage value splits (e.g. 60/40), accumulating the un-weighted full discount amount to each account ID. https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move_line.py#L1044-L1052

**Fix:**
- Change the processing loop  inside `_compute_discount_allocation_needed` from `self` to `self.move_id.line_ids` to calculate the correct `analytic_distribution` across all records.
- Applying the factored weight ratio (`amount * (percentage / 100.0)`) to `distribution_totals`

opw-6362084

Forward-Port-Of: odoo/odoo#280302
Forward-Port-Of: odoo/odoo#275070

### Issue before this commit:
When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F".

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company
3. Activate ZUGFeRD from settings
4. Go to settings and click on Configure Document Layout and insert something like <a href="mailto:info@company.de_skr03example.com"> info@company.de_skr03example.com</a> into the footer
5. Create an invoice to Bloem GmbH and send it through ZUGFeRD
6. Download PDF and upload it on https://www.portinvoice.com/
7. See error: An annotation dictionary does not contain the key F. With the exception of annotation dictionaries whose subtype value is Popup, all annotation dictionaries must contain the key F.

### Cause of the issue:
The underlying PDF generation engine creates hyperlinks as PDF annotations but omits the /F (Flags) key. During Odoo's PDF/A conversion process, these annotations were left unmodified. This violates the strict PDF/A specification, which mandates that all non-Popup annotations must explicitly define the /F key.

### Reason to introduce the fix:
This fix ensures full PDF/A compliance by iterating through all page annotations and injecting the missing /F key for any annotation that is not a Popup. This allows users to safely include clickable links in their invoice templates without breaking electronic document validation.

opw-6388212

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

Forward-Port-Of: odoo/odoo#279024

Description of the issue/feature this PR addresses:

Downloading an attachment from the file viewer fails with a `405 Method Not Allowed` error when the attachment belongs to a Discuss channel.

I've already submitted a ticket to Odoo: #6430586

Steps to reproduce (on a 18.0 runbot):
1. open Discuss and send an image in a channel
2. click the image to open the file viewer
3. click the download button (either the one in the header or the one in the bottom
   toolbar)

The server rejects the request:

```
POST /discuss/channel/1/image/519861?filename=image.png&unique=32647b0f&download=true  405
```

and the user gets a `RPC_ERROR: Arbitrary Uncaught Python Exception` dialog reporting `405 Method Not Allowed`.

Cause: `download()` always issues a POST request, while the routes serving the attachments of a discuss channel only allow GET:

* `/discuss/channel/<int:channel_id>/attachment/<int:attachment_id>`
* `/discuss/channel/<int:channel_id>/image/<int:attachment_id>`

so the request never reaches the controller. Downloading the very same attachment from the attachment card in the conversation still works, because that one is a plain anchor navigation (GET).

This is a regression from fb152985f4b8 ("[FIX] web: download FileViewer files via blob helper"), which routed the file viewer download through `download()` in order to honor the filename sent by the server in the `Content-Disposition` header.

Only 18.0 is affected: saas-18.1 and saas-18.2 do not have the commit that introduced the regression, and from saas-18.3 on, the `urlRoute` override was dropped and channel attachments are served through the standard `/web/content` and  /web/image` routes, which are not restricted to GET. 
The download is still sent with POST on those branches though, hence forward-porting this up to master.

Current behavior before PR:

Downloading a Discuss channel attachment from the file viewer raises a 405 error and the file is not downloaded. Images and other file types are equally affected.

Desired behavior after PR is merged:

The file is downloaded, keeping the filename advertised by the server. The download is performed with a GET request through `downloadFile()`, which still goes through the blob helper, so the fix of fb152985f4b8 is preserved. This is already the way a file is downloaded from its url in `readonly_file.js`.

Added a test that downloads an image attachment of a channel from the file viewer and asserts the request is a GET on the channel attachment route. It fails before this fix with `POST /discuss/channel/1/image/1`.

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

Forward-Port-Of: odoo/odoo#279232

## Steps to Reproduce:
- Install the Time Off module.
- Create an Accrual Plan without any milestones.
- Create an Accrual Allocation using the newly created accrual plan.
- Approve the allocation.
- Add a milestone to the accrual plan.
- Create a new Time Off request after the allocation start date.
- Save the record.

## Error:
`TypeError - '>' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
`lastcall` is initialized by method `_add_lastcalls()`, which is only called at create and write. When an accrual allocation is created with an accrual plan that has no milestones, `_add_lastcalls()` returns early because `level_ids` is empty, leaving `lastcall` set to `False`. - [1]

If a milestone is added later, `lastcall` is compared with `first_level_start_date`, resulting in a comparison between boolean and datetime, which raises an error.

## Fix:
When `lastcall` is not set, default it to `first_level_start_date`.

[1] - https://github.com/odoo/odoo/blob/27036bea232572ba692fbb95387911eb453266bf/addons/hr_holidays/models/hr_leave_allocation.py#L703-L706

sentry-7615375197

### Issue before this commit:
When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F".

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company
3. Activate ZUGFeRD from settings
4. Go to settings and click on Configure Document Layout and insert something like <a href="mailto:info@company.de_skr03example.com"> info@company.de_skr03example.com</a> into the footer
5. Create an invoice to Bloem GmbH and send it through ZUGFeRD
6. Download PDF and upload it on https://www.portinvoice.com/
7. See error: An annotation dictionary does not contain the key F. With the exception of annotation dictionaries whose subtype value is Popup, all annotation dictionaries must contain the key F.

### Cause of the issue:
The underlying PDF generation engine creates hyperlinks as PDF annotations but omits the /F (Flags) key. During Odoo's PDF/A conversion process, these annotations were left unmodified. This violates the strict PDF/A specification, which mandates that all non-Popup annotations must explicitly define the /F key.

### Reason to introduce the fix:
This fix ensures full PDF/A compliance by iterating through all page annotations and injecting the missing /F key for any annotation that is not a Popup. This allows users to safely include clickable links in their invoice templates without breaking electronic document validation.

opw-6388212

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

Forward-Port-Of: odoo/odoo#279024