Behavior before:
When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors.

Behavior after:
Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets.

Root cause:
The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation.

Benchmark:

| Period size (journal items)  | Before patch   | After patch   |
|----------------------------------------|----------------------|--------------------|
| ~15k                                        | 7s                      | 5s                   |
| ~200k+                                    | Timeout error| 21s                 |


opw-5046077

Forward-Port-Of: odoo/enterprise#97660
Forward-Port-Of: odoo/enterprise#95047

**Steps to reproduce:**
1. Install the *Fleet* and `accounting` modules.
2. Create a new purchase tax.
3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund.
4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines.
5. Check the *Tax Report*(account>tax), including the date of this vendor bill.

**Observed behavior:**
* Tax lines linked to the current asset account are merged.
* Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`).
* This mismatch triggers an error in the tax report.

**Root cause:**
The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles.

**Solution:**
Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error.

opw-5013757

Forward-Port-Of: odoo/odoo#232001
Forward-Port-Of: odoo/odoo#228422

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

Forward-Port-Of: odoo/odoo#233740

[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#233911
Forward-Port-Of: odoo/odoo#228396

### 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#98022
Forward-Port-Of: odoo/enterprise#97526

Behavior before:
When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors.

Behavior after:
Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets.

Root cause:
The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation.

Benchmark:

| Period size (journal items)  | Before patch   | After patch   |
|----------------------------------------|----------------------|--------------------|
| ~15k                                        | 7s                      | 5s                   |
| ~200k+                                    | Timeout error| 21s                 |


opw-5046077

Forward-Port-Of: odoo/enterprise#97660
Forward-Port-Of: odoo/enterprise#95047

Steps:
- Install account app.
- Create a branch company under the main company.
- Create a tax for the branch company.
- Add a main company tax on a product.
- Switch to branch company.

Issue:
- Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form.

Cause:
- After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company.

Fix:
- Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents.

[PR]: https://github.com/odoo/odoo/pull/194881
[17.0 PR]: https://github.com/odoo/odoo/pull/125642

opw-5042833

Forward-Port-Of: odoo/odoo#233720

Currently, a missing exception is triggered when reopening a PoS session after a partner is deleted.

**To reproduce this issue:**

1) Install point_of_sale and pos_settle_due.
2) Open a PoS session
3) Create a customer and place an order with payment. 
4) Without closing the session, go to the backend. 
5) Delete the customer from Contacts.
6) Reopen the previously opened PoS session.

**Error:**
A `missing record` exception is triggered.

**Cause:**
When the user reopens a PoS session after deleting a partner, 
the method `setAllTotalDueOfPartners` is triggered during setup.
https://github.com/odoo/enterprise/blob/7c6ba26970698cb60121157c2cca0e414d5b62a0/pos_settle_due/static/src/app/services/pos_store.js#L7-L9
https://github.com/odoo/enterprise/blob/7c6ba26970698cb60121157c2cca0e414d5b62a0/pos_settle_due/static/src/app/services/pos_store.js#L44-L48

This method makes an RPC call to `get_all_total_due` to update all partners' due amounts.
Since the partner was deleted, this causes a missing record exception.
https://github.com/odoo/enterprise/blob/7c6ba26970698cb60121157c2cca0e414d5b62a0/pos_settle_due/models/res_partner.py#L28-L32

**Solution:**
Before calling `get_total_due`, verify the partner still exists in the database.

Related Community PR:- https://github.com/odoo/odoo/pull/219809

opw-4897814

Forward-Port-Of: odoo/enterprise#90596

Currently, a partner can be deleted even if they have associated PoS orders.
This causes inconsistent behavior, such as missing record tracebacks 
when reopening a PoS session.

**To reproduce this issue:**

1) Install point_of_sale and pos_settle_due.
2) Open a PoS session
3) Create a customer and place an order with payment. 
4) Without closing the session, go to the backend. 
5) Delete the customer from Contacts.
6) Reopen the previously opened PoS session.

**Error:-**
A `missing record` exception is triggered.

**Cause:**

- Starting from SaaS-18.1, PoS supports offline mode with limited functionality, due to this commit:
https://github.com/odoo/odoo/pull/184417/commits/711e248efd54500f91acfb1b9a30f48177c34925

- Before this commit, data was reloaded whenever a session was opened or reopened, 
ensuring proper synchronization with the backend.

- After this commit, IndexedDB is used to cache data and it is reused every time the session is reopened.

- When the user reopens a PoS session after deleting a partner, the method 
`setAllTotalDueOfPartners` is triggered during setup.

- This method makes an RPC call to `get_all_total_due` to update all partners due amounts.
Since the partner was deleted, this causes a missing record exception.

**Solution:**

- Prevent users from deleting a partner who has PoS orders and an open session. 
- Before calling `get_total_due`, verify the partner still exists in the database.

Related Enterprise PR:- https://github.com/odoo/enterprise/pull/90596

opw-4897814

Forward-Port-Of: odoo/odoo#219809

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#98508
Forward-Port-Of: odoo/enterprise#94660

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

Forward-Port-Of: odoo/odoo#233740

### 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#98022
Forward-Port-Of: odoo/enterprise#97526

### Issue:
Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled.

This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list.

`companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3.

