Steps to reproduce the issue:

- Enter Website edit mode.
- Click on the "Theme" tab.
- Pick a black color for the website background (4th color button).
- Click on a link in the website navbar to make the link popover appear.
- Bug: The popover background is black, and its buttons are not visible as they are also black.

Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce cart button, with the theme colors. However, the change unfortunately also affected the link editing popover, which should remain neutral as it is part of the interface elements.

[1]: https://github.com/odoo/odoo/commit/0d96be06faf8aad1a92183bd2b6371253980c7e6

task-4422810

| Before  | After |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/a217c886-9521-4347-a0db-7d6cd7b6029b)  | ![image](https://github.com/user-attachments/assets/f06e4618-e896-430c-8063-bbe3dd534055)  |

Forward-Port-Of: odoo/odoo#203958

Steps to reproduce:
- Install stock, stock_account, sales
- Create a product with pricing policy not standard(AVCO, FIFO)
- Track this product by lot and keep lot valuation **unchecked**
- Add a quant of the product with this lot
- Create a quotation on the product and confirm the SO
- Confirm the delivery
- Activate the lot valuation on the product
- Make a return delivery based on the delivery we had
- Confirm the return

**Issue**:
Traceback is thrown
```py
new_std_price = ((amount_unit * qty_avail) + (move_cost[lot] * qty)) / (qty_avail + qty)
KeyError: stock.lot(55,)
```
Because `move_cost` is a dictionary returned by `_get_price_unit()`, which gets the current lots’ valuations. Since the pick is a return one, then `_get_price_unit()` uses the original pick stock valuation layers and hence we were disabling the valuation on the original delivery then the layers don’t have the lot of the product valuated. Then the `move_cost` dict is not having the lot of the product while valuating it currently, hence the KeyError is thrown. This issue happens with the AVCO, FIFO because both valuation models depend on the already valuated lots values using the `_get_price_unit()`.

**FIX**:
Ensure `_get_price_unit()` properly handles cases where lot valuation was disabled at the time of the original move but is enabled later by adding lots of the return pick if not included in the valuation layers of original pick.

opw-4662744
opw-4660094

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

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

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailled operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Enterprise: https://github.com/odoo/enterprise/pull/81850

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

Forward-Port-Of: odoo/odoo#203662
Forward-Port-Of: odoo/odoo#202725

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

Prior to this commit, using a `/banner` block would create elements that always
have `contenteditable` attributes when saving, that are always different from
the server value which removes these `contenteditable` attributes, resulting in
a new `Wysiwyg` instance being constructed after each `save`.

Resolution:
1- Introduce new classes to handle the `contenteditable` attribute:
  `o-contenteditable-true` and `o-contenteditable-false` to avoid a namespace
  conflict with `website` specific features. They replace `o_editable` and
  `o_not_editable` for the `banner` block.
2- Ensure that `contenteditable` attribute handled by these classes are removed
  during `cleanForSave`, to create a value comparable to the server value. This
  is because the server sanitizes the `contenteditable` attribute. If both
  compared values are not equal, the current `Wysiwyg` and `Editor` instances
  would be fully replaced after each save, resulting in a loss of edition
  history. This should ideally never happen.
3- Ensure the attributes `role` and `aria-label` which are also sanitized by the
  server are removed during `cleanForSave` and maintained during
  `normalize` through `data-oe-role` and `data-oe-aria-label`.
4- Introduce a `o_editor_banner_content` class for the `banner` content, for
  ease of selector creation.
5- Ensure that the `baseContainer` created before the `banner` if it is the
  first element in the `editable` has the proper `tagName` based on the
  `HtmlField` configuration.

A `html_migrations` version is added to adjust existing `banners` to the new
classes usage.

task-4640490

Forward-Port-Of: odoo/odoo#204656
Forward-Port-Of: odoo/odoo#201139

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

Description
------------
Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal execution plan when using a limit of 4 records.

With a very low limit of 4, PostgreSQL would choose to perform an index scan on the `complete_name` index instead of using the more efficient trigram indexes. This resulted in high I/O operations as it traversed the index from A until finding matches, causing significant performance degradation.

The fix simply increases the limit to 8, consistent with other `name_search` operations, ensuring the query planner consistently chooses the trigram index path regardless of the search term.

Benchmark
----------
On a database with over 8 digits count of partners, a non selective search of a partner (5 chars) took:

| Before | After | Speedup |
|--------|-------|---------|
| 27.4s  | 42ms  | 652x    |

Reference
---------
task-4686893

Forward-Port-Of: odoo/enterprise#82680

…with empty working schedule

**Issue**
When setting the working schedule to empty, opening the Gantt view is not possible as an error is displayed

Steps to Reproduce:

1. Login as Mitchell Admin
2. Install Employees and Project apps
3. Go to Employees > Contracts
4. Select a contract from Mitchell Admin
5. Empty the Working Schedule Field
6. Set Planning or Attendances as work entries > Save
7. Go to project app
8. Select a project
9. Switch to the Gantt view
10. An error message appears
11. Expected Behavior: Gantt view should be displayed without errors. Actual Behavior: Gantt view is not displayed, and an error message appears.

**Root Cause**

The issue occurs because before processing the work intervals, the system checks for the presence and uniqueness of a calendar. If a user has no assigned schedule, the function attempts to process a None value, which results in an error when calling ensure_one in _attendance_intervals_batch.

**Fix**
To prevent the error, users without a working schedule are skipped when computing valid work intervals. If a user has no assigned schedule, they will not be included in _work_intervals_batch, ensuring the function executes correctly without attempting to process an empty calendar.


opw-4462241

Forward-Port-Of: odoo/enterprise#79159

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

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

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

opw-4480104

Forward-Port-Of: odoo/enterprise#82643
Forward-Port-Of: odoo/enterprise#81850

[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