Steps to reproduce:
* Install `l10n_mx_edi` (or `l10n_sa_edi`).
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

Observed behavior:
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

Cause:
* `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`.  However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated.

Fix:
* Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain.
* Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call.

This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic.

opw-6228268

Forward-Port-Of: odoo/odoo#271489

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Forward-Port-Of: odoo/odoo#271795
Forward-Port-Of: odoo/odoo#269743

The chatter recipients input always added a "Create" option to its autocomplete dropdown, even when the field held no text. The feature that introduced this input, https://github.com/odoo/odoo/commit/3b985d2c4239fe702c1a56bef04fc112af39e954, wired that option to create a res.partner straight away. Selecting "Create" with an empty input therefore created a partner with no name, displayed everywhere as "Unnamed".

The email popover that opens for a recipient without an address then offered a Discard button, but the empty partner was already saved. The same sequence could be repeated to accumulate nameless contacts, which later raise a missing name error when opened in the Contacts app.

Only add the "Create" option when the typed term resolves to a name or an email, in getAutoCompleteSources of recipients_input.js. An input with no usable text has nothing to create from, which matches the standard many2one autocomplete that only offers creation once text is entered.

Steps to reproduce:
1. Open any record with a chatter
2. Click "Send message"
3. In the recipients field type a character then delete it, leaving the field empty with the dropdown still open
4. Click the "Create" option
5. On the "What's the email address of Unnamed?" popover, click Discard

=> A blank "Unnamed" contact is created, and repeating the steps creates more

Ticket [link](https://www.odoo.com/odoo/action-4043/5942428)
opw-5942428


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

Forward-Port-Of: odoo/odoo#250973

The chatter recipients input always added a "Create" option to its autocomplete dropdown, even when the field held no text. The feature that introduced this input, https://github.com/odoo/odoo/commit/3b985d2c4239fe702c1a56bef04fc112af39e954, wired that option to create a res.partner straight away. Selecting "Create" with an empty input therefore created a partner with no name, displayed everywhere as "Unnamed".

The email popover that opens for a recipient without an address then offered a Discard button, but the empty partner was already saved. The same sequence could be repeated to accumulate nameless contacts, which later raise a missing name error when opened in the Contacts app.

Only add the "Create" option when the typed term resolves to a name or an email, in getAutoCompleteSources of recipients_input.js. An input with no usable text has nothing to create from, which matches the standard many2one autocomplete that only offers creation once text is entered.

Steps to reproduce:
1. Open any record with a chatter
2. Click "Send message"
3. In the recipients field type a character then delete it, leaving the field empty with the dropdown still open
4. Click the "Create" option
5. On the "What's the email address of Unnamed?" popover, click Discard

=> A blank "Unnamed" contact is created, and repeating the steps creates more

Ticket [link](https://www.odoo.com/odoo/action-4043/5942428)
opw-5942428


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

Forward-Port-Of: odoo/odoo#250973

Steps to reproduce:
* Install `l10n_mx_edi` (or `l10n_sa_edi`).
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

Observed behavior:
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

Cause:
* `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`.  However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated.

Fix:
* Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain.
* Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call.

This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic.

opw-6228268

Forward-Port-Of: odoo/odoo#271489

The chatter recipients input always added a "Create" option to its autocomplete dropdown, even when the field held no text. The feature that introduced this input, https://github.com/odoo/odoo/commit/3b985d2c4239fe702c1a56bef04fc112af39e954, wired that option to create a res.partner straight away. Selecting "Create" with an empty input therefore created a partner with no name, displayed everywhere as "Unnamed".

The email popover that opens for a recipient without an address then offered a Discard button, but the empty partner was already saved. The same sequence could be repeated to accumulate nameless contacts, which later raise a missing name error when opened in the Contacts app.

Only add the "Create" option when the typed term resolves to a name or an email, in getAutoCompleteSources of recipients_input.js. An input with no usable text has nothing to create from, which matches the standard many2one autocomplete that only offers creation once text is entered.

Steps to reproduce:
1. Open any record with a chatter
2. Click "Send message"
3. In the recipients field type a character then delete it, leaving the field empty with the dropdown still open
4. Click the "Create" option
5. On the "What's the email address of Unnamed?" popover, click Discard

=> A blank "Unnamed" contact is created, and repeating the steps creates more

Ticket [link](https://www.odoo.com/odoo/action-4043/5942428)
opw-5942428


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

Forward-Port-Of: odoo/odoo#250973

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238