### Solution:
A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies.  Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed.

opw-4880477

Forward-Port-Of: odoo/odoo#228438
Forward-Port-Of: odoo/odoo#217001

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

Steps to reproduce the current behaviour:

- Update the DEMO user to be a website "restricted editor" and sales
"admin" who cannot bypass HTML field sanitization.

- As ADMIN, add a YouTube video to a product page > Save.

- As DEMO, try to update the content on the product page > You cannot
(a dialog informs you that you cannot edit the content because an admin
edited it previously).

Explanation:

Starting from [1], an HTML field can be flagged as `sanitize_overridable`
which allowed users with the `base.group_sanitize_override` group to
skip the HTML field sanitize process.

If such users added some content that is not considered "sanitize
friendly" (e.g. YouTube iframe), a restricted user won't be allowed to
add content in the fields, since the sanitizer will remove the original
content from the DOM.

For this case, the code from [2] added an implementation to consider the
field as none editable and warn the user once he tries to update it.

Implementation:

The goal of this commit it to fix the current limitation for video
upload that currently prevents non admin users to edit a website record
once an admin adds a video on it...

The idea of the fix is the following:

- We already have a technical fallback when uploading a video to save
the iframe `src` to an attribute: `data-oe-expression`.
- The public widget is now destroying the video iframes so they are
never saved in the DOM.
- A non-lazy code will build the iframes immediately on page load.
- The public widget can always create the iframes if they are not
already created (for compatibility).

