### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will
set the state of the 'mail.message' as 'auto_comment' -introduced in https://github.com/odoo/odoo/pull/94018/commits/d1dd307555ac78841384d1158de5a0a7787370db - and add 'auto_comment'
to the domain of the field website_message_id which is for the messages
shown to the portal user in his view

P.S. LNA confirmed that we need to show it to the portal user.

opw-4459754

Forward-Port-Of: odoo/odoo#210807
Forward-Port-Of: odoo/odoo#194401

Issue
=====
In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`:

```python
self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [
    {'lot_id': lot_product_b[0].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[0].id, 'quantity': 0, 'value': 1.5},
    {'lot_id': lot_product_b[1].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[1].id, 'quantity': 0, 'value': 1.5},
    {'lot_id': lot_product_a[0].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[0].id, 'quantity': 0, 'value': 1},
    {'lot_id': lot_product_a[1].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[1].id, 'quantity': 0, 'value': 1},
    {'lot_id': lot_product_a[2].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[2].id, 'quantity': 0, 'value': 1},
])
```
This issue is sometime the records order is not the expected one.

Cause of the issue
==================

By doing `recordset.sorted('product_id')`, it will sort the records by compare their `product_id` records, using the python built-in `sorted`. The built-in `sorted` function simply check if record A is lower than record B, using the < operation. But in Odoo, comparing two recordsets is equal than comparing their ids as a `set`:
```python
def __lt__(self, other):
    try:
        if self._name == other._name:
            return set(self._ids) < set(other._ids)
    except AttributeError:
        pass
    return NotImplemented
```
In python, the comparaison between two sets compares is a set is a subset of the other one, which means than:
```python
{1} < {2}     # is false
{1} < {2, 1}  # is true
```
So, comparing SVLs by their product won't sort them by their product's id. If we want to do that, we have to explicitly do it by passing a function as the `sorted` `key` argument.

For more information, see:
-https://docs.python.org/3/library/functions.html#sorted -https://docs.python.org/3/reference/expressions.html#comparisons

runbot-build-error: 99086

Forward-Port-Of: odoo/odoo#210514

When manually changing the `discount_date` field to null in an invoice related to a customer with an Early price discount payment term, the customer will face a type error on the website when accessing their invoices.

**Steps to reproduce:**

* Install the accountant module
* Create a new invoice for the current user as a customer (e.g., Mitchel Admin).
* Set `2/7 Net 30` in payment terms and add any product.
* Go to Journal Items and make Discount Date visible if not already visible.
* Under the account field `121000 Account Receivable` remove the discount date
  and confirm the invoice.
* Open portal View (/my) and click on Your Invoices >>> Error occurs.

`TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'`

**Solution:**
We use if else blocks to check if `discount_date` exists for the `days_left calculation`; if it exists,
do the calculation as usual if `discount_date` is in future. Otherwise, set `days_left` to zero and continue the function as usual.

Sentry-6395559503

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

Forward-Port-Of: odoo/odoo#205306

**Problem**
Users in the `hr_attendance.group_hr_attendance_officer` group are blocked from opening the Attendance app when they lack the manager role.

**Steps to reproduce**
 - Remove `hr_attendance.group_hr_attendance_manager` from your user.

 - Add `hr_attendance.group_hr_attendance_officer`.

 - Open the Attendance app: access is denied.

**Cause**
The method [read_group_employee_id](https://github.com/odoo/odoo/blob/cd428bd75b63f96c67942be5457d0afdb00d29b0/addons/hr_attendance/models/hr_attendance.py#L672) applies a domain on attendance_manager_id, which incorrectly prevents officers from passing the check.

**Solution**
Switch the group on the attendance_manager_id field in hr_employee.py so that officers aren’t inadvertently blocked. Officers will still be restricted from reading records they don’t manage.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#209586

**Description of the issue/feature this PR addresses:**
- The contact-us form allows task creation without a project (project_id = None).
These tasks are assigned to odoobot, have no followers, and no project, making
them inaccessible due to ACL restrictions. 

**steps to reproduce**
1. Install website_form_project.
2. Edit the contact-us form submit button.
3. Set action to 'Create a task' and select 'None' for the project.
4. Save and submit the form.

**Observation**
- Tasks created under such configuration are hidden in the UI and trigger access
errors when trying to open them.

![access error](https://github.com/user-attachments/assets/e5688152-d78b-4628-a0bd-d9f58e2ca442)

Desired behavior after PR is merged:
- Making the project field required, the created tasks will now be accessible/visible

[opw-4664601](https://www.odoo.com/odoo/project/49/tasks/4664601)

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

Forward-Port-Of: odoo/odoo#210109
Forward-Port-Of: odoo/odoo#207871

## Issue:

When converting a lead to an opportunity, a wizard
(`crm.lead2opportunity.partner`) is shown. This allows merging
duplicated leads.

However, if the most recently created lead is selected as the primary,
the wizard record may be deleted unexpectedly. This usually goes
unnoticed in the UI, as the wizard disappears after the operation.

The issue becomes critical when overriding the conversion flow via a
custom module or in future changes to the core logic. In those cases,
the deletion of the wizard can lead to empty recordsets and errors.

#### Affected versions: 16.0 and later.

## Explanation

The `crm.lead2opportunity.partner` model has a `Many2one` field
`lead_id` that is being deleting on cascade which is the default
for m2o fields on transient models.

During lead conversion, action_apply() calls _action_merge() or
_action_convert(). In _action_merge(), non-primary leads are
unlinked. If the primary lead is the last created one, it differs
from the one referenced by the wizard. This causes lead_id to be
unset, triggering the cascade and deleting the wizard.

## Impact:

If a custom module overrides action_apply() or _action_merge() and
calls super() first, it may operate on an empty recordset, leading
to failures when trying to access data or call methods.

## To reproduce:

With debugger:

- Set a breakpoint on the unlink call inside _action_merge
- After unlink, calling self.exists() on the wizard will return an empty recordset

With a custom module:

- Override action_apply() or _action_merge()
- Call super() first
- Try to merge leads and select the most recent one as primary
- The wizard record will be deleted before your custom logic executes, and will raise a "Record does not exist or has been deleted."

OPW-4773172

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

Forward-Port-Of: odoo/odoo#209795

This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval.

Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6.

This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval.

opw-4790119

Forward-Port-Of: odoo/enterprise#85967
Forward-Port-Of: odoo/enterprise#85548

### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view

opw-4459754

Forward-Port-Of: odoo/enterprise#85969
Forward-Port-Of: odoo/enterprise#82352

…vailability

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The `preparation_time` (`Security Time`) field is used at the sale order line creation to modify the `reservation_begin` value: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L447-L453 In particular, the `preparation_time` of the product creates a difference between the `order_id.rental_start_date` and the `reservation_begin`. This is porblematic since the `rental_start_date` is used to generate the dates of the deliveries taken into account by the forecast:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L354-L362 but the quantity considered as rented does not and is purely based on the `reservation_begin` of the line:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/product_product.py#L113-L117 In particular, the qunaities are not yet accounted ithe stock forecast by the `virtual_available` value of the product:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L129-L132 But will incorrectly be found and read by the rental forecast: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L133-L140

opw-4552760

Forward-Port-Of: odoo/enterprise#85949