## 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

## 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

### 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

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

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

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

__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

**Steps to reproduce:**
- Install Accounting
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Create an account (e.g. Test Account)
- Go to "Accounting / Accounting / Miscellaneous / Journal Entries"
- Create a journal entry:
  * Journal Items:
------------
        Account    |    Debit    |    Credit
    --------------------------------------------
     Test Account  |    $0.00    |    $410.34
         [any]     |   $410.34   |     $0.00

- Post the journal entry
- Go to "Accounting / Accounting / Management / Automatic Transfers"
- Create an automatic transfer:
  * Origin Accounts: Test Account
  * Automated Transfer:
-----------
        Percent (%)    |    Destination Account
    -----------------------------------------------
           15.00       |           [any]
           42.50       | [any, but a different one]
           42.50       | [any, but a different one]

- Activate the automatic transfer
- Compute transfer

**Issue:**
A UserError is raised while trying to create a journal entry because of a $0.01 difference between the total credit and the total debit.

**Cause:**
When the amounts of each line are computed from the percentage, they are not rounded.
These amounts are used to create the journal entries generated by the automatic transfer.
However, each created journal entry line is rounded, which can generate a rounding difference.

**Solution:**
Directly round the amounts when they are computed from the percentage to be sure that the amounts used for the computation and the ones that will be set in the journal entries are the same.

opw-3998808

Forward-Port-Of: odoo/enterprise#67956
Forward-Port-Of: odoo/enterprise#67644

### Main Issue:
When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house number from the 'street' field of the partner.

### Main change:
Updated the regex pattern used to extract house numbers from postal address lines to increase accuracy and cover more address formats.

### Before:
- Regex Pattern: `([1-9]+\w*)`
- Explanation: This pattern captures one or more digits (not starting with zero) followed by any number of word characters (letters, digits, or underscores).

### After:
- Regex Pattern: `(\d+[-\/]?\d* ?[a-zA-Z]?\d*)(?![a-zA-Z])`
- Explanation: This improved pattern captures a broader range of house number formats, including those with dashes, slashes, spaces, and letters.

### Examples of the Differences:

    "Friedrichstr. 13/1"
        Before: '13'
        After: '13/1'

    "Rue du pont 11 A"
        Before: '11'
        After: '11 A'

    "Place Albert 1er 15B"
        Before: '1er'
        After: '15B'

    "123-456 Main Street"
        Before: '123'
        After: '123-456'

    "789 C Oak Avenue"
        Before: '789'
        After: '789 C'

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

Forward-Port-Of: odoo/enterprise#67344
Forward-Port-Of: odoo/enterprise#67286

This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new ticket without any team attached, rendering it useless.

step to reproduce:
- install helpdesk application
- open helpdesk
- open confifuration menu, select helpdesk team
- select 'customer care'
- activate the livechat option and saves
- leave helpdesk
- change from the current active company to any other company that doesn't have any helpdesk team with the livechat feature enabled
- open the discuss app and select the 'general' discussion
- type /helpdesk your_ticket a new ticket will be created without any team linked to it.

source of the issue:
when a team has the livechat option enable, the command is added to the livechat regardless of the connected user's access right to the team.

solution:
Only add the command to the list of livechat command if the user has access to at least one team with the livechat feature enable.

affected version : 15.0 - master
task - 3631682
https://www.odoo.com/web#id=3631682&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form

Forward-Port-Of: odoo/enterprise#66009
Forward-Port-Of: odoo/enterprise#53510

Steps
-----
[Planning]
- Create a shift from 1 July 2024 -> 31 July 2024 and chose the option to repeat it every month. Save it.

1st issue: no shift is created in September.
2nd issue: November shift ends in December and overlaps with December shift.

Cause
-----
- The 1st issue is caused by the first day of the September shift being on a weekend. In case the first day is not a working day, a shift will only be generated if the first day of the original shift was outside working days.
https://github.com/odoo/enterprise/blob/079b0ba241b8b4f7fbd74775e5fc43b27ca3c8fd/planning/models/planning_recurrency.py#L104-L107
- The 2nd issue happens because the length of all the repeated shifts is the same than the original shift. In the case of a longer original month, this will create overlapping generated shifts when we get to shorter months.

Introduced by 079b0ba241b8b4f7fbd74775e5fc43b27ca3c8f

Fix
-----
- Consider a shift with any day (and not just the starting one) outside of working days as being outside working days.
- Adapt the length of the generated shifts in case of a monthly recurrence. Take the minimum between the original shift duration in days and the number of days in the month.

opw-3996123

Forward-Port-Of: odoo/enterprise#66408