… flexible

This commit aims to resolve critical error in time off when the user is
fully flexible.

- get_allocation_data is updated to handle the case when the employee is fully flexible.
- Set duration_hours and duration_days in the dummy attendance to handle
  flexible time off requests and to avoid unintended zero division error in _get_attendance_intervals_days_data.
  P.S: Currently Fully Flexible resources do not support fully time offs,
  so this allows a fallback that prevents error while still setting a valid
  duration of a time off request.

Steps to reproduce:
1. Install hr_holidays
2. Go to Mitchel Admin's employee profile > work information
3. Delete the working calendar > so that the employee is fully flexible
4. Try to open time off module
   -> Prior to this commit, it would raise a zero division error

ticket-id: 4677726


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

Forward-Port-Of: odoo/odoo#203737

In this commit, we fix multiple indeterministic tours:

- website/static/tests/tours/media_dialog.js Add a step to ensure all images are loaded before exiting the tour to avoid message: "CORS is misconfigured on the API server, image will be treated as non-dynamic."
- project/static/tests/tours/project_task_history.js Use stepUtils.saveForm to ensure form is well saved before continue.
- website/static/tests/tours/snippets_all_drag_and_drop.js Remove a step that can cause undeterministic failure during tours.
- pos_restaurant/static/tests/tours/pos_restaurant_tour.js Add a delay when transfering the order.
- website/static/tests/tours/page_manager.js Add a last step to ensure reloading is done before exiting the tour to avoid "Error received after termination: TypeError: Failed to fetch" error.
- website/static/tests/tours/html_editor.js Add steps to wait the iframe reload.

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

Currently, a traceback occurs when the user tries to send multiple invoices 
to sign in the list view, which includes draft invoices.

Error:- 
```
TypeError: the JSON object must be str, bytes or bytearray, not bool
```

Cause:-

When the user resets an Egyptian invoice to draft status, the value 
of `l10n_eg_eta_json_doc_id` is set to False as seen in the following line

https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L66-L67

After that when the user attempts to sign the document through the list view, it leads to the  traceback.

This happens because we are passing self instead of the invoices to the method `action_sign_invoices`.
https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L73
https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L106
As a result, self contains all draft invoices (if selected by the user), leading to the traceback since the value of l10n_eg_eta_json_doc_id is False for the reset draft invoice.

https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/eta_thumb_drive.py#L34-L35

sentry-6448238266

Forward-Port-Of: odoo/odoo#203064

Currently there are two bugs:
1) Selling a kit product to another internal company
(inter_company) and validating the delivery will not update the
`qty_delivered` field on the corresponding `SaleOrderLine`
* Currently the filters to capture moves which informs the
delivered quantity of the line do not account for moves with
`location_dest_id` pointing to the inter-company transit
location (which should count towards the delivered value)

2) Receiving a kit product via inter_company which has a
`comp:final` ratio >1 will result in an inaccurate update on the
`qty_received` field on the corresponding `PurchaseOrderLine`
* The BoM of the sold kit-product belongs to the selling
company, and in the purchase_mrp override of
`_compute_qty_received` they fail to get marked as kit lines
because the `bom_line_id` is hidden due to a company-precise
domain constraint

**Steps to reproduce:**
*Having `sale_purchase_stock_inter_company_rules` and enabled
synchronization of sale & purchase orders for both companies*
1. Create a kit product

2. Deliver it to another internal company

3. After validating the delivery, check the the sale order line
and observe that the delivered qty is 0

**Cause of the issue:**
When computing `qty_delivered`, we have the following filters to
capture in/out move qty:
https://github.com/odoo/odoo/blob/ef1be75601e7ce346d8e6b9367505cbf39b05101/addons/sale_mrp/models/sale_order_line.py#L69-L70
which don't account for moves to inter-company transit.

When computing `qty_received`, we aggregate purchase lines:
https://github.com/odoo/odoo/blob/b13e46f06c1d3166fd64fc72cacd8af1f3673ae6/addons/purchase_mrp/models/purchase.py#L56
however using the line's `company_id` means the BoM belonging to
the delivering company isn't revealed. Then the `qty_received`
is computed as though the line was an ordinary product, leading
to the mismatch between product and qty.

**Fix:**
Modify the existing incoming/outgoing move filters in the qty
received and delivered compute methods to account for
inter-company moves.

opw-4267210

Forward-Port-Of: odoo/odoo#203568
Forward-Port-Of: odoo/odoo#195726

### Steps to reproduce:

- In the settings: enable Multi-steps route.
- Have two companies active (each with an existing warehouse): COMP 1, 2
- Put the warehouse of COMP 2 in delivery in 2 steps.
- With COMP 1 as main active company, create and confirm an SO for COMP2
> A pick picking has been created for COMP2
- Validate The pick picking
#### > The ship picking was not created

### Cause of the issue:

During the `_action_done`of the pick move, we will run a `_push_apply` on the move and try to trigger any push rule related to its destination. However, since de destination location of tha move (COMP2 output) does not belong to the main active company, the warehouse for which we search the rule is set to False and the rule ends up not being found: https://github.com/odoo/odoo/blob/cc05d9d50ac668eaa26363e1127f914897a4b125/addons/stock/models/stock_move.py#L1058-L1066

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

