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

Steps to reproduce
==================

As Admin:
- Install project
- Go to project
- Click on the three dots on a project card
- Select "Share"
- Copy the link
- Select the edit mode
- Add "Joel Willis" to the recipients
- Click on "Send"

As portal in another browser (or in private navigation)
- Paste the link
- Type some random characters in the search bar so that no records are matched
- remove the current filter => Every single column is displayed, for example
  `<field name="sequence" readonly="1" column_invisible="True"/>`

As Admin:
- Go to the shared project settings
- Disable the "Milestones" checkbox

As portal:
- Refresh the page => The milestone column is still displayed

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

The difference between invisible and column_invisible is that

`invisible` is meant to hide a cell in a row and is evaluated with the record data (`record.evalContextWithVirtualIds`).

`column_invisible` is meant to remove a column completely for the list, but is is not evaluated with the record. It only uses the context and a few more keys (`this.model.root.evalContext`).

It is thus not possible to hide an entire column depending on record values. It makes sense as the values could be different for every record displayed.

In this case though, there are a few fields that have the same values for every record. They are in fact related fields, declared on the project.

Those fields are
- allow_milestones
- allow_timesheets

The [ProjectSharingListRenderer] has been created to hide some columns from being displayed when a feature is disabled on the project displayed.

It works by evaluating the column_invisible with the first record. If there are no records, we skip any column_invisible processing,

When calling `setColumns` from `onWillUpdateProps`, we use `nextProps` for the columns, but still `this.props` to get the first record.

This means that we use an outdated first record, and this is why every column is displayed after removing the filter.

Another issue is that

During [View-Pocalypse],
In 16.0, the milestone_id field was

```xml
<field name="milestone_id" attrs="{'column_invisible': [('allow_milestones', '=', False)]}"/>
```

In 17.0, it is

```xml
<field name="milestone_id" invisible="not allow_milestones" context="{'default_project_id': project_id}" groups="project.group_project_milestone" optional="hide"/>
```

Solution
========

As there are some limitations to the js approach (when no records are in the list for example) and there is already a context key for the [allow_timesheets], we use a simpler approach to add the missing keys.

Finally, we put back the column_invisible attributes

---

[ProjectSharingListRenderer]: https://github.com/odoo/odoo/commit/ab2b5d1fd1f09d804ab410bc326cfebf26d5a7c6
[View-Pocalypse]: https://github.com/odoo/odoo/pull/104741
[allow_timesheets]: https://github.com/odoo/odoo/blob/d2a428c07fd728691e3ddd60fe4b7cc5e94455a6/addons/hr_timesheet/models/project_project.py#L290

opw-4015035

Forward-Port-Of: odoo/odoo#172645

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

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

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

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

Issue 1:
---

### Steps to reproduce:

- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
  COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
    - 1 x COMP 1 consumed in op 1
    - 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.
**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**

As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P

### Cause of the issue:

When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").

Issue 2
---
### Steps to reproduce:

- Enable Multi-Step routes in the settings
- Go Inventory >  Configuration > Warehouse Management > Warehouses
- Enable 2-step manufacturing on your Warehouse
- Create 2 storable products:
    - product P: tracked by SN
    - product COMP: tracked by lot
- Update the "on hand qty" of COMP by creating a lot with 10 units
- Create and confirm a manufacturing order for 1 unit of P
- Assign a serial number to the final product
- Validate the transfer of components from stock to preproduction (The lot is automatically used on this transfer as it is available)

### Expected behavior:

Since the lot of COMP was used in the transfer from stock to preproduction it should be displayed on the raw move of the MO.

### Current behavior:

The raw move is not updated.

Note: if the transfer is validated before we assign a serial number to the final product, the lot of the component is correctly updated.

### Cause of the issue:

When the 'action_generate_serial' is triggered in order to assign a SN to the final product P, the '_set_qty_producing' is called in order adapt the quantities of the MO (produce only one unit and consume accordingly):
https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1397-L1398
https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1215-L1231
Now, changing the quantity of the stock move of the component to a positive quantity will trigger the inverse method '_set_quantity' of that field to adapt reservation by creating a stock.move.line. Therefore, validating the transfer of components from stock to pre-production will not update the lot of components on the raw move because the computed need will be at 0 here:
https://github.com/odoo/odoo/blob/3097ea49705a1b6319be9677152d65ebe3ce515b/addons/stock/models/stock_move.py#L1689-L1697
and the '_update_reserved_quantity' call will therefore be empty.

Issue 1: opw-3887580 and opw-3863572

Issue 2: opw-3925894

Enterprise: https://github.com/odoo/enterprise/pull/63912
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#168205

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

**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#67693
Forward-Port-Of: odoo/enterprise#67644

### Steps to reproduce:

- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
  COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
    - 1 x COMP 1 consumed in op 1
    - 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.

**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**

As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P

### Cause of the issue:

When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").

Community: https://github.com/odoo/odoo/pull/168205

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

Forward-Port-Of: odoo/enterprise#63912