[1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c
[2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6

task-3757205

Forward-Port-Of: odoo/odoo#232871
Forward-Port-Of: odoo/odoo#175717

```
  File /home/odoo/src/odoo/saas-18.4/addons/website_sale_product_feed/models/product_feed.py, line 105, in _check_product_limit
    raise ValidationError(feed.env._(
odoo.exceptions.ValidationError: A single feed cannot contain more than 5,000 products. Please separate products with Categories.
```
```
(Pdb) feed.env['product.product'].search_count(feed._get_feed_product_domain())
12433
```
During migration I am getting the traceback mentioned above, which is occurring because [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/__init__.py#L14) we have populated feed records in _post_init_hook which will create feed records without any [category ID](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/website.py#L21) because of which, [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/product_feed.py#L101) we get all records without a category, which is of course higher than our soft limit of 5000, and a validation error occurs: the customer database does not have GMC enabled. Still, it calls _populate_product_feeds, which is why I have moved it to a condition.

opw-5180407

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

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

### 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#98022
Forward-Port-Of: odoo/enterprise#97526

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

Behavior before:
When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors.

Behavior after:
Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets.

Root cause:
The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation.

Benchmark:

| Period size (journal items)  | Before patch   | After patch   |
|----------------------------------------|----------------------|--------------------|
| ~15k                                        | 7s                      | 5s                   |
| ~200k+                                    | Timeout error| 21s                 |


opw-5046077

Forward-Port-Of: odoo/enterprise#97660
Forward-Port-Of: odoo/enterprise#95047

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

Forward-Port-Of: odoo/odoo#233740

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

### 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#98022
Forward-Port-Of: odoo/enterprise#97526

**Steps to reproduce:**
1. Install the module `project_timesheet_forecast_sale`.
2. Go to Project > Configuration > Projects and open any project.
3. Go to Dashboard, click the "Timesheets and Planning" button.

**Issue:**
- Opening the "Timesheets and Planning" view raised the following error:
     `TypeError: Cannot read properties of undefined (reading 'length')`

**Cause:**
- Error caused by [method](https://github.com/odoo/odoo/blob/5be6ef1ae3958a25e680f5fa30824fec57d63efe/addons/web/static/src/views/pivot/pivot_renderer.js#L107-L109), occurred because the `planned_costs` and `effective_costs` fields are float fields but were declared with `widget="monetary"` in the pivot view. Since these fields use `format_type="monetary"` and have no corresponding `currency_field`, the pivot renderer failed to resolve currency mappings (`currency_ids` was undefined) and crashed.

**Solution:**
- Removed the `widget="monetary"` attribute from the `planned_costs` and `effective_costs` fields in the pivot view so they are treated as numeric measures instead of monetary ones.

**opw-5179265**

**Steps to reproduce:**
1. Install the module `project_timesheet_forecast_sale`.
2. Go to Project > Configuration > Projects and open any project.
3. On the project's dashboard, click the Dashboard stat button.
4. In the stats dialog, click "Timesheets and Planning".

**Issue:**
- Opening the Timesheets and Planning stat button from a Project dashboard (after installing `project_timesheet_forecast_sale`) raises the following error:

    TypeError: Cannot read properties of undefined (reading 'length')

**Cause:**
- The method _getCellCurrency() expected every dataset to have corresponding currencyIds, but the Timesheet/Forecast report does not include any currency information in its configuration data.
As a result, config.data.currencyIds[key] was empty, leading to the crash when trying to access .length.

**Solution:**
- Handle missing currencyIds in _getCellCurrency() by checking for an empty or undefined entry before accessing it.
If no currency is defined (as is the case for timesheet/forecast reports), the method now simply returns.

**opw-5179265**

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

### Summary

Previously, when a user attempted to **register as a Peppol receiver** while already registered through a different Odoo database, the system would raise a **User Error**.  
The user had to **manually deregister** and **re-register** from the desired database.

---

### New Behavior (After This Commit)

With this update:
- The system **detects existing Peppol registrations** across databases.  
- Instead of raising an error, it now **sends an automated email** to the user with a **secure transfer link**.  
- This allows the user to **migrate their Peppol connection** to the current database seamlessly.

---
###  Flow Overview

```text
            ┌────────────────────────────┐
            │  User initiates Peppol     │
            │  registration (becomes     │
            │  sender)                   │
            └────────────┬───────────────┘
                         │
                         ▼
          ┌──────────────────────────────┐
          │  Check existing registration  │
          └────────────┬─────────────────┘
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
┌─────────────────────┐       ┌──────────────────────────────┐
│ User NOT registered │       │ User ALREADY registered      |
│ in any Odoo DB      │       
└────────────┬────────┘       └──────────────┬───────────────┘
             │                               │
             ▼                               ▼
 ┌──────────────────────────┐      ┌──────────────────────────────┐
 │ Proceed with normal      │      │ Send email with transfer link│
 │ registration flow        │      │ to the user                  │
 └──────────────────────────┘      └──────────────┬───────────────┘
                                                  │
                                                  ▼
                                     ┌──────────────────────────────┐
                                     │ User clicks transfer link    
                                     │                                                                              
                                     └──────────────┬───────────────┘
                                                    │
                                                    ▼
                                     ┌──────────────────────────────┐
                                     │ Peppol connection migrated 
                                     └──────────────────────────────┘


```
---
iap pr- https://github.com/odoo/iap-apps/pull/1236
task- 5023252

Versions
--------
18.0+

Issue
-----
The `test_website_sale_add_and_remove_main_product_image_no_variant` and `test_website_sale_remove_main_product_image_with_variant` tours fail because the main product image is not removed as expected after the tour completes.

Cause
-----
Both tours assume that once the product `<img>` element is removed from the DOM, the action is fully completed. The tour then ends, and the remaining Python code verifies the result. However, this assumption can lead to issues. If the save request takes longer than expected, the Python code may execute prematurely and fail.

Solution
--------
Add a step at the end of both tours to wait for the `<img>` element to be fully saved and updated in the preview DOM.

Additionally, during debugging, it was observed that using an alias URL (i.e., a redirect) to an `ir.attachment` could introduce further issues or slow down the test due to the server fetching the image with a remote call. To address this, this commit replaces the alias URL with a simple binary attachment.

opw-5159593
runbot-163025
runbot-163615

**PROBLEM**
Internal users can access the documents of a private project even when they are not followers of the project. They shouldn't.

**STEP TO REPRODUCE**
1. Create a project, and set its visibility to Invited internal users (private), and upload a document to the project folder.
2. Switch to a user that is not a follower of the project, but is a user of the document app.
3. Go to the documents app, and notice you have access to files in the private project folder.

**CAUSE**
1. When creating the project folder, we don't specify `access_ids`, which means it will copy the `access_ids` of the folder above it. If a user have access to the "Project" folder, they will have access to any sub-folder ("Project" folder is the default parent folder of the any project folder).
2. `is_access_via_link_hidden` is by default set to False, which means the project folder is visible to anyone who has access to its parent folder.

**FIX**
1. Don't copy `access_ids` from the parent folder.
2. If project visibility is private, `is_access_via_link_hidden` is set to True.
3. To give access to the folder to the followers of the project, update the `access_ids` of the project folder and documents when add/removing followers.

opw-4791346

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

Issue
-----
Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML.

Steps to reproduce
-----
- Create a subcontracted product with 2 components
- Add one of each component in subcontractor's stock
- Create a PO for the finished product and confirm it
- Go to the production
- Open the "Record components" wizard
- Set quantity then remove the second line
- Confirm production (don't update consumption)
- Go to Inventory > Reporting > Moves History and remove the "Done" filter

> There is a pending move in the report

Cause
-----
When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method

https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46

The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do

`move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])`

we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db.

https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322

We cannot change the field to `ondelete='cascade'` as such a change would not be stable.

Solution
-----
Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated.

-----
Ticket:
opw-4817397

Forward-Port-Of: odoo/odoo#229310

Issue
-----
When providing multiple SN on the reception form, only the first one is used for the original production, the backorders SN are instead automatically generated.

Steps to reproduce
-----
- Create a subcontracted produt tracked by serial number
- Create a purchase for 2 units of the subcontracted product & confirm
- Open reception and create 2 SNs for the product & save the form

> Only the first SN is used, the second got replaced by a generated one

Cause
-----
When saving the form, we write on both the SM's `quantity` and `lot_ids`. This triggers the inverse `set_lot_ids` which updates the SMLs accordingly

https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/stock/models/stock_move.py#L560

But after `lot_ids` inverse, we trigger the `quantity` one, which calls the move's `_auto_record_components`

https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp_subcontracting/models/stock_move.py#L85

where we split the production.

https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp_subcontracting/models/stock_move.py#L97-L101

The production is split into N productions for a single unit of the product (because the `lot_producing_id` field of the MO is a many2one, see

https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp/models/mrp_production.py#L78-L80

Once the production has been split, a `lot_producing_id` is assigned to the backorder productions by calling `action_generate_serial`.

https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp_subcontracting/models/stock_move.py#L103-L106

We could instead assign the unused ids in the SM's `lot_ids` to the backorder productions.

-----
Ticket:
opw-5003930