Forward-Port-Of: odoo/odoo#204170

Before this commit, when running a HOOT test suite with a dependency on `@mail`, the memory snapshot at end of suite test was higher than expected.

Steps to reproduce:

- run HOOT suite `global_filter_editor.test.js` with 51 tests
- make a snapshot of memory after test => observe that there's thousands of RecordList objects kept in memory (8976) instead of a few hundreds (176)

These tests do not make use of any mail code, but the manifest has dependency on `@mail` thus it loads mail store. This test suite is a good candidate to show constant memory issue from discuss code: 51 tests each having 176 record lists result in 8976 record lists in total.

The JS records are expected to be garbage collected after each test, thanks to store not being accessible from components and services (app is unmounted at end of test).

However, `Rtc.iceServers` field was preventing this and leads to keeping store in memory. This is happening because the default value of this field is `DEFAULT_ICE_SERVERS`, which is defined on window object globally and is shared among all the different stores in the test suite. The field is computed too, so an internal `onChange` also contributed in keeping a reference to observing this shared object.

This commit fixes the issue by providing a deep copy of this global variable as the default value of `iceServers`, allowing proper gc of store between tests of the suite.

Forward-Port-Of: odoo/odoo#204521

This pull request (PR) facilitates the integration of Odoo with the Uruguayan electronic billing system, allowing automatic synchronization of vendor bills every 10 minutes. Synchronized bills are created in "Draft" status for user review, complete with attached PDF and XML files.
Also this pull request allows to create vendor bills from XML files on uruguayan journals.

**Key Features**:

- **_Automatic Bill Creation_**: Bills are generated in "Draft" status to enable manual verification against vendor invoices and attachments.

- **_Necessary Configuration_**:
1) The database must connect to Uruware.
2) A Uruguayan company must be set up with an appropriate chart of accounts.
3) Notifications must be activated in the Uruguayan billing system.

**Important Considerations**:
- Errors during synchronization will still create invoices in "Draft" with error messages for user review.
- Invoice lines are created without products; if a vendor doesn’t exist, it will be automatically created based on RUT.
- Any unregistered taxes will be flagged.

**Technical Overview**:
- **_Notification Mechanism_**: Notifications for each received CFE are managed through a web service, allowing users to check, request details, and discard notifications.
- **_Synchronization Process_**: Notifications are read and processed sequentially, with each CFE generating a corresponding document in Odoo. Notifications must be discarded to continue processing.

Related Tasks:
Adhoc Task: 43467
LATAM Task: 1249

Forward-Port-Of: odoo/enterprise#71234

Steps to reproduce the bug:

- Create a storable product “P1”:
  - Create a BoM
  - Go back to the product form and create an ECO:
    - Apply on: “Bill of Materials”
    - The created BoM will be selected automatically.
    - Save.

- Return to the product form.
- The ECO count in the smart button is 1.
- Click on it.

Problem:
No ECO is displayed because the domain filters only ECOs applied to the product:
https://github.com/odoo/enterprise/blob/ec6b4717f49ccd5b651be80aed21494ed500f580/mrp_plm/models/product.py#L17-L20

Solution:
only ECOs of type "Product" should be counted in the product form.

Issue 2:

- Try updating the "Apply on" field of the ECO to “Product.”

Problem:
The "Bill of Materials" field becomes invisible but is not cleared. As a result, when counting the number of ECOs linked to the BoM, the count will be incorrect.

https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48

opw-4653598

Forward-Port-Of: odoo/enterprise#82576

[FIX] hr_appraisal: prevent TypeError for raw record data

The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None.
This occurred because the code attempted to create a set from the None value directly.

Steps to reproduce:
-------------------
* Open Appraisal app and click on an employee's card
* Activate debug mode
* From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+

> Observation: 
  File "/data/build/enterprise/hr_appraisal/models/hr_appraisal.py", line 539, in read
    check_notes = set(fields) & {'note', 'assessment_note'}
                  ^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

Why the fix:
------------
set() requires an iterable. By adding this condition, we avoid iterating over NoneType. This maintains the intended default functionality while preventing the crash.

opw-4631142

Forward-Port-Of: odoo/enterprise#82711
Forward-Port-Of: odoo/enterprise#81758

Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user.

**Steps to reproduce:**
- Install the `account` and `l10n_hr_payroll` modules.
- Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record.
- In **Scheduled Actions**, manually execute `Payroll: Update data`.
- Observer the backend error.

**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/enterprise/saas-18.2/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data...`

The error occurs because the method at [1] attempts to load the `hr_salary_rule_ind_emp_data.xml` file that references a deleted `partner_id` [2], leading to a parsing error.

[1] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/models/hr_payslip.py#L44-L54
[2] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data.xml#L364

This commit ensures that `res_partner_data.xml` is loaded before `hr_salary_rule_ind_emp_data.xml`, preventing errors due to missing partners.

Sentry - 6429993371

Forward-Port-Of: odoo/enterprise#81917