Prerequisites:
------------------------------
1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket
2. From Settings, create one Alias Domain

Steps to reproduce:
------------------------------
1. Install Helpdesk module
2. Open Helpdesk Team > Settings
3. Inside Channels, Set the mail used for the incoming server and the alias created
4. Set Accept Emails From to Everyone
5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`)
6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail.
7. Open Incoming mail sever  > Click on Fetch Now
8. Open Created Contact

Observation:
------------------------------
The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost

Issue:
------------------------------
After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update.

https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369

Solution:
------------------------------
Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails

Note for reviewer
-----------------------------
After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address.

That said, we should also avoid automatically clearing or altering the existing value in the field.

Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint.


opw-5478067

Forward-Port-Of: odoo/enterprise#107808

An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation

Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```

Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown

Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.

Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.

target: saas-18.4
task-6034836

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#99784

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619