When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself.

To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved.

The fix will ensure extra dynamic reports follow their configured printed name.

Steps to reproduce:
1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report.
2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST').
3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”.
4. Add the duplicated report under Dynamic Reports.
5. Create a customer invoice and confirm it.
3. Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716

Forward-Port-Of: odoo/odoo#259597
Forward-Port-Of: odoo/odoo#259267

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

Forward-Port-Of: odoo/enterprise#113966

When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language.

### Steps to reproduce

1. Install the "Surveys" module and activate a second language (e.g., Dutch).
2. Create a survey and ensure its invitation template has translations for both languages.
3. Create two contacts: one with English as their language and another with Dutch.
4. On the survey, click "Share" and add both contacts as recipients.
5. Send the invitations.
6. The contact with Dutch preferred language receives the email in English.

### Cause

By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one.

opw-5868581

Forward-Port-Of: odoo/odoo#246778

Steps to reproduce:
-------------------
1. Activate JPY and create a JPY bank journal with ISO20022 as an
   outgoing payment method
2. Create a vendor (with a country) and add a trusted bank account
3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it
   using the ISO20022 method on the JPY journal
4. Create a batch payment containing that payment, with Batch Type
   Outbound, on the JPY journal, with ISO20022 as payment method
5. Validate the batch — the XML file is generated and attached
6. Download it

-> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has
no decimals. The file is rejected by banks.

The fix:
--------

Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d:

> Generating the xml file for iso20022 always generates the amount with
two decimals which is hard coded and can cause error for currencies without decimals for example JPY.
> The fix is to have the currency decimal number dynamically set through
the currency decimal places field.

opw-6103849

Forward-Port-Of: odoo/enterprise#113296