When posting an invoice, the system creates:
- Journal Entry: Dr 131 (Receivable) / Cr 511

Then the system creates a deferral entry:
- Deferral entry: Dr 511 / Cr 3387 (Payable)

Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators

The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a  current liability, not a payable account.

By changing the account type from `Payable` to `Current Liabilities`,
the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner.

After this fix:
- Entry: Dr 131 (Receivable) / Cr 511
- Deferral: Dr 511 / Cr 3387 (Current Liabilities)

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#238807
Forward-Port-Of: odoo/odoo#237493

Similar to: 0104cee

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 16 hours)
4. Open the project dashboard > create a new project update >
observe the timesheet time
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard > create another project update >
observe the timesheet time again

Issue:
------
Incorrect value displayed in the Timesheets. (e.g., 16 Days instead of 2 Days)

Cause:
-------
After commit 28b69da, the UoM model was restructured, changing how conversions 
between hours and days are computed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). 
Whenever a new project update is created, the division in `create()` performs an
unnecessary second conversion on an already converted value, causing the incorrect display.
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/hr_timesheet/models/project_update.py#L36-L37

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days.

opw-5184077

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

Forward-Port-Of: odoo/odoo#237532

Currently, an error occurs when user tries to create a new amazon account on a new company.

Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.

Error:
```
  File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
    'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```

Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].

Solution:
- Assigning the `location_id` if the `parent_location_data` exists.

[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210

[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204

[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214

sentry-7086464738

Forward-Port-Of: odoo/enterprise#101465

When posting an invoice, the system creates:
- Journal Entry: Dr 131 (Receivable) / Cr 511

Then the system creates a deferral entry:
- Deferral entry: Dr 511 / Cr 3387 (Payable)

Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators

The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a  current liability, not a payable account.

By changing the account type from `Payable` to `Current Liabilities`,
the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner.

After this fix:
- Entry: Dr 131 (Receivable) / Cr 511
- Deferral: Dr 511 / Cr 3387 (Current Liabilities)

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#238807
Forward-Port-Of: odoo/odoo#237493

Currently, an error occurs when user marks multiple Manufacturing Orders as Done.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1XfkMB001rMiyulRGrP4dlJFDYByo_5Bv/view?usp=drive_link)):**
 - Install the `mrp` module.
 - Go to `Settings` and enable `Units of Measure & Packagings`.
 - Go to `Products and `create two products` with different `units of measure`.
 - Go to `Manufacturing Orders`, create a manufacturing order by `adding one of the products`, and then `create work order` in the Work Orders section and `confirm` it.
 - Create another `manufacturing order` with the `same quantity` for the second product and add a `Work Order` for it as well and `confirm` it.
 - Go to the `list view`, select `both orders`, and click `Mark as Done` from the `Actions` menu.

**Error:**
```
ValueError: ValueError('Expected singleton: uom.uom(4, 6)') while evaluating
"if records:\n                res = records.filtered(lambda mo: mo.state in {'confirmed', 'to_close', 'progress'}).button_mark_done()\n                if res is not True:\n                    action = res"
ValueError: Expected singleton: uom.uom(4, 6)
```

After [this commit], which improves the performance of button_finish, when a user marks multiple orders as done with the same quantity but different uom , it creates all_vals_dict based on the vals[1] data as the key and the work order as the value[2]. Then it  stores two or more work orders with different UoMs under the same vals key. When attempting to write multiple work orders[3], the precision rounding is calculated, which raises the error[4] due to multiple UoMs.

The commit ensures that when writing records, precision_rounding is calculated separately for each Work Order's UoM.

[this commit]: https://github.com/odoo/odoo/pull/223715/commits/b857d192085a38b612335223d04f8bdff91b898c

[1]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L698-L703

[2]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L706

[3]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L708

[4]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L477

sentry-7050854871

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

Forward-Port-Of: odoo/odoo#238086

Similar to: 0104cee

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 16 hours)
4. Open the project dashboard > create a new project update >
observe the timesheet time
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard > create another project update >
observe the timesheet time again

Issue:
------
Incorrect value displayed in the Timesheets. (e.g., 16 Days instead of 2 Days)

Cause:
-------
After commit 28b69da, the UoM model was restructured, changing how conversions 
between hours and days are computed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). 
Whenever a new project update is created, the division in `create()` performs an
unnecessary second conversion on an already converted value, causing the incorrect display.
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/hr_timesheet/models/project_update.py#L36-L37

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days.

opw-5184077

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

Forward-Port-Of: odoo/odoo#237532

Currently, an error occurs when user tries to create a new amazon account on a new company.

Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.

Error:
```
  File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
    'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```

Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].

