We previously took into account all possible Message-IDs found in the References header of incoming messages. We also don't try to match the `In-Reply-To` header separately, since it is supposed to be appended to the `References` header, when present.

This is all specified in RFC5322, section 3.6.4:
   https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4

However, for very long threads, the `References` field can contain dozens or even hundreds of previous Message-IDs, even though we generally care only about the last one.

This can be an issue for databases with a large number of messages, as the query planner could mistakenly choose a suboptimal plan (e.g. a Seq Scan or filtered Index Scan), rather than looping on the `message_id` index, which is the best plan.

Here we truncate the list of References to only include the last 32 ones. For most threads this will make no difference, as they have less than 32 referencs. For very long threads it should still pick up the last known Message-ID without trouble. And if the last 32 messages aren't known by the system, it's unlikely that the message should still be considered part of earlier threads - it's been sidetracked elsewhere.

PS: also simplify the `order` clause, as no secondary sort criterion is going to work after `ORDER BY id`.

When User opens an appointment with resource that does not have Opening Hours,
a traceback will appear.

Steps to reproduce the error:
- Go to 'Appointments' > Configuration > Resources >
  Create a new Resource without opening hours (ex. court) > Save
- Create new Appointment > Availability on: resources > Resource: court > Save
- Click on Go to website or Preview

Traceback:
```
AttributeError: 'bool' object has no attribute 'upper'
  File "odoo/http.py", line 2232, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1807, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1827, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1805, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1812, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1950, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.2/appointment/controllers/appointment.py", line 210, in appointment_type_page
    return self._get_appointment_type_page_view(appointment_type, page_values, state, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/website_appointment/controllers/appointment.py", line 108, in _get_appointment_type_page_view
    return super()._get_appointment_type_page_view(appointment_type, page_values, state, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/appointment/controllers/appointment.py", line 228, in _get_appointment_type_page_view
    slots = appointment_type._get_appointment_slots(
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 798, in _get_appointment_slots
    self._slots_fill_resources_availability(
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 1183, in _slots_fill_resources_availability
    availability_values = self._slot_availability_prepare_resources_values(
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 1369, in _slot_availability_prepare_resources_values
    resources_values.update(self._slot_availability_prepare_resources_leave_values(resources, start_dt_utc, end_dt_utc))
  File "home/odoo/src/enterprise/saas-17.2/appointment/models/appointment_type.py", line 1422, in _slot_availability_prepare_resources_leave_values
    unavailabilities = appointment_resources.sudo().resource_id._get_unavailable_intervals(start_dt_utc, end_dt_utc)
  File "addons/resource/models/resource_resource.py", line 152, in _get_unavailable_intervals
    resources_unavailable_intervals = calendar._unavailable_intervals_batch(start_datetime, end_datetime, resources, tz=timezone(calendar.tz))
  File "odoo/tools/_monkeypatches_pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
```

https://github.com/odoo/odoo/blob/6cb52b4a02a7b3236c20863b177bfaadf474651d/addons/resource/models/resource_resource.py#L147 Here, when the user does not select Opening Hours in resource,
"calendar.tz" will be False.
So, it will lead to the above traceback.

sentry-5475389977

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

Forward-Port-Of: odoo/odoo#169038

Versions
--------
- 15.0+

Steps
-----
1. Have an employee on a 40 hour/week work schedule;
2. for a past week, create a sick leave for monday & tuesday;
3. create 8 hour timesheets for the remaining weekdays;
4. switch the employee's work schedule to 35 hour/weeks;
4. navigate to the week with the leaves in Timesheets.

Issue
-----
The hours displayed next to the employee name shows -11:00, ignoring the the timesheets created by the leaves.

Cause
-----
`resource.calendar.leave` records have a `calendar_id` field which is inialized to the resource's calendar, and updates if the resource changes, but not when the resource's calendar changes.

As a consequence, the `_work_intervals_batch` method used for this calculation gets called on the employee's new calendar, which is no longer related to the calendar associated with their leaves.

Solution
--------
Replace the `onchange_resource` method with a compute method which updates the leave's field if the employee's calendar changes.

opw-3693131

Forward-Port-Of: odoo/odoo#172346
Forward-Port-Of: odoo/odoo#169291

__Current behavior before commit:__
If `crm` is installed `test_import_multiple_invoices` will fail because the crm demo data are changing the email of the partner `base.res_partner_12` (i.e. Azure Interior)(see [crm_lead_demo.xml][1]). `partner` will therefore be `False`.

__Description of the fix:__
Getting `partner` from the `base.res_partner_12` external id so this test does not depend on modifications from other modules.

