Versions -------- - 18.0+ Feature doesn't exist in earlier versions. Steps ----- 1. Create a product with a tag; 2. create another product with a different tag; 3. create a delivery method with these 2 tags as Must Have Tags; 4. add one product to the cart in eCommerce; 5. go to checkout. Issue ----- Delivery method isn't available for selection. Cause ----- While the "Must Have Tags" description states that the method should be available if at least one product on the or

Versions
--------
- 18.0+

Feature doesn't exist in earlier versions.

Steps
-----
1. Create a product with a tag;
2. create another product with a different tag;
3. create a delivery method with these 2 tags as Must Have Tags;
4. add one product to the cart in eCommerce;
5. go to checkout.

Issue
-----
Delivery method isn't available for selection.

Cause
-----
While the "Must Have Tags" description states that the method should be available if at least one product on the order has at least one of these tags, the `_match_must_have_tags` method requires *all* of the `must_have_tags` to be present in the order.

Solution
--------
Instead of using `all`, use `any` when matching must-have tags.

opw-4836137

Forward-Port-Of: odoo/odoo#214312

In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214035

In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed.

no-task

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

Forward-Port-Of: odoo/odoo#214035

Steps to reproduce: - add a property on Tasks - open a pivot view - group by this property - insert in spreadsheet => boom The pivot cannot be loaded because the property is not a real field. Hence it's not loaded by `fields_get` and we are missing the property metadata (type) We need to load the definition independently and we push it to the fields. It's a hack but it seems to work. opw-4858129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su

Steps to reproduce:
- add a property on Tasks
- open a pivot view
- group by this property
- insert in spreadsheet

=> boom

The pivot cannot be loaded because the property is not a real field. Hence it's not loaded by `fields_get` and we are missing the property metadata (type)
We need to load the definition independently and we push it to the fields. It's a hack but it seems to work.

opw-4858129


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

Forward-Port-Of: odoo/odoo#213832

Steps to Reproduce: - Install `website_sale_stock` and enable the Reorder from portal feature. - Place an order from `/shop` that includes one or more combo products. - Navigate to `/my/orders` and attempt to reorder the same. - Combo products are broken into separate lines rather than shown as a single combo. - Stock information for the combo is not available, as the items are treated independently. Issue: - Combo products are displayed as separate lines in reorder modal - Also stock

Steps to Reproduce:
- Install `website_sale_stock` and enable the Reorder from portal feature.
- Place an order from `/shop` that includes one or more combo products.
- Navigate to `/my/orders` and attempt to reorder the same.
- Combo products are broken into separate lines rather than shown as a single combo.
- Stock information for the combo is not available, as the items are treated independently.

Issue:
- Combo products are displayed as separate lines in reorder modal
- Also stock management of combo products is not there

Cause:
- The `/my/orders/reorder_modal_content` controller route lacks logic to handle combo products. The reorder modal builds the cart lines assuming all items are standalone, disregarding combo grouping and related stock aggregation.

Solution:
- Extend the `/my/orders/reorder_modal_content` route logic to correctly identify and process combo products as single bundled entities.
- Update the reorder modal in `website_sale_stock` to incorporate combo-specific stock handling, ensuring accurate availability feedback for the entire combo.
- This ensures that the reorder experience mirrors the original order composition and improves stock visibility for bundled products.

opw-4731014
Affected Version-18.0

Forward-Port-Of: odoo/odoo#209234

When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number. This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows. However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via

When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number.

This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows.

However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via API or automation), bypassing the form view validation.

This commit updates the condition in `_action_done()` to check the context key `is_scrap`, which is already passed in `do_scrap()` via `move.with_context(is_scrap=True)._action_done()`.

This allows tracked products to be scrapped without a lot in valid scenarios, without misleadingly assigning a `picking_type_id` to the move.


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

Forward-Port-Of: odoo/odoo#213536
Forward-Port-Of: odoo/odoo#206900