Solution:
- Assigning the `location_id` if the `parent_location_data` exists.

[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210

[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204

[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214

sentry-7086464738

Forward-Port-Of: odoo/enterprise#101465

__
## Short functional explanation of the error
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B.
In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

## Reproduction Steps
1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check
Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

### Expected behavior
The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

### Unexpected behavior
Nothing happens

## Origin of the issue
When computing the working time to assign, we also take into consideration leaves:
if this happened during public holidays, we consider that it took no working time to get assigned.
However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following:
https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#546

The company isn't taken into account in the domain, applying the holiday for every company.
_________________________________________
opw-5222883

Forward-Port-Of: odoo/odoo#236043

Currently, an error occurs when user tries to create a new amazon account on a new company.

Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.

Error:
```
  File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
    'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```

Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].

Solution:
- Assigning the `location_id` if the `parent_location_data` exists.

[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210

[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204

[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214

sentry-7086464738

Forward-Port-Of: odoo/enterprise#101465

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101499
Forward-Port-Of: odoo/enterprise#100940

Currently, an error occurs when user tries to create a new amazon account on a new company.

Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.

Error:
```
  File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
    'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```

Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].

Solution:
- Assigning the `location_id` if the `parent_location_data` exists.

[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210

[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204

[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214

sentry-7086464738

Forward-Port-Of: odoo/enterprise#101465

When posting an invoice, the system creates:
- Journal Entry: Dr 131 (Receivable) / Cr 511

Then the system creates a deferral entry:
- Deferral entry: Dr 511 / Cr 3387 (Payable)

Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators

The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a  current liability, not a payable account.

By changing the account type from `Payable` to `Current Liabilities`,
the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner.

After this fix:
- Entry: Dr 131 (Receivable) / Cr 511
- Deferral: Dr 511 / Cr 3387 (Current Liabilities)

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#238807
Forward-Port-Of: odoo/odoo#237493

**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template

**Observation:**
- Traceback for faulty template


**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587

when this content is parsed using DOMParser in browser, 

https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63

we might get different result.
For a very basic template like this:
```
<div>
    <t t-if="ctx.get('error')">
        <pre t-out="ctx['error'] or ''" />.
    </t>
    <t t-else="">
        <span>some text</span>
    </t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
    <t t-if="ctx.get('error')">
        <pre t-out="ctx['error'] or ''">.
        <t t-else="">
            <span>some text</span>
    </t>
</pre>
    </t>
</div>
```

Issue roots because of use of self-closing tags, which are valid for xml but not for html

**Fix:**
- we forcefully replace all self-closing tags(which are not void elements)  with a closing tag.
- see  list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element



opw-5234345


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

Forward-Port-Of: odoo/odoo#238695
Forward-Port-Of: odoo/odoo#235924

Currently, an error occurs when user marks multiple Manufacturing Orders as Done.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1XfkMB001rMiyulRGrP4dlJFDYByo_5Bv/view?usp=drive_link)):**
 - Install the `mrp` module.
 - Go to `Settings` and enable `Units of Measure & Packagings`.
 - Go to `Products and `create two products` with different `units of measure`.
 - Go to `Manufacturing Orders`, create a manufacturing order by `adding one of the products`, and then `create work order` in the Work Orders section and `confirm` it.
 - Create another `manufacturing order` with the `same quantity` for the second product and add a `Work Order` for it as well and `confirm` it.
 - Go to the `list view`, select `both orders`, and click `Mark as Done` from the `Actions` menu.

**Error:**
```
ValueError: ValueError('Expected singleton: uom.uom(4, 6)') while evaluating
"if records:\n                res = records.filtered(lambda mo: mo.state in {'confirmed', 'to_close', 'progress'}).button_mark_done()\n                if res is not True:\n                    action = res"
ValueError: Expected singleton: uom.uom(4, 6)
```

After [this commit], which improves the performance of button_finish, when a user marks multiple orders as done with the same quantity but different uom , it creates all_vals_dict based on the vals[1] data as the key and the work order as the value[2]. Then it  stores two or more work orders with different UoMs under the same vals key. When attempting to write multiple work orders[3], the precision rounding is calculated, which raises the error[4] due to multiple UoMs.

The commit ensures that when writing records, precision_rounding is calculated separately for each Work Order's UoM.

[this commit]: https://github.com/odoo/odoo/pull/223715/commits/b857d192085a38b612335223d04f8bdff91b898c

[1]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L698-L703

[2]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L706

[3]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L708

[4]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L477

sentry-7050854871

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

Forward-Port-Of: odoo/odoo#238934
Forward-Port-Of: odoo/odoo#238086

Similar to: 0104cee

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 16 hours)
4. Open the project dashboard > create a new project update >
observe the timesheet time
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard > create another project update >
observe the timesheet time again

Issue:
------
Incorrect value displayed in the Timesheets. (e.g., 16 Days instead of 2 Days)

Cause:
-------
After commit 28b69da, the UoM model was restructured, changing how conversions 
between hours and days are computed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). 
Whenever a new project update is created, the division in `create()` performs an
unnecessary second conversion on an already converted value, causing the incorrect display.
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/hr_timesheet/models/project_update.py#L36-L37

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days.

opw-5184077

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

Forward-Port-Of: odoo/odoo#237532

### Issue:

To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.

The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.

### Cause of issue

Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.

### Fix:

In the fix, picked is set to False when there no
`move_line_ids`

### Issue 2

This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,

### Cause of issue 2

To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
        move.picked = False
+ else:
        move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.

After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.

### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507

opw-4964561


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

Forward-Port-Of: odoo/odoo#222034

Currently, an error occurs when user tries to create a new amazon account on a new company.

Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.

Error:
```
  File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
    'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```

Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].

Solution:
- Assigning the `location_id` if the `parent_location_data` exists.

[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210

[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204

[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214

sentry-7086464738

Forward-Port-Of: odoo/enterprise#101465

**Description:**

- The ir.actions.act_window [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91) menus from the sale_account_accountant module were causing memory errors on databases with millions of sale.order.line records. These actions call [_search_invoice_to_be_issued and _search_deferred_revenue](https://github.com/odoo/enterprise/blob/master/sale_account_accountant/models/sale_order_line.py#L17-L29), which iterate over all lines and access the non-stored computed fields [qty_delivered_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L905) and [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L985) As a result, qty_delivered and qty_invoiced were repeatedly recomputed, leading to excessive memory usage.

- To fix this, we now pre-fetch these fields so the compute method can directly use the values already loaded in memory.

```
matu_3306966_19.0=> select count(*) from sale_order_line;
  count
---------
 2159957
(1 row)
```

**Traceback1:**
```
2025-12-03 07:02:25,973 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_to_bill_action', 1295, 'Accounting > Review > Sales > Invoices To Be Issued', 2690) to the failing menus
Traceback (most recent call last):
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
    return self.mock_view_tree(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
    self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
    data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
    groups, length = self._formatted_read_group_with_length(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
    groups = self.formatted_read_group(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
    groups = self._read_group(
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
    return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
    return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
    query = self._search(domain)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
    domain = domain.optimize_full(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
    return self._optimize(model, OptimizationLevel.FULL)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
    domain = self._optimize_field_search_method(model)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
    children = cls._flatten(items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
    return determine(self.search, records, operator, value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in _search_invoice_to_be_issued
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in <listcomp>
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
    return _compute_field_value.origin(self, field)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
    line.qty_invoiced_at_date = line.qty_invoiced
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
    self.fetch(fnames)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
    field._insert_cache(fetched, values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
    collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```

**Traceback2:**
```
2025-12-03 07:02:30,098 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_deferred_revenues_action', 1296, 'Accounting > Review > Sales > Invoiced Not Delivered', 2691) to the failing menus
Traceback (most recent call last):
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
    return self.mock_view_tree(model, view, fields_list, domain, group_by)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
    self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
  File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
    data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
    groups, length = self._formatted_read_group_with_length(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
    groups = self.formatted_read_group(
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
    groups = self._read_group(
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
    return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
    return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
    query = self._search(domain)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
    domain = domain.optimize_full(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
    return self._optimize(model, OptimizationLevel.FULL)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
    children = self._flatten(child._optimize(model, level) for child in self.children)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
    domain = self._optimize_field_search_method(model)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
    children = cls._flatten(items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
    return DomainOr.apply(Domain(item) for item in items)
  File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
    return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
    return determine(self.search, records, operator, value)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in _search_deferred_revenue
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
  File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in <listcomp>
    ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
    return _compute_field_value.origin(self, field)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
    line.qty_invoiced_at_date = line.qty_invoiced
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
    self.fetch(fnames)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
    field._insert_cache(fetched, values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields_textual.py", line 243, in _insert_cache
    super()._insert_cache(records, values)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
    collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```

- opw-5238152, 5269996
- upg-3306966, 3444833

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

### Issue:
The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method.
When in debug mode, trying to look at the fields of an employee results in a traceback because of this.

### Cause:
This [forward port](https://github.com/odoo/enterprise/commit/4124dc4c13055d39d233d7ea9374b5191afdfcf2#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) had a conflict that was badly resolved by re-adding a previously deleted field.
The field was replaced by `l10n_sa_remaining_annual_leave_balance` in [this commit](https://github.com/odoo/enterprise/commit/339bc032aa763c62d4dd27b73fc42488b3e1c3aa#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5).

[Failing FWP](https://github.com/odoo/enterprise/commit/b3f276d0d73a24faf322aa2ae8965c3d5aad4a87#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5)

### Solution:
We can no longer delete the field because of the stable policy. The solution is to remove the compute and add `store=False`. Then remove the field in master.

opw-5352456

## Versions
19.0+

## Issue
Positive totals for refunds lead to miscalculation and wrong data in the sales report. A PoS order line and its refund should lead to a $0 total.

## Steps to reproduce
*In the PoS app*
- Open a register:
  - Sell 2 units of any product and process payment by cash;
  - Validate payment;
  - Navigate to "Orders" tab and filter on "Paid" orders (instead of "Active"):
    - Select your latest order and refund 2 items;
    - Process refund by cash and validate; *In the Sales app*
- Go to "Reporting > Sales" and change for list view:
  - Display "Untaxed total" column;
  - Filter on 2 last lines (by date and hour):
    - The refund line has positive values for "Untaxed Total" and "Total column";
    - The refund line has a "Untaxed Total" equal to the "Unit Price" but should be multiplied by the quantity;
    - The bold totals are not equal to 0 for "Untaxed Total" and "Total" columns.

## Cause
Commit c5d4e4f73ac0474675414ee89555028b370f8e30 refactored all PoS taxes logic and there were some forgotten parts.

opw-5241438

Before this commit:
- For an employee with a Working Schedule as the work entry source and a default overtime ruleset (which creates a specific work entry type for overtime hours), creating an attendance with a check-in earlier than the employee’s normal working schedule start was not handled correctly. The early portion was ignored, resulting in a wrong attendance work entry duration (e.g., 06:15 instead of 08:00).
- Work entries were not created automatically when approving the attendance. The user had to click Reset to force the generation, which is not the intended workflow.

After this commit:
- Attendance boundaries are now correctly normalized against the employee’s Working Schedule, ensuring the full expected duration is taken into account, even when the check-in occurs before the official start time.
- The overtime ruleset is applied correctly, and the generated intervals properly reflect both standard working hours and overtime hours.
- Work entries are now automatically created upon approval of the attendance, removing the need for any manual Reset action.

task-5082562

**Problem:**
    In the Purchase Comparison view the unit price is
    expressed in the uom of the purchase order line
    so two purchase order lines with different uom will
    be compared without the client knowing it.
    
**Steps to reproduce:**
- create a new product
- set a unit cost of 1
- in the sales tab, in the packagings add
pack of 6
- Create and confirm a PO for 6 unit of this
product
- create and confirm a PO for 1 pack of 6 of
this product
- on the second PO click on the 'price comparison'
smart button

**Current behavior:**
The unit price average on the group by line
is 3.5.
If you click on the line you'll see that the
price unit for the second purchase order line
is expressed in the uom of the purchase order
line (so here it is 6$ per pack of 6).
So the average does not realy make sense.

**Cause of the issue:**
On the purchase order lines price_unit
is expressed in the UoM of the line and not the
uom of the product

**fix:**
We replace the unit price column by a column
with a unit price expressed in the uom of
the product.
The trade off is that, because the new field
is not stored, we don't have an average in
the group by line anymore.

opw-5220196

**Problem:**
partial cogs are not correctly computed
(no test in the commit, waiting for the new setup
https://github.com/odoo/odoo/blob/a3db18acf8010c989c17ea69ad8eb1f0d6bd6116/addons/sale_stock/tests/test_anglo_saxon_valuation.py#L15) 

**Steps to reproduce:**
- create a storable product FIFO/Perpetual
- Order 1 unit of product at 7
- Receive
- Order a second unit at 10
- Receive
- Create SO of 2 units
- Deliver 1 with a backorder
- Invoice one
- Deliver the second
- Invoice remaining

**Current Behavior**:
The first invoice will show double the COGS it is
supposed to (14 instead of 7).
The second invoice shows proper COGS (10)

**Expected behavior:**
Either both cogs should be 8.5 or the first one 7 and
the second one 10.

**Cause of the issue:**
There is two issues here :
- *The first issue* is that when confirming the invoice,
_post() calls _set_value() on the moves.
https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/stock_account/models/account_move.py#L42
In the case of a fifo move this is a problem because
run_fifo is going to be called and the value of the move
is going to be wrongly recomputed based on the current
fifo stack.
This issue can be illustrated by a simpler use case:
       - fifo product
       - one move in at 7, one move in at 10
       - SO for one product and validate the delivery
       - the value of the move is 7
       - create and confirm invoice -> the value of the move is now 10


- *The second issue* is about the cogs computation :
in the case of a fifo product,  _get_cogs_value() calls 
_get_price_unit() on the moves of the sale order line 
(fetched via _get_stock_moves()) to compute the unit price.
https://github.com/odoo/odoo/blob/a3db18acf8010c989c17ea69ad8eb1f0d6bd6116/addons/stock_account/models/account_move_line.py#L73
So when computing the cogs for the first invoice:
Inside _get_price_unit(), the value of our back order 
move (not yet validated) will be taken into account 
in the computation of total_value. 
But because the stock move lines of this move are not 
picked yet, it's quantity will not be taken into account in 
the computation of total_qty (because get_valued_qty() calls
_get_out_move_line() which does not return the unpicked lines).
https://github.com/odoo/odoo/blob/a3db18acf8010c989c17ea69ad8eb1f0d6bd6116/addons/stock_account/models/stock_move.py#L217-L218
So the return value will be 14 (the value of the 2 moves) 
divided by 1 (the quantity of only the first move)

**Fix**
There is two possibility for the cogs in this situation : 
1) cogs of 7 on the first invoice and then later cogs of 10
on the second invoice
 2) cogs of 8.5 on both invoices 

In the current state of the code, the value of the second fifo 
move (10) is not yet set, it will be set when the move is validated.
Therefore we have to go for option 1).
The first part of the fix is to be sure to fetch only 'done' moves
before using _get_unit_price.
The second part of the fix is to deduce the cogs already posted.

opw-5342803

Issue before this commit:
=========================
When a product contains multiple attribute lines using the same attribute and 
also has optional products, attempting to add the product to the cart from the 
website resulted in a server error. The product configurator failed during 
attribute-line processing, causing the Add to Cart button to crash.

Steps to Reproduce:
=========================
1. Install website_sale and enable product variants.
2. Create a product containing:
    - Two or more attribute lines referencing the same attribute
    - At least one optional product.
3. Publish the product on the website.
4. Go to the product page and click Add to Cart button.

Cause of the Issue:
=========================
The website product configurator assumes a one-to-one mapping between attribute
lines and their attributes.
When multiple attribute lines share the same attribute_id, the current mapping 
logic builds an incomplete attribute map.
This causes a KeyError during configurator construction, leading to a error when
adding the product to the cart.
Related to this PR: https://github.com/odoo/odoo/pull/235170

With This Commit:
=========================
A safer attribute mapping mechanism is introduced, ensuring that each attribute
line even if sharing the same attribute always receives its own attribute data.
This prevents missing keys during configurator processing and allows products 
with duplicate attribute lines and optional products to be added to the cart 
without errors.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/1cKLNfJAOvp6IFTmoL4BtkGnZgIV7omta/view?usp=drive_link)

**opw-5361565**

**Steps to reproduce:**
- (Firefox only)
- Go to any record which uses a chatter (e.g. Contact)
- Send message > Full composer > click the schedule message icon (lower right corner)
- Schedule the message in the future and click send
- You should see now a post in the chatter indicating that the message will be sent
- Now click Send message and repeat the above steps again to schedule a second message
- Whole page will be freezed
- Reloading doesn't help

**Issue:**
Infinite loop in reactive callback on firefox.
The code gets stuck in
```js
for (const callback of [...callbacks]) {
    clearReactivesForCallback(callback);
    callback();
}
```
because of
```js
const sortProxy2 = reactive(recordProxy, function sortObserver() {
    self.requestSort(record, fieldName);
});
this.fieldsSortProxy2.set(fieldName, sortProxy2);
```
which loops over `store._.ADD_QUEUE("sort", record, fieldName);`

(Forcing the `requestSort` only change the infinite loop into a recursion error)

The recomputation seems to be caused by `record[fieldName]` being an array filled with empty slots (previously deleted values). As to why it only happens on firefox, no idea, it's probably related to the design of the tracking on empty slots.

**Fix:**
Avoid reactivity when the value is an array with empty slots. The issue could also happen in other places (e.g. for the `computeProxy2`). Finding a better more reliable/generic fix would be great to avoid the issue on owl level.

related: https://github.com/odoo/odoo/commit/ba77db25c836cb692066cb9487842f7f683beaad

opw-5367371

Before this commit, internal URLs (i.e. "blob:" and "data:") required                                                                                                                     
'fetch' to be mocked to work. This is wierd because these requests are                                                                                                                    
handled directly by the browser and shouldn't require any particular                                                                                                                      
manipulation from the (mocked) server.                                                                                                                                                    
                                                                                                                                                                              
This commit ensures that internal URLs still work without fetch being                                                                                                                     
mocked.    

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

Steps to reproduce:
--------------------------
1. Install the Quality module.
2. Create a Quality Control Point with:
   * Control per: Control on Operation.
   * Operation: Receipts (set in the Operations field).
3. Create a Receipt containing one product.
4. Click the Mark as To Do button.
5. Add another product to the same Receipt and save it.

Observation:
--------------------------
Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation.

Issue:
--------------------------
No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation.

Solution:
--------------------------
Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created.

opw-5249233