__Steps to reproduce the issue:__
Run:
```sh
./odoo/odoo-bin -d test-17 -i crm,l10n_es --test-tags .test_import_multiple_invoices --addons-path=./enterprise,./odoo/addons
```
You will get:
```log
odoo.addons.l10n_es_edi_facturae.tests.test_edi_xml: FAIL: TestEdiFacturaeXmls.test_import_multiple_invoices
Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/l10n_es_edi_facturae/tests/test_edi_xml.py", line 283, in test_import_multiple_invoices
    self.assertRecordValues(moves, [
  File "/home/odoo/src/odoo/odoo/tests/common.py", line 659, in assertRecordValues
    self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.

==== Differences at index 0 ====
---

+++

@@ -1 +1 @@

-partner_id:14
+partner_id:False

==== Differences at index 1 ====
---

+++

@@ -1 +1 @@

-partner_id:14
+partner_id:False
```

opw-4009379

[1]: https://github.com/odoo/odoo/blob/1c8e2555366fe6e6b0d74d6db71a29d09bd5f06a/addons/crm/data/crm_lead_demo.xml#L606

Forward-Port-Of: odoo/odoo#175601
Forward-Port-Of: odoo/odoo#173863

Versions
--------
- 17.0+

Steps
-----
1. Go to Website / Shop;
2. click on a product;
3. click on the phone icon to get mobile view;
4. open the editor;
5. click on the product image;
6. set Layout / Image Zoom to Both;
7. save.

Issue
-----
Clicking on the product image doesn't zoom it.

Cause
-----
Commit 75cb82490200 improved zoom features. In the `_startZoom` function it added a comment to an early return, explaining zoom-on-hover should be ignored on mobile:

https://github.com/odoo/odoo/blob/75cb824902000b2c05716c8992ec486cf7102cea/addons/website_sale/static/src/js/website_sale.js#L490-L495

The issue is that this function also handles zoom-on-click, which gets skipped as well with the early return.

This early return didn't fire in the editor before commit 55f182291164, because it checked the value of `config.device.mobile`, which was `undefined`. After this commit, it checks `uiUtils.isSmall()` instead, which does return true in the editor, fully disabling the ability to zoom-on-click:

https://github.com/odoo/odoo/blob/55f1822911641a63309078dbc6dadf0c9fdc0796/addons/website_sale/static/src/js/website_sale.js#L341-L343

Solution
--------
Move the check on `uiUtils.isSmall()` from the early return to the `salePage.dataset.ecomZoomAuto` check, so that only zoom-on-hover gets skipped on mobile.

opw-3880081

Forward-Port-Of: odoo/odoo#170747

## Description
It's really slow to archive a published course with many participants

## Analysis
In `_recompute_completion`, we are recomputing the set of resume lines to check against to see if we should add a new resume line upon completion of a course for *each* employee associated with the course. Also the creation of resume lines is not batched.
There is also *no* indexes of any sort on the `hr.resume.line` model.

## Solution
- Refactor to remove the `search` inside the `for`
- Batch the create
- Add missing indexes

## Benchmark
Archiving a published course with ~30k participants, with a over 100k resume lines in the database.

| No indexes | Before | After | Speed up |
|------------|--------|-------|----------|
| Timings    | 1m39s  | 17s   | 5.8x     |

| With indexes | Before | After | Speed up |
|--------------|--------|-------|----------|
| Timings      | 1m39s  | 4.14s | 23.9x    |

## Reference
task-4043098

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

Forward-Port-Of: odoo/odoo#173857

Issue:
The `_get_weight` method is called for each location to compute the weight and it sums up all the incoming and outgoing lines for forecasted weight. Using filtered for each record is compute intensive and gets slower over time.