This commit update the finished move quantity of a production of a serial tracked product to 1 when set the quantity producing (always to 1 in case of a serial tracked product) This is mainly mandatory in case the production need to process quality checks. Task : 4575193 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This commit update the finished move quantity of a production of a serial tracked product to 1 when set the quantity producing (always to 1 in case of a serial tracked product) This is mainly mandatory in case the production need to process quality checks.

Task : 4575193

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#206109

### Description: Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues. ### Fix: `_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM. A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_

### Description:

Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues.

### Fix:

`_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM.

A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_log_activity_get_documents`.

Also, a bug in `_action_cancel` was calling a filtering on`self`, rather than `production`, and that for each production, which was degrading the performance.

### Benchmark:

| N° of MO | Before | After |
|----------|--------|-------|
|       80 |    15s |    1s |
|      160 |    33s |    2s |
|     1000 |   2:52 |    8s |

### Reference:

opw-4734710

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

Forward-Port-Of: odoo/odoo#214347
Forward-Port-Of: odoo/odoo#207960

The test `test_website_event_tour_admin` fails randomly depending on the processing speed available. When clicking on `a[title='Back to All Events']`, if the website happens to still be in edit mode, the click will be prevented: https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438 We can use the clickOnSave function made specifically for this. It ensures exiting edit mode before continuing. --- runbot-223022 Fo

The test `test_website_event_tour_admin` fails randomly depending on the
processing speed available.
When clicking on `a[title='Back to All Events']`, if the website
happens to still be in edit mode, the click will be prevented: 
https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438
We can use the clickOnSave function made specifically for this.
It ensures exiting edit mode before continuing.

---

runbot-223022

Forward-Port-Of: odoo/odoo#211221

to_reproduce: --- 1. Create a combo product (no company set) 2. Create a combo choice (no company set) 3. Add a product with company restrictions 4. Multi-company error appears: "Incompatible companies on records" 5. Set company on combo choice and product template - error resolves 6. Remove company from both combo choice and combo product template 7. Save succeeds despite invalid company configuration problem: --- - During combo choice updates, only the modified combo items are inc

to_reproduce:
---
1. Create a combo product (no company set)
2. Create a combo choice (no company set)
3. Add a product with company restrictions
4. Multi-company error appears: "Incompatible companies on records"
5. Set company on combo choice and product template - error resolves
6. Remove company from both combo choice and combo product template
7. Save succeeds despite invalid company configuration

problem:
---
- During combo choice updates, only the modified combo items are included in vals['combo_item_ids'], while existing unchanged combo items are not added to the validation scope.
 https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L68
- The company validation logic only checks items present in the vals,  missing the existing combo items that should also be validated for company consistency.
https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L1092

solution:
---
- Add another check on combo items

opw-4844678

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

Forward-Port-Of: odoo/odoo#213615

Forward-Port-Of: odoo/odoo#214247 Forward-Port-Of: odoo/odoo#208639

Forward-Port-Of: odoo/odoo#214247
Forward-Port-Of: odoo/odoo#208639

Since the edited page is within an iframe, the built-in fonts used by the wysiwyg are also loaded inside the page within the iframe, which causes them to replace the one used when viewing the page as a visitor if it happens to be one of the fallback fonts. This commit avoids that by giving a distinct `font-family` to the fonts used by the wysiwyg. task-3080104 Forward-Port-Of: odoo/odoo#214128 Forward-Port-Of: odoo/odoo#112759

Since the edited page is within an iframe, the built-in fonts used by the wysiwyg are also loaded inside the page within the iframe, which causes them to replace the one used when viewing the page as a visitor if it happens to be one of the fallback fonts.

This commit avoids that by giving a distinct `font-family` to the fonts used by the wysiwyg.

task-3080104

Forward-Port-Of: odoo/odoo#214128
Forward-Port-Of: odoo/odoo#112759

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1 with a BoM that includes: - Component 1 (sequence = 1) - Component 2 - KIT (sequence = 2), which itself contains: - Component 2-1 (sequence = 1) - Component 2-2 (sequence = 2) - Component 3 (sequence = 3) - Create a Manufacturing Order for P1. Observed behavior: - The

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.

Steps to reproduce:
- Create a product P1 with a BoM that includes:
  - Component 1 (sequence = 1)
  - Component 2 - KIT (sequence = 2), which itself contains:
      - Component 2-1 (sequence = 1)
      - Component 2-2 (sequence = 2)
  - Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.

Observed behavior:
- The generated stock moves are ordered as:
    1. Component 1
    2. Component 3
    3. Component 2-1
    4. Component 2-2

Expected behavior:
- The stock moves should respect the BoM line sequence:
    1. Component 1
    2. Component 2-1
    3. Component 2-2
    4. Component 3

Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430

Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.

opw-4809095

Forward-Port-Of: odoo/odoo#212761

### Steps to reproduce: - Insert an image into the editor. - Open the Transformation controls for the image. - Press the `Backspace` key to delete the image. - The transformation overlay remains visible after the image is removed. ### Description of the issue/feature this PR addresses: - In commit [1](https://github.com/odoo/odoo/commit/85698bf4f591fc9280f054b9a255a7d5ff4d1fe2), the `image_transform_button` component unmounted before `selectionchange` event could fire. As a result,

### Steps to reproduce:

- Insert an image into the editor.
- Open the Transformation controls for the image.
- Press the `Backspace` key to delete the image.
- The transformation overlay remains visible after the image is removed.

### Description of the issue/feature this PR addresses:

- In commit [1](https://github.com/odoo/odoo/commit/85698bf4f591fc9280f054b9a255a7d5ff4d1fe2), the `image_transform_button` component unmounted before `selectionchange` event could fire.  As a result, event listener was removed, and the transform container was not closed when the image was deleted.

Desired behavior after PR is merged:

- The `selectionchange` listener is now attached within the `image_transformation` component.
- A `keydown` listener is also added to explicitly handle Backspace and Delete keys, addressing the case where Chrome does not trigger `selectionchange` on image deletion.

task-4831728

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

Forward-Port-Of: odoo/odoo#212715

Steps to reproduce: - Enter website edit mode. - Click the header. - Select "Sidebar" in the template options. - Save the page. - Click Site > Menu Editor in the backend navbar. - Add a "Mega menu" to the menu and save the dialog. - In the sidebar, open the "Mega menu". - Bug: The layout is broken. The mega menu should be displayed in a single column, but it's displayed in three columns. In this commit, we fix the issue by forcing the columns width of the mega menu to 100% when the

Steps to reproduce:

- Enter website edit mode.
- Click the header.
- Select "Sidebar" in the template options.
- Save the page.
- Click Site > Menu Editor in the backend navbar.
- Add a "Mega menu" to the menu and save the dialog.
- In the sidebar, open the "Mega menu".
- Bug: The layout is broken. The mega menu should be displayed in a single column, but it's displayed in three columns.

In this commit, we fix the issue by forcing the columns width of the mega menu to 100% when the header is set to "Sidebar" or "Hamburger".

This commit also hides the "Size" option of the mega menu when the header template is set to "hamburger" or "sidebar", as it has no effect with either of these headers.

task-4830118

Forward-Port-Of: odoo/odoo#212752

This commit adds the the unit e.g. 'kg' to each orderline next to the quantity. The reason for this change was to satisfy the requirements of the LNE to allow Odoo to be certified for weighing scales in the EU. task-4869128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214335

This commit adds the the unit e.g. 'kg' to each orderline next to the quantity. The reason for this change was to satisfy the requirements of the LNE to allow Odoo to be certified for weighing scales in the EU.

task-4869128

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

Forward-Port-Of: odoo/odoo#214335

There are several flows where the persona of a member might not (or no longer) be known in JS. These members should simply be ignored when computing the correspondent of a channel rather than crashing. Forward-Port-Of: odoo/odoo#214395

There are several flows where the persona of a member might not (or no longer) be known in JS. These members should simply be ignored when computing the correspondent of a channel rather than crashing.

Forward-Port-Of: odoo/odoo#214395

Adds a test to ensure the Sales Details report computes the correct total base amount when products with multiple taxes are sold. This test covers a previously incorrect behavior where the base amount was summed multiple times for products with multiple tax lines, leading to inflated totals. Now, the report uses the accurate tax-excluded total to avoid duplication. Opw-4670643. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: o

Adds a test to ensure the Sales Details report computes the correct total base amount
when products with multiple taxes are sold.

This test covers a previously incorrect behavior where the base amount was summed
multiple times for products with multiple tax lines, leading to inflated totals.
Now, the report uses the accurate tax-excluded total to avoid duplication.

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

Forward-Port-Of: odoo/odoo#212377
Forward-Port-Of: odoo/odoo#203289

This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c and flatten the background color of the body element instead. Scenario: - set a color to the body different than white - add snippets to have a height higher than the viewport - go down in the page Result: the background color is only set up to the viewport height. Cause: Before 18.0, the body takes 100% of the page height because we are scrolling over the #wrapwrap element. In 18.0 with 189a7c96e6e26825d

This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c
and flatten the background color of the body element instead.

Scenario:
- set a color to the body different than white
- add snippets to have a height higher than the viewport
- go down in the page

Result: the background color is only set up to the viewport height.

Cause:

Before 18.0, the body takes 100% of the page height because we are scrolling
over the #wrapwrap element.

In 18.0 with 189a7c96e6e26825dc05c0c6466576fe63aa091e, we are scrolling
over the body element, that combined with the body having a height of
100%  makes the body element being positionned from 0 to viewport height,
and it's not present below that.

Also to set background of the whole page, the browser uses the body
background if there is no background on the html element, so even if the
body didn't cover the whole page, we were getting the body color on the
whole page.

So the change in 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c that set the
html element to white, causes the background color to only be applied to
up to the viewport height, with the background being blank below that.

Fix: set the body background color to the flattened rgb color.

opw-4863179
opw-4863724

Forward-Port-Of: odoo/odoo#214379
Forward-Port-Of: odoo/odoo#213858

The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries, cooperatives, consignees, exporters, brokers and future market operators. This document is emitted by the intermediary of the operation so, in Odoo, if the user is the seller or purchaser of the operation, it will need to register that document in a sale or purchase journal accordingly. This PR aims to incl

The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries, cooperatives, consignees, exporters, brokers and future market operators. This document is emitted by the intermediary of the operation so, in Odoo, if the user is the seller or purchaser of the operation, it will need to register that document in a sale or purchase journal accordingly.
This PR aims to include this document in the list of the available ones to allow the user to select it when registering either a sale or a purchase. 
![image](https://github.com/user-attachments/assets/cd257bb9-8337-46c0-a699-7ed973338ac7)

**Behaviour before this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 - SECONDARY GRAIN LIQUIDATION" is not available to select, although it is activated.

**Behaviour after this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 -SECONDARY GRAIN LIQUIDATION" is appears in the list of documents (the document type should be activated before)

**Steps to reproduce:**

1. Install l10n_ar
2. Go to "Document Types" menu and activate "331 - SECONDARY GRAIN LIQUIDATION" 
3. Create or use a sale or purchase journal that has "Is AFIP POS?" as False.
4. Create an invoice in that journal and check that the document type with code 331 is not available to select.
 
![image](https://github.com/user-attachments/assets/710ac57c-8f2c-4398-88c7-ef8c3c8581f3)


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

Forward-Port-Of: odoo/odoo#211737

<b>Steps to Reproduce:</b> 1. Navigate to Sales → Products → Products. 2. Click on Print Labels. 3. Select label format 2×7. 4. Add an image to the "Extra Content" field (e.g., by typing `/image`). <b>Issue:</b> - When printing labels, the image added via `extra_html` is not fully displayed. It gets cut off due to the fixed height and overflow settings on the `.o_label_extra_data` container. <b>Solution:</b> - Added responsive styling to o_label_extra_data for img so they resize pr

<b>Steps to Reproduce:</b>
1. Navigate to Sales → Products → Products.
2. Click on Print Labels.
3. Select label format 2×7.
4. Add an image to the "Extra Content" field (e.g., by typing `/image`).

<b>Issue:</b>
- When printing labels, the image added via `extra_html` is not fully displayed. It gets cut off due to the fixed height and overflow settings on the
 `.o_label_extra_data` container.

<b>Solution:</b>
- Added responsive styling to o_label_extra_data for img so they resize properly and stay within bounds:

    ```css
    .img {
        max-height: 2.5em;
        max-width: 100%;
    }
    ```
ensures image appear without being cropped.

<b>opw-4741550</b>


Before FIX:
![image](https://github.com/user-attachments/assets/c914571e-6e08-4bb4-b05e-e1c027ed7a5e)
After FIX:
![image](https://github.com/user-attachments/assets/3f8ac94c-a128-418d-88cb-ab4f078c848d)

Forward-Port-Of: odoo/odoo#212903

If the automatic check out and absence managment settings in attendance are set, it will not take into account the employees that have a flexible working schedule. These settings were not compatible with the notion of flexibility in hours. Backport of https://github.com/odoo/odoo/pull/196822 task-4816736 Forward-Port-Of: odoo/odoo#211461

If the automatic check out and absence managment settings in attendance are set, it will not take into account the employees that have a flexible working schedule.

These settings were not compatible with the notion of flexibility in hours.

Backport of https://github.com/odoo/odoo/pull/196822

task-4816736

Forward-Port-Of: odoo/odoo#211461

Check that the menu actually exists before adding it to the results. Also don't raise error if not found. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212555

Check that the menu actually exists before adding it to the results. Also don't raise error if not found.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#212555

not reproducible but keeping test. opw-4782062 Forward-Port-Of: odoo/enterprise#87301

not reproducible but keeping test.

opw-4782062

Forward-Port-Of: odoo/enterprise#87301

opw-4772870 opw-4664501 Forward-Port-Of: odoo/enterprise#87774 Forward-Port-Of: odoo/enterprise#86891

opw-4772870
opw-4664501

Forward-Port-Of: odoo/enterprise#87774
Forward-Port-Of: odoo/enterprise#86891

Steps to reproduce: 1. Install the german localization 2. Create company in DE 3. Create a partner that has country = PL 4. Create a customer invoice for the PL partner 5. Open: Accounting > Reporting > EC Sales List 6. Hit the wheel and create the CSV export. 7. Open the file Issue: see that the amount is a float Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4575788) opw-4575788 Forward-Port-Of: odoo/enterprise#87421 Forward-Port-Of: odoo/enterprise#83822

Steps to reproduce:
1. Install the german localization
2. Create company in DE
3. Create a partner that has country = PL
4. Create a customer invoice for the PL partner
5. Open: Accounting > Reporting > EC Sales List
6. Hit the wheel and create the CSV export.
7. Open the file

Issue:
see that the amount is a float

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4575788)
opw-4575788

Forward-Port-Of: odoo/enterprise#87421
Forward-Port-Of: odoo/enterprise#83822

Before this commit, we had the capability to view the current scale checksum by visiting `/scale_checksum`, but no way to automatically flag to the user if it had changed. After this commit, we keep track of the expected checksum and compare it to the current checksum. If they differ, the POS is no longer certified and we show an error to the user. task-4873162 Forward-Port-Of: odoo/enterprise#87726

Before this commit, we had the capability to view the current scale checksum by visiting `/scale_checksum`, but no way to automatically flag to the user if it had changed.

After this commit, we keep track of the expected checksum and compare it to the current checksum. If they differ, the POS is no longer certified and we show an error to the user.

task-4873162

Forward-Port-Of: odoo/enterprise#87726

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1 with a BoM that includes: - Component 1 (sequence = 1) - Component 2 - KIT (sequence = 2), which itself contains: - Component 2-1 (sequence = 1) - Component 2-2 (sequence = 2) - Component 3 (sequence = 3) - Create a Manufacturing Order for P1. Observed behavior: - The

When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.

Steps to reproduce:
- Create a product P1 with a BoM that includes:
  - Component 1 (sequence = 1)
  - Component 2 - KIT (sequence = 2), which itself contains:
      - Component 2-1 (sequence = 1)
      - Component 2-2 (sequence = 2)
  - Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.

Observed behavior:
- The generated stock moves are ordered as:
    1. Component 1
    2. Component 3
    3. Component 2-1
    4. Component 2-2

Expected behavior:
- The stock moves should respect the BoM line sequence:
    1. Component 1
    2. Component 2-1
    3. Component 2-2
    4. Component 3

Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418

https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430

Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.

opw-4809095

Forward-Port-Of: odoo/enterprise#87003

Users can upload request documents from the kanban and the activity views. This commit extends this feature to the list view. task-4745800 Forward-Port-Of: odoo/enterprise#84518

Users can upload request documents from the kanban and the activity views. 
This commit extends this feature to the list view.

task-4745800

Forward-Port-Of: odoo/enterprise#84518

Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration o

Problem
---------
Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...)

One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default.

But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed.

Objective
---------
Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level.

Solution
---------
Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default).

task-4574971

Forward-Port-Of: odoo/enterprise#80116

In case of 'quantity' control per quality point. If a complete stock move line is sent to a failure location. The stock move was not split. We could have a stock move line going to a location that is not child of the location of the corresponding move. This can lead issues in case of push_rules or stock valuation. Task: 4575193 Forward-Port-Of: odoo/enterprise#81275

In case of 'quantity' control per quality point. If a complete stock move line is sent to a failure location. The stock move was not split. We could have a stock move line going to a location that is not child of the location of the corresponding move. This can lead issues in case of push_rules or stock valuation.

Task: 4575193

Forward-Port-Of: odoo/enterprise#81275

Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery order with one unit of P1, not linked to any sale order - Go to the delivery order list view - Select the created delivery order - Click on Action → Fetch shipping label Problem: A traceback is triggered: ``` ValueError: ValueError('Expected singleton: shopee.shop()') while evaluating 'records._fetch_shipment_label()' The above server error caused the following client error: ``` The `_fetch_s

Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery order with one unit of P1, not linked to any sale order
- Go to the delivery order list view
- Select the created delivery order
- Click on Action → Fetch shipping label

Problem:
A traceback is triggered:

```
ValueError: ValueError('Expected singleton: shopee.shop()') while
evaluating
'records._fetch_shipment_label()'

The above server error caused the following client error:

```

The `_fetch_shipment_label` function expects at least one item, but
we don't check it via a user error, because we're supposed to call
`_sync_shopee_pickings` instead, where all these filtering and checks
are done


opw-4812360

Forward-Port-Of: odoo/enterprise#86442

Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction. Root Cause: The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises a lock error based on the permanent date. Additionally, the hard lock dat

Current behavior before commit:

When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction.

Root Cause:

The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises
a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored.

Fix:

Replaced the direct lock date check with _get_lock_date_violations(), which:

- Correctly considers user-specific temporary lock date exceptions.

- Returns violations based on effective lock rules (including hard lock).

- Provides a more generic error message.

Steps to reproduce:

- Use a tax report with carryover values (e.g. Belgian VAT return, line 81).

- Post a refund using a tax that maps to the carryover (e.g. 21% M).

- Generate a closing entry.

- Set the company’s tax_lock_date to a date covering the refund.

- Grant a temporary lock date exception to the user, covering the same date.

- Try to reset the closing entry → Lock date error is raised (incorrectly).

opw-4715100

Forward-Port-Of: odoo/enterprise#85337

This commit introduces two improvements to the 'Add Properties' button in the cog menu of the Asset model: 1. Hides the button if the record has state = 'model'. Previously, the button was available but no action was triggered. 2. Raises an error message if the button 'Add Properties' is clicked in an asset without an asset model associated. Previously, only a warning with the unclear message "You need edit access on the parent doument to update these property fields" was shown. task-482209

This commit introduces two improvements to the 'Add Properties' button in the cog menu of the Asset model:
1. Hides the button if the record has state = 'model'. Previously, the button was available but no action was triggered.
2. Raises an error message if the button 'Add Properties' is clicked in an asset without an asset model associated. Previously, only a warning with the unclear message "You need edit access on the parent doument to update these property fields" was shown.

task-4822091

Forward-Port-Of: odoo/enterprise#86651

When generating the accounting entry from the Corporate Tax Report, the system first tries to find a miscellaneous journal with the short code `MISC`. If this specific journal does not exist, the logic attempts to fall back and find any other journal of type 'Miscellaneous' (`type = 'general'`). However, this fallback search fails with an error due to an incorrect search domain syntax. Steps to reproduce: 1. Go to Accounting > Configuration > Journals. 2. Ensure no journal exists with th

When generating the accounting entry from the Corporate Tax Report, the system first tries to find a miscellaneous journal with the short code `MISC`.

If this specific journal does not exist, the logic attempts to fall back and find any other journal of type 'Miscellaneous' (`type = 'general'`). However, this fallback search fails with an error due to an incorrect search domain syntax.

Steps to reproduce:
1. Go to Accounting > Configuration > Journals.
2. Ensure no journal exists with the short code MISC.
3. Ensure at least one other journal of type "Miscellaneous" exists (for example, with short code GEN or MSC).
4. Go to Accounting > Reporting > Corporate Tax Report.
5. Try to generate the accounting entry.

opw-4836686

Forward-Port-Of: odoo/enterprise#87300

Currently, a raceback occurs when the user changes or adds the expression label of the column in the "Generic Tax report". **To reproduce this issue:** 1) Install "account_reports" 2) Open "Generic Tax report" from "Accounting Reports" 3) In columns change the "Expression Label" and save the record 4) Open the "Tax Report" in "Reporting" 5) A traceback occurs **Error:** ``` UnboundLocalError: local variable 'col_value' referenced before assignment ``` **Cause:** The "co

Currently, a raceback occurs when the user changes or adds the expression label 
of the column in the "Generic Tax report".

**To reproduce this issue:**

1) Install "account_reports"
2) Open "Generic Tax report" from "Accounting Reports" 
3) In columns change the "Expression Label" and save the record 
4) Open the "Tax Report" in "Reporting"
5) A traceback occurs

**Error:**

```
UnboundLocalError: local variable 'col_value' referenced before assignment
```

**Cause:**
The "col_value" is assigned based on the "expr_label" if it doesn't match the if conditions it leads to a traceback.
https://github.com/odoo/enterprise/blob/d154cbf1bd5b4cc104ff0e2443047aff0c05330f/account_reports/models/account_generic_tax_report.py#L921-L932

**Solution:**
This commit will resolve this issue by assigning a fallback value of an empty string to col_value.

opw-4841789

Forward-Port-Of: odoo/enterprise#87277

Currently, an error is produced when the payslip start date is not set, but the end date is provided. **Steps to reproduce:** - Install `hr_payroll` module(with demo). - Create new **Payslip** for employee **Anita Oliver**. - Clear both the start and end dates under the "Period" section. - Set only the end date. **Error:** `TypeError: '<' not supported between instances of 'bool' and 'datetime.date'` **Cause:** The `_compute_warning_message` method performs a comparison between `s

Currently, an error is produced when the payslip start date is not set, but the end date is provided.

**Steps to reproduce:**
- Install `hr_payroll` module(with demo).
- Create new **Payslip** for employee **Anita Oliver**.
- Clear both the start and end dates under the "Period" section.
- Set only the end date.

**Error:**
`TypeError: '<' not supported between instances of 'bool' and 'datetime.date'`

**Cause:**
The `_compute_warning_message` method performs a comparison between `slip.date_from` and `contract_id.date_start` without verifying if `date_from` is set. When `date_from` is `False`, the comparison `False < datetime.date(...)` - [1], raises a `TypeError`.

[1] - https://github.com/odoo/enterprise/blob/a65314702b99df97c778d4f12f943191a19dafd1/hr_payroll/models/hr_payslip.py#L1029-L1031

This commit adds checks to ensure that start and end date is defined before performing date comparisons in warning message computation, preventing the error.

Sentry - 6618275041

Forward-Port-Of: odoo/enterprise#86091