Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.

This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.

Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.

This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.

⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.

Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:

|                       | Before  | After  | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time  | 400ms   | 160ms  | 2.5x        |
| Frontend process time | 3.3s    | 220ms  | **15x**     |
| Total (LCP) time      | 3.7s    | 380ms  | 9.7x        |
| Response Payload size | ~800KiB | ~33KiB | **24x**     |

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

Forward-Port-Of: odoo/odoo#232354

Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

Forward-Port-Of: odoo/enterprise#95982
Forward-Port-Of: odoo/enterprise#94438

When archiving an employee with a Detailed Reason, a traceback occurs.

Steps to reproduce the error:
- Open any employee record > Archive
- Set ``Detailed Reason`` > Apply

Traceback:
```py
NotImplementedError: Unsupported tracking on field departure_description (type html
```

https://github.com/odoo/odoo/blob/8002b82d5783744b88b75c1199c4c1f222a0f7d0/addons/hr/models/hr_version.py#L130
here, ``tracking=True`` was added for the ``departure_description`` html field by the commit [1].
but tracking is not supported for the html field.
So, it will lead to the above traceback.

Tracking for ``departure_description`` field is already handled via a chatter message in the write method by the commit [2]. https://github.com/odoo/odoo/blob/8002b82d5783744b88b75c1199c4c1f222a0f7d0/addons/hr/models/hr_employee.py#L1187-L1191

[1]: https://github.com/odoo/odoo/commit/aa4d13b89b4497d2e5b33faa49ad86e0788782a2

[2]: https://github.com/odoo/odoo/commit/9b723e2591224f2b563924d3b3dfe27ab909b7d0

sentry-6973440621

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

Before this PR, if you created a leave of a type that had sandwich leave
enabled on a non-working day, it would show a negative duration.

This PR fixes some issues related to sandwich leave cases

(where Saturday and Sunday are considered non-working days):
- Friday - Monday across weekend - counted (4 days).
- Hour-based leave types: weekend bridging increases hours accordingly
- Public holiday in the middle (Tue-Thu with Wed PH) - counted (3 days).
- Stop/Start exactly on a public holiday(Tue-Wed(Public holiday), or Wed(Public holiday)-Thu) - trimmed to 1 day.
- Public holiday only - 0 days.
- Two single-day leaves around a Public holiday
  - When the second leave is created, it bridges via a public holiday (2 days),
  - The first one remains 1 day if it stands alone
- Mixed leave types:
  - If the linked leave type doesn’t have sandwich enabled, no sandwich rules.
  - If both leave enable sandwich (with different types) - sandwich rule applies
- Refusing/canceling a linked leave must immediately adjust the other side’s duration
(e.g., Monday refused - Friday drops from 3 - 1 day)

Task-4430044

Co-authored-by: @mepe-odoo

Forward-Port-Of: odoo/odoo#233717
Forward-Port-Of: odoo/odoo#193186

The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker.

This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop.

For a specific customer (opw-5025162), this was the case.

Benchmarks:

| No. stock.picking | avg no. quality checks | peak memory before | peak memory after |
| ----------------- | ---------------------- | ------------------ | ----------------- |
| 25                | 20                     | 2771 mb            | 235 mb            |

opw-5025162

Forward-Port-Of: odoo/enterprise#95568

In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund).

In Italy, a product cannot have more than one VAT tax. Also, the FatturaPA XML structure only allows global declarations for withholding and pension fund taxes — on the line level, it can only specify if those taxes apply, not which ones. To reflect this, we enforce one tax per kind per line. This validation was broken and recently fixed.

However, ENASARCO is a special case: it acts both as a withholding and a pension fund tax. We added the Withholding flag recently (odoo/odoo#226968). In realistic cases (e.g., a line with VAT + withholding 23% RIT AG + ENASARCO), the validation fails and the user gets a blocking error in account.move.send.

Since ENASARCO already has dedicated support through the AltriDatiGestionali tag on the line, we allow it to pass the check as if it were only a pension fund, restoring the previous behavior before we added the withholding flag.

Some validation added and fields clear up in the tax editing phase, preventing invalid cases.

Ticket [link](https://www.odoo.com/odoo/project.task/5154223)
opw-5154223

Forward-Port-Of: odoo/odoo#233698
Forward-Port-Of: odoo/odoo#232140

Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.

This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.

Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.

This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.

⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.

Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:

|                       | Before  | After  | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time  | 400ms   | 160ms  | 2.5x        |
| Frontend process time | 3.3s    | 220ms  | **15x**     |
| Total (LCP) time      | 3.7s    | 380ms  | 9.7x        |
| Response Payload size | ~800KiB | ~33KiB | **24x**     |

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

Forward-Port-Of: odoo/odoo#232354

Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code.

If a new module (e.g., restaurant) adds a new object store to the PoS database schema but the `dbVersion` is not bumped, the store is never created. This causes the PoS session to fail when it tries to access the missing store.

This commit modifies the `databaseEventListener` to add a check inside the `onsuccess` handler. After the database opens, it compares the list of required stores (`this.dbStores`) with the list of existing stores (`this.db.objectStoreNames`).

If a mismatch is detected:
1. The current database connection is closed.
2. The `dbVersion` is incremented.
3. The database connection process is re-run.

This forces the `onupgradeneeded` event to trigger, which then correctly creates the missing object stores, ensuring the database schema is always up-to-date.

opw-5166049

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

The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker.

This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop.

For a specific customer (opw-5025162), this was the case.

Benchmarks:

| No. stock.picking | avg no. quality checks | peak memory before | peak memory after |
| ----------------- | ---------------------- | ------------------ | ----------------- |
| 25                | 20                     | 2771 mb            | 235 mb            |

opw-5025162

Forward-Port-Of: odoo/enterprise#95568

[FIX] website: get scroll from document element for footer animation

__Current behavior before commit:__
Since [this PR], the scrolling is not done on `#wrapwrap` anymore.
Now when an animation is set on an element inside the footer it
will not appear if a slideout effect is set on it.

__Description of the fix:__
Get `scrollTop` and `scrollHeight` from the document element instead of
`#wrapwrap` and add a test tour.

__Steps to reproduce:__
1. Open the Website builder.
2. Click on a column in the footer.
3. Set an "On Appearance" Animation on it.
4. Set the footer Slideout Effect to "Slide Hover".
5. Add some content on the page so that it's needed to scroll for the
footer to be visible.
6. Save.
7. Scroll to the footer.
=> The column doesn't appear.

[this PR]: https://github.com/odoo/odoo/pull/98429

---

[FIX] website: scroll on new entry in faq horizontal

__Current behavior before commit:__
Since [this PR][1], the scrolling is not done on `#wrapwrap` anymore.
Now when adding a new entry to the snippet faq horizontal, the page
doesn't scroll automatically to the new entry.

This behavior has actually never worked because [the PR that introduced
faq horizontal][2] was merged just after [the PR that moved the
scrolling to the document element][1]. 

__Description of the fix:__
Get `scrollTop` and `scrollHeight` from the document element instead of
`#wrapwrap` and add a test tour.

__Steps to reproduce:__
1. Open the Website builder.
2. Drag a Text block
3. Choose the FAQ horizontal snippet
4. Click on "Add New"
=> The page doesn't scroll to the new entry.

[1]: https://github.com/odoo/odoo/pull/98429
[2]: https://github.com/odoo/odoo/pull/176438

Forward-Port-Of: odoo/odoo#233850
Forward-Port-Of: odoo/odoo#228396

The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker.

This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop.

For a specific customer (opw-5025162), this was the case.

Benchmarks:

| No. stock.picking | avg no. quality checks | peak memory before | peak memory after |
| ----------------- | ---------------------- | ------------------ | ----------------- |
| 25                | 20                     | 2771 mb            | 235 mb            |

opw-5025162

Forward-Port-Of: odoo/enterprise#95568

### Issue:

Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors.

### Steps to reproduce:

- In the settings enable "Batch Transfers"
- Inventory/Operations/Transfers/Batch Transfers
- Create a new batch and do not confirm it
- Go to the barcode app > Batch Transfers > Clear filters
- Select your draft batch
- Scan anything
#### > Traceback

#### Other issues:

The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done".

### Cause of the issue:

Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error:
https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179

opw-5162164

Forward-Port-Of: odoo/enterprise#97816
Forward-Port-Of: odoo/enterprise#97526

[IMP] account_accountant: css backport

To have a consistent css across all version of the new bank rec widget, we
decided to backport few changes.

backport of:
https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a
https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb
https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667
https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a
https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e

[FIX] account_accountant: restrict some account in the set_account

Before this commit, we could select the liquidity account or bank suspense
account which could create a reco model for it that would do nothing.

[FIX] account_accountant: partner_name

Before this commit, when a transaction had no partner_name and some lines with
the same partner. When unfolded, we had the info of the partner on the statement
line and on the line itself which was a duplicate of information.

This commit will change when the line is unfolded so that the partner is visible
on the statement line only when there is a partner_name

[FIX] account_accountant: payable and receivable button

Before this commit, the payable and receivable buttons where on the top line
only when the reconcile button was not there anymore. Now We decided to always
have them present in secondary next to the reconcile button.

no task-id

Forward-Port-Of: odoo/enterprise#98458
Forward-Port-Of: odoo/enterprise#96852

#### Issue:

In this bug, workorder duration inverse is causing some time_ids to be deleted.

To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
   - First one 10:00 -> 12:00
   - Second one 10:00 -> 11:00

5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked

#### Cause:

The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.

To be specific this is the compute function override: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766

In which duration is calculated using get_duration: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837

Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.

However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals: https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400

As a result, if time_ids overlap:
new_order_duration < old_order_duration

As a result some time_ids will be unlinked and some will have duration changed.

#### Fix:

Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```

As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899

The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.

In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.

However, this might cause another issue:
If `order.duration` is not computed yet, and inverse method `_set_duration` is called, then `get_duration` inside `_set_duration` will be called before the `get_duration` in compute method. As a result there might be a small unexpected time difference between `old_order_duration` and `new_order_diuration`. To avoid that inside `get_working_duration` we can use cursor now instead:
```diff
+ now = self.env.cr.now()
- now = datetime.now()
```

opw-5082477

Forward-Port-Of: odoo/enterprise#96632

*: ai_website_livechat, test_discuss_full_enterprise

Before this commit, when the last agent from a live chat conversation leave, the live chat conversation did not end.

Steps to reproduce:
- install "ai" and "im_livechat" modules
- have a visitor initiate a live chat conversation with 1 available human agent
- have have human agent open conversation in chat window and close chat window + confirm button
=> the live chat conversation does not end

When live chat agent is about to close the chat window of live chat, there's a warning to tell that this will make him/her leave the conversation and thus end the conversation. When proceeding, it doesn't actually do this.

This is a bug caused by overrides of `ChatWindow._onClose()`, which is a function invoked during the closing of chat window, that has an option `notifyState` that determines whether the user leaves the conversation or not. The overridden code had to ensure the param is preserved and passed to `super` calls, but they fail to do this, and thus the closing of chat window is not making the user leave the conversation.

This commit fixes the issue by passing `...arguments` to super calls to make sure the params are preserved as expected by original code of the `_onClose` function.

Note that we had a test for the good working of the feature, but this test run with `im_livechat` assets and not overrides on top of it such as `ai` module. The main culpit of the problem was caused by the override in `ai` module. To have test coverage for this problem, the test is not executed in both `im_livechat` test suite and the `test_discuss_full_enterprise`, which is a module whose HOOT suite runs code of discuss with all overrides such as `ai` module.

Forward-Port-Of: odoo/enterprise#98481

_______________________________________
## Short functional explanation of the error
Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens.

## Reproduction Steps
1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2.
2. Select both companies. In planning, create a slot for company_2 and publish it.
3. Log in as the user you created. Make sure that the current company is company_1. Select company_2.
4. Go to planning and try to assign yourself to the slot you've just created as an admin

### Expected behavior
Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected).

### Unexpected behavior
Nothing happens

## Origin of the issue
When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee,
self.env.user.employee_id is set at False

_________________________________________
opw-4963674

---

Forward-Port-Of: odoo/enterprise#95933
Forward-Port-Of: odoo/enterprise#91616

Currently, on creating a budget using split budget causing an error.

**Steps to Reporduce:**
1) Install **account_budget module(with Demo)**
2) Navigate to **Accounting>Accounting>Analytic Budget** 
3) Click on `Generate` set `Analytic Plan` and click on `Split`

Error:
`ValueError: Cannot convert budget.line.achieved_amount to SQL because it is not stored`

Root Cause:
since [this commit](https://github.com/odoo/odoo/pull/224667/commits/53b4670b1ad375ffc3800fc3beb97e960f229dc6), a new aggregate spec `sum_currency` was added. As a result, the code at [1] is executed for currency-aware aggregates. From the line, `self._field_to_sql(self._table, fname, query)` the ORM tries to create an SQL expression for `achieved_amount`. Because `achieved_amount` is computed `_field_to_sql` fails and error is raised.

Fix:
Provide a default SQL expression for computed fields on Budget Line

[1]: https://github.com/odoo/odoo/blob/af668f545676f72385c52629f8498edfe22219cd/odoo/orm/models.py#L1972-L2004

Used Reference: https://github.com/odoo/odoo/blob/d42102cac8fff3967cb605a897bbb0e8690464ed/addons/crm/models/crm_lead.py#L286-L298

sentry-6917352415

Forward-Port-Of: odoo/enterprise#98215

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#97700
Forward-Port-Of: odoo/enterprise#96299

Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

Forward-Port-Of: odoo/enterprise#95982
Forward-Port-Of: odoo/enterprise#94438

[IMP] account_accountant: css backport

To have a consistent css across all version of the new bank rec widget, we
decided to backport few changes.

backport of:
https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a
https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb
https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667
https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a
https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e

[FIX] account_accountant: restrict some account in the set_account

Before this commit, we could select the liquidity account or bank suspense
account which could create a reco model for it that would do nothing.

[FIX] account_accountant: partner_name

Before this commit, when a transaction had no partner_name and some lines with
the same partner. When unfolded, we had the info of the partner on the statement
line and on the line itself which was a duplicate of information.

This commit will change when the line is unfolded so that the partner is visible
on the statement line only when there is a partner_name

[FIX] account_accountant: payable and receivable button

Before this commit, the payable and receivable buttons where on the top line
only when the reconcile button was not there anymore. Now We decided to always
have them present in secondary next to the reconcile button.

no task-id

Forward-Port-Of: odoo/enterprise#98325
Forward-Port-Of: odoo/enterprise#96852

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

-> Resolved in 19.0 see https://github.com/odoo/enterprise/commit/060f4c3e24e7add05273cfad5853884546937d0e#diff-3c84b414a086808e446ae3f90b3b803edf964c28237c153af19edda3ed05cc6bL21

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#97497
Forward-Port-Of: odoo/enterprise#96299

Currently, on creating a budget using split budget causing an error.

**Steps to Reporduce:**
1) Install **account_budget module(with Demo)**
2) Navigate to **Accounting>Accounting>Analytic Budget** 
3) Click on `Generate` set `Analytic Plan` and click on `Split`

Error:
`ValueError: Cannot convert budget.line.achieved_amount to SQL because it is not stored`

Root Cause:
since [this commit](https://github.com/odoo/odoo/pull/224667/commits/53b4670b1ad375ffc3800fc3beb97e960f229dc6), a new aggregate spec `sum_currency` was added. As a result, the code at [1] is executed for currency-aware aggregates. From the line, `self._field_to_sql(self._table, fname, query)` the ORM tries to create an SQL expression for `achieved_amount`. Because `achieved_amount` is computed `_field_to_sql` fails and error is raised.

Fix:
Provide a default SQL expression for computed fields on Budget Line

[1]: https://github.com/odoo/odoo/blob/af668f545676f72385c52629f8498edfe22219cd/odoo/orm/models.py#L1972-L2004

Used Reference: https://github.com/odoo/odoo/blob/d42102cac8fff3967cb605a897bbb0e8690464ed/addons/crm/models/crm_lead.py#L286-L298

sentry-6917352415

### use overlay offset for basic editor

In this prior [fix], overlays spawned by the HtmlBuilder and its children have a
modified offset in order to prevent the `MassMailingIframe` from unloading its
content.

However the `MassMailingHtmlField` also handles a Simple Editor feature, which
does not use the Builder.
This feature still uses an iframe and also uses overlays (popover toolbars).

This work moves the [fix] in `MassMailingIframe` so that it applies also for
the Simple Editor.

[fix]: https://github.com/odoo/odoo/commit/dd31e31f3cecd4d23dc90f9c88780bf3b969a294

### ensure correct editor instance on record switch

Issue:
When switching from one record to another using the Form view pager, the
`activeTheme` was set to the theme value of the previous record, resulting in
the wrong Editor instance in some cases.

How to reproduce:
- Open the list view in Email Marketing
- Ensure there are 2 records in the list view:
  - one editable with the builder (default theme)
  - one editable with the simple editor (basic theme)
- click on the record with the simple editor
- use the pager to switch to the next record

Issue:
- switching from simple -> builder, the builder is not instanced but it should
  have been
- switching from builder -> simple, the builder is instanced but it should not
  have been

Resolution:
Update the active theme based on the value of the nextRecord instead of the
record currently in `props`, because `this.props.record` is updated after
`updateActiveTheme` is called.

task-5217595

In version `19.0` new hierarchy views was added to module `hr_appraisal` by this commit[^1]. But the module `web_hierarchy` is not dependency of `hr_appraisal`.

When we install `hr_appraisal` it triggers the installation of `hr` because of dependency. On the other side `hr_org_chart`[^2] gets installed because of auto_install=true. So it makes `web_hierarchy` installed because of the `hr_org_chart` dependency.

If we upgrade db from `18.0` to `19.0` which `hr_appraisal` installed and `web_hierarchy` uninstalled we will get issue as `hr_appraisal` requires dependency to `web_hierarchy` because of new views.

Steps to reproduce (case 1):
1. Install `hr_appraisal` in `18.0`
2. Uninstall `web_hierarchy`
3. Upgrade to `19.0`

Steps to reproduce (case 2):
1. Install `hr_appraisal` in `16.0`
2. Uninstall `hr_org_chart`
3. Upgrade to `19.0`

In this 2nd case, the `web_hierarchy` is not existing yet and `hr_org_chart` is auto installed module, so during upgrade it will not be re-installed again.

We will get traceback like this:

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1509, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 185, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 449, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 211, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 58, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 646, in convert_file
    convert_xml_import(env, module, fp, idref, mode, noupdate)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 745, in convert_xml_import
    obj.parse(doc.getroot())
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 616, in parse
    self._tag_root(de)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 570, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/19.0/hr_appraisal/views/hr_appraisal_goal_template_views.xml:71
Invalid view type: 'hierarchy'.
You might have used an invalid starting tag in the architecture.
Allowed types are: list, form, graph, pivot, calendar, kanban, search, qweb, cohort, gantt, grid, map, activity

View error context:
'-no context-'

```

[^1]: https://github.com/odoo/enterprise/commit/dbe4946218b3523bea4fb8a79be8f3fc29d8d33e
[^2]: https://github.com/odoo/odoo/blob/dec621e60794ede263222e3b5be0ebfc33ed6f40/addons/hr_org_chart/__manifest__.py#L16-L17

Currently, an error occurs when creating a sale order for a project.

**Steps to Reproduce:**
 - Install the `sale_project` module.
 - Go to `Project` and, in the `list view`, create a `project` and `set a customer`.
 - Click the `Sales Order` button in the header.
 - Save the `sale order` without adding `any product` or by adding a `non-service product`.

**Error:**
`AttributeError: 'bool' object has no attribute 'order_id'`

This error occurs, when user creating a sale order for a project without adding a service product, then 
service sol becomes empty [1], which raises an error here [2] when trying to access the sale order.

This commit ensures that if there is no service sol, empty sol is taken in the service sol.

[1]- https://github.com/odoo/odoo/blob/3121577430cdfa485af4d69792745a6f9c2ffe2f/addons/sale_project/models/sale_order.py#L272

[2]- https://github.com/odoo/odoo/blob/3121577430cdfa485af4d69792745a6f9c2ffe2f/addons/sale_project/models/sale_order.py#L276

sentry-6948584510

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

Description of the issue/feature this PR addresses:
Issue reported[ here ](https://github.com/odoo/odoo/issues/233130)

Impacted versions:
19.0 (and likely earlier stable versions: 17.0, 18.0)

Steps to reproduce:

Open the Website Editor or HTML Editor (e.g., editing a website page).
Insert or select an image that has been saved as an attachment (source is a /web/image/... URL, not a Base64 string).
Perform an action that triggers the attachment modification logic (e.g., applying a filter, or a WebP conversion step).


**Current behavior before PR:**
- The client-side JavaScript correctly omits the data parameter in the RPC request to /html_editor/modify_image/<attachment_id>.
- The Python modify_image controller receives data=None, and subsequent image processing fails because it expects the image content, leading to a server-side traceback (e.g., a KeyError or a failure in image manipulation libraries).

**Desired behavior after PR is merged:**
The modify_image controller should successfully retrieve the existing image content from the database and process the modification without error.

- This controller endpoint handles modifications for existing attachments. When the client is modifying a server-stored image (sourced via /web/image/...), the client efficiently omits the image data payload.
- The controller should be resilient to this behavior by retrieving the image content directly from the existing attachment record.
- The fix introduces a conditional check to load the image's base64 content (attachment.datas) into the data variable if the client does not provide a new payload (data is None).
- This is the most robust and performant solution, as it ensures the controller has the necessary image data without forcing the client to re-upload potentially large files


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

Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code.

If a new module (e.g., restaurant) adds a new object store to the PoS database schema but the `dbVersion` is not bumped, the store is never created. This causes the PoS session to fail when it tries to access the missing store.

This commit modifies the `databaseEventListener` to add a check inside the `onsuccess` handler. After the database opens, it compares the list of required stores (`this.dbStores`) with the list of existing stores (`this.db.objectStoreNames`).

If a mismatch is detected:
1. The current database connection is closed.
2. The `dbVersion` is incremented.
3. The database connection process is re-run.

This forces the `onupgradeneeded` event to trigger, which then correctly creates the missing object stores, ensuring the database schema is always up-to-date.

opw-5166049

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

Forward-Port-Of: odoo/odoo#233268

Steps to Reproduce:
- Create a Sale Order containing two combo products placed consecutively.
- Change the quantity of the first combo → corresponding combo items update correctly.
- Without saving, change the quantity of the second combo.
- Observe that the combo items now appear misplaced — items from the second combo are inserted before those of the first combo.

Issue:
- The order of combo items becomes incorrect when multiple combo products are updated consecutively in the same unsaved Sale Order.

Cause:
- During `onchange`, the `self.order_line` recordset reflects the *in-memory order of applied commands* rather than the database `sequence` field because they are not saved in the DB during the edition.
- Each `onchange` rebuilds `order_line` using concatenated command lists (`delete + create + update`), So when multiple combos are modified without save, newly created combo items are appended according to command evaluation order — not by logical grouping.
- This causes combo items to shift relative to their parent combo lines.

Solution:
- Restrict the recomputation of order lines to non-combo lines by filtering out combo item lines during the rebuild. As combo items will always be in their desired sequence.
- This ensures that combo items always stay under their respective parent combos and their sequence is preserved, regardless of the order in which combos are updated.

opw-5148770
Affected Version:18.0

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

Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged.

Cause:
- The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns.

Fix Applied:
- Updated frontend (`filters.js`) to call `format_column_values_from_client` via
  `dispatch_report_action` instead of calling `format_column_values` directly.
  (this enables proper routing through the custom handler system)
- Added `format_column_values_from_client` override in `JournalReportCustomHandler`
  that intercepts the formatting call and applies special handling for tax summary
  lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines`
  monetary fields using their `_no_format` counterparts.
- The custom handler then delegates to the base method via
  `report.format_column_values_from_client()` to format standard columns.
- Also added missing `_no_format` fields in `account_journal_report.py` for
  `base_amount` and `tax_amount` to enable proper reformatting.

Forward-Port-Of: odoo/enterprise#94660

Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues.

The reconciliation logic worked as follows:

1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`.
2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`.
3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`.

The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`.

---

To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced.

- Reconciliation now starts by iterating only over the relevant `in_moves`.
- If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`.
- This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited.

**Implementation details:**

- An `OrderedSet` is used for the inverse mapping to preserve the original query order.
- Benefits of `OrderedSet`:
  - **O(1)** removal (assuming no collisions)
  - Maintains insertion order, ensuring the same order as the query result.

---

| Metric        | Before PR | After PR |
|---------------|-----------|----------|
| Execution Time| ~90 sec   | ~10 sec  |

The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`.

opw-4951469

# Issues

There are a total of 3 different flows by which we observe the common issue (name not updating in the fileviewer)

-----------------------------

### 1st flow
1. click on any image to preview it.
2. close the preview.
3. now just select the same document.
4. change it's name from the inspector and hit ENTER.
5. now keeping it selected, preview it again.
6. you will notice the file name has not been updated in the file viewer.

issue:
- the existing IF condition which is present only checks for the datapoint ID
  (which changes only when we replace the existing document with a new document).

reason:
- but in our case, since the document is same the ID remains the same.
- as a result, the code inside the IF block does not get executed and the
  document store is not updated.
  but we still need to update the document store with the newly updated document.

fix:
- we remove the IF condition so that we ensure that the document store is
  updated everytime we PREVIEW any document.

----------------------------------------------------

### 2nd flow

1. click on any image to preview it. (do not select it)
2. change it's name from the inspector and hit ENTER.
3. close the PREVIEW.
4. PREVIEW the same document again.
4. you will notice the file name has not been updated in the file viewer.

issue:
- for some reason the existing `record.save()` fails to save/update the root
  records.

fix:
- we find that record from the root and save it from the root.


----------------------------------------------------------

### 3rd flow

1. click on any image to preview it.
2. change it's name from the inspector and hit ENTER.
3. you will notice the file name has not been updated in the file viewer.

issue:
- the `previewStore` object is formed/updated only when we preview any document.
  it is this `previewStore` object which contains the list of documents to preview.
- but when we update the file name from the inspector, the code to update the
  `previewStore` is absent.

fix:
- on updating the values from the inspector, we now update the `previewStore`
  as well. which then goes on to update the name in the FILEVIEWER.

Task-4605750

**Issue:**
For retired employees with AHV Insurance and variable pay, if their pay previously exceeded the exempt amount but is below the exempt amount on the current payslip, the AVS Salary will be negative, which is expected.

However, the AVS deduction is still calculated based on this negative amount and adds to the Net Salary, which is incorrect. Instead, no deduction should be applied.

**Steps to Reproduce:**
1) Install l10n_ch_hr_payroll_elm_transmission
2) Change to My Swiss Company and enable the Switzerland Fiscal Package
3) Go to Payroll > Configuration > AVS/AC Insurances
4) Create a new record, fill in the empty required fields with any data
5) Create a new employee
6) Create a contract for the employee starting January 1, with:
- Contract Type = Permanent contract with monthly salary
- Has Monthly Wage = True, 500.00
7) On the contract under Insurances tab, set:
- AVS/AC Insurance = The Insurance created in (4)
- AVS Special Status = Retired
8) Create a payslip for January, compute sheet, and post draft entries. -> AVSSALARY = 0 (Correct)
9) Change the Monthly Wage and repeat payslip creation and posting for the following months:
- February: 800
- March: 1,200
- April & May: 3,000
- June: 800
-> On the June payslip, notice that the AVS Salary is negative (correct) but the AVS Deduction is positive and adds to net salary (wrong)

**Solution:**
Modify the AHV/IV/EO contribution and AHV/IV/EO Employer contribution rules so that if the AVS Salary is less than 0, no deduction is made.

opw-5042175