While returning a delivery with 30 stock moves the _create_return took 7:41 minutes most of which were on `_get_weight`. Here filtered alone was taking over 6 minutes.
![image](https://github.com/odoo/odoo/assets/111344786/52f2bdef-f486-4e07-aab3-0ced1d68bd1c)

For a single run, 
|| Before| 
| --------- | ------------- | 
|Quants| 5474  | 
|Outgoing Move Lines| 38020  | 
|Incoming Move Lines| 150935 |
|Time| 246.05s |

Solution:
Optimized the `_get_weight` method to use `read_group` to get the sum of incoming and outgoing lines. This reduces the number of reads. Total time for the same return reduced to 28s.

![image](https://github.com/odoo/odoo/assets/111344786/9cc83c93-3502-44a2-af54-9a269a98394a)
For a single run:
|| After| 
| --------- | ------------- | 
|Quants| 5474  | 
|Outgoing Move Lines| 38020  | 
|Incoming Move Lines| 150935 |
|Time| 0.4s |
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#174660
Forward-Port-Of: odoo/odoo#170675

### Version:
15, 16, 17, master

### Description of the issue/feature this PR addresses:

Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the document type if the invoice was posted before. If it does then an incosistency will occurr because the name, document type and sequence will not match. A new sequence non-real will be used. Also the user it is not aware is happening because the field is readonly.

[Video](https://drive.google.com/file/d/1D4uqNnXMkguS813NiLl9td4_f_TJ35Xf/view) showing how to replicate the bug:

### Steps to reproduce:

1. Log in with admin on runbot odoo enterprise 16 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module.
2. Take position on company "Responsable Inscripto"
3. Go to "Accounting / Customers / Invoices" and create a new customer invoice with customer "ADHOC SA" (this partner has "IVA Responsable Inscripto" AFIP Responsibility), with a sale journal "Pre-printed Invoice" AFIP POS System (i.e Ventas Preimpreso), add an invoice line and confirm it. ![image](https://github.com/user-attachments/assets/5e770259-6195-45af-b2d2-6e7a701f9fb5)

4. Reset to draft the invoice mentioned in step 3 (now journal and document type are readonly fields), change customer to "Consumidor Final Anónimo" (this partner has "Consumidor Final" AFIP Responsibility) and save. Check that the document type has changed from "(1) FACTURAS A" to "(6) FACTURAS B" and this is not the desired behavior because is a readonly field now because the invoice was posted before. 
![image](https://github.com/user-attachments/assets/d9d4cced-59df-4f0b-8222-1a581702bd0b)

### Current behavior before PR:

When a customer invoice with customer with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the customer to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted.

### Desired behavior after PR is merged:

When a customer invoice with customer with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the customer to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is not changed.

Ticket Adhoc side: 77058
Task latam: 1235


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

Forward-Port-Of: odoo/odoo#172003

### [FIX] hr_holidays: search for leaves in user's tz

For the sake of simplicity we'd assume 3 days: Mon, Tue, Wed.
Let's also assume that the everything happens in GMT+10

Now if we have a valid leave allocation for Mon and Tue, we should
NOT be able to able to take it on Wed. However, because of the way
Timestamps are casted to dates it is possible. It happens as follow:
user "asking" server for leave on Wed, defines requested day by passing by
the datetimes in the context ranging from Tue 21:00 to Wed 09:00

Why such datetime range? Firstly because we have hardcoded devault values
for events that range from 07:00 to 19:00 in local time (ref.1).
Secondly because we're in GMT+10 so this range gets shifted:
 07:00 on Wed becomes 21:00 on Tue
 19:00 on Wed becomes 09:00 also on Wed

Then because allocations ranges are defined by dates not datetimes,
implicit casting is performed that causes cut-off of the time from the datetime
and in the end instead of checking if leave is allowed on Wed we check if
it is allowed on Tue and Wed.

### [FIX]
Shifting back into the user's timezone before casting.

### [Reproduction of the original issue]
- install hr_holidays
- create employee E
- create & validate new Allocation A  (in TimeOff/Allocations):
        - of type T (creating new type will help identify the issue)
        - for employee E
        - valid from Mon to Tue
- Open E's time off (Employee E -> Time Off)
- Switch your browser TZ that is +10
- Attempt to book time off for E on Wed
- BUG: you are allowed to do so

opw-3850159

(ref.1)
calendarEventToRecord from calendar_model
https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/js/views/calendar/calendar_model.js#L74-L75


![3850159 Can apply for a leave with expired allocissueation; Timezone  _0 excalidraw](https://github.com/user-attachments/assets/ed06411b-7403-4676-bd8b-82ebb203090e)

Forward-Port-Of: odoo/odoo#175567
Forward-Port-Of: odoo/odoo#172748

## Description
On large MOs with many lines, the `onchange` triggered when setting the `lot_producing_id` can be really slow.

## Analysis
In `_set_quantity_done`, the `__set__` on `move_line_ids` triggers the computation of fields that depends on it.
This necessitates the creation of a trigger tree, to know what fields on what model with what records needs to be recomputed. In this context, because some of the frequent dependencies, `raw_material_production_id` and `production_id` on `stock.move` don't have a respective inverse *without* a domain on it, in `_modified_triggers`, we fall back on a generic lookup of cache entries + filtering, which can be costly, as it's `O(n)` in complexity, and `n` can be large, in this case it's over 18k records of `stock.move`, that's done 4 times (the tree has 2 instances for each of the above-mentionned `Many2one`)
The process of resolution of the dependencies tree is repeated for each line of the MO, accentuating the bottleneck.

## Solution
Adding two `One2many` fields to be the generic inverse of `raw_material_production_id` and `production_id` on `mrp.production`, so the ORM can use those to fall into the fast-path when resolving these dependencies.
There are already two `One2many` on this model that are inverse of these `Many2one` (`move_raw_ids` and `move_finished_ids`), but they each have a domain, therefor the ORM cannot use them as an inverse during creation of the trigger tree.

## Benchmarks

|         | Before | After |
|---------|--------|-------|
| Timings | 91.8s  | 14.1s |

## Reference
opw-4003495

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

Forward-Port-Of: odoo/odoo#170881