Steps to reproduce the bug: - Create a storable product "P1" with a BoM. - Go to ECO stage > In Progress > add two approvals: - approval 1: Mitchel admin + Marc Demo - approval 2: Mitchel admin + Marc Demo - Navigate to PLM > BoM Update and create a new ECO: - Create a new ECO: - Type: BoM Update - Apply On: BoM - Product P1 - Start the revision - Move the ECO to In Progress. Problem: A validation error occurs: “The operation cannot be completed: Error

Steps to reproduce the bug:
- Create a storable product "P1" with a BoM.
- Go to ECO stage > In Progress > add two approvals:
    - approval 1: Mitchel admin + Marc Demo
    - approval 2: Mitchel admin + Marc Demo

- Navigate to PLM > BoM Update and create a new ECO:
- Create a new ECO:
    - Type: BoM Update
    - Apply On: BoM
    - Product P1
    - Start the revision

- Move the ECO to In Progress.

Problem:
A validation error occurs:
“The operation cannot be completed: Error, a partner cannot follow twice the same object.”

opw-4421352

Forward-Port-Of: odoo/enterprise#77252
Forward-Port-Of: odoo/enterprise#76232

Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75770

Problem
----------
The SHIF is based on the gross and not the basic.
There is no SHIF Relief

Objective
----------
Correct the SHIF implementation

Solution
----------
Get GROSS in SHIF computation rather than BASIC
Remove SHIF Relief Rule

task-4414345

Forward-Port-Of: odoo/enterprise#75770

When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#76788

When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue.

Also, the report will show a traceback.

This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue.

Forward-Port-Of: odoo/enterprise#76788

Currently, an error occurs when attempting to insert field `template_autocomplete_ids` into planning slot list view using studio mode. Step to produce: - Install the `sale_planning` and `web_studio` modules (with demo data). - Open the 'My Planning' list view. - Add the `template_autocomplete_ids` field to the list view using 'studio'. - Error generated at the backend. `ValueError: Expected singleton: planning. Slot(5, 7)` The error occurs because the system attempts to access a

Currently, an error occurs when attempting to insert field `template_autocomplete_ids`  into planning slot list view using studio mode.

Step to produce:

- Install the `sale_planning` and `web_studio` modules (with demo data).
- Open the 'My Planning' list view.
- Add the `template_autocomplete_ids` field to the list view using  'studio'.
- Error generated at the backend.

`ValueError: Expected singleton: planning. Slot(5, 7)`

The error occurs because the system attempts to access a single value of fields from multiple records at [1].

[1] - https://github.com/odoo/enterprise/blob/5a9d3be9fb65d780ce92c437600220b8a0e95023/planning/models/planning.py#L410-L414

To resolve this issue, use an iteration(for loop) to iterate records one by one.

Sentry-6217013028

Forward-Port-Of: odoo/enterprise#77318

Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718

Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it.

task-4210393

Forward-Port-Of: odoo/enterprise#70718

The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501

The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe.
It allows to debug the iframe during the development.

no task id

Forward-Port-Of: odoo/enterprise#77501

Steps: - Install sale app. - Enable Loyalty settings. - Try to create a card on a loyalty. Issue: - Giving validation error. Casue: - In [PR] forgot to check expiration_date set or not before raise an error. Fix: - Added condition to check if expiration_date set or not on card before raising an error. [PR]: https://github.com/odoo/odoo/pull/171453 opw-4492179 opw-4490587 opw-4504188 opw-4495530 Forward-Port-Of: odoo/odoo#194836 Forward-Port-Of: odoo/odoo#194785

Steps:
- Install sale app.
- Enable Loyalty settings.
- Try to create a card on a loyalty.

Issue:
- Giving validation error.

Casue:
- In [PR] forgot to check expiration_date set or not before raise an error.

Fix:
- Added condition to check if expiration_date set or not on card before raising an error.

[PR]: https://github.com/odoo/odoo/pull/171453

opw-4492179
opw-4490587
opw-4504188
opw-4495530

Forward-Port-Of: odoo/odoo#194836
Forward-Port-Of: odoo/odoo#194785

**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data

**Problem**:
When we have `<b t-field="html">`, it is rendered in the DOM as
`<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string
and parsed in the backend, the `html.fromstring` method removes the `p` from
the `b` because `b` is an inline element and cannot contain block elements.
This results in:
`<b data-oe-attr="..."></b><p>content</p>`.

Since this structure has two root elements, the parser wraps them in a block
element (`div`), generating:
`<div><b data-oe-attr="..."></b><p>content</p></div>`.

This causes a traceback when trying to access `data-oe` attributes, as they
are expected to be in the root element.

**Solution**:
Convert any `b` elements used as HTML fields to `div` elements before saving.

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

Forward-Port-Of: odoo/odoo#194872

This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185947

This commit will update some taxes:
- Update the purchase tax accounts
- Add new 0% EX tax
- Delete EX RS 20% & EX RS -20%

In the tax report:
- Change the name of the report
- Add a new record

task: 4244715




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

Forward-Port-Of: odoo/odoo#185947

Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider i

Description of the issue/feature this PR addresses:
The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider.

Current behavior before PR:
When attempting to authenticate a new user with an OAuth provider in Odoo using Python 3.12, the method werkzeug.http.parse_www_authenticate_header is called. Since this method is removed in Werkzeug 3.0.1, a misleading error message about auth_signup not being installed on the database is displayed.

Desired behavior after PR is merged:
The code will use WWWAuthenticate.from_header for parsing the WWW-Authenticate header if available, otherwise, it will fall back to using werkzeug.http.parse_www_authenticate_header for compatibility with older versions of Werkzeug (2.0 and 2.2). The misleading error message will no longer appear, and OAuth authentication will work as expected.

Fixes #194002


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

Forward-Port-Of: odoo/odoo#194484

The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#157028

The confirmation page wasn't displayed and the order wasn't sent to the
preparation display when confirming an order with a total of 0.

Now the confirmation page is displayed and the order is send to the
preparation display when the order is confirmed regardless of the total
amount.

Forward-Port-Of: odoo/odoo#157028

Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] st

Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121.

This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] starting from Odoo version 18.0). This is not compatible with the older browsers mentioned above.

The bug only appears in version 18. However, we already fixed this in 16.0 in case potential customizations had added the ":is" pseudo-class to the same selector.

[1]: https://github.com/odoo/odoo/commit/65a85009800dfa45526ebdc41d3a0a808b2e9f6d
[2]: https://github.com/odoo/odoo/commit/e0fc83760f991fa2fea39763bb2709d9e0182316

opw-4494945

Forward-Port-Of: odoo/odoo#194908
Forward-Port-Of: odoo/odoo#194676

The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmet

The `amount_untaxed` field, which is tracked,
encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned,
the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise.

I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmetic and its limitations. So what I did is checking if the new value is different than the old one then update the field.

Steps to reproduce:
1. Create a PO
2. Add a product with price 261,462.02
3. Save
4. Change the expected arrival date
5. Save See the chatter.
take a loot at the chatter.
![image](https://github.com/user-attachments/assets/a19ce09a-f02a-45a7-a02a-d044a4c1cc40)

opw-4315116



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

Forward-Port-Of: odoo/odoo#193368

Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could

Scenario:

- have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it)
- merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table

Why:

The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property.

Also a savepoint was used, without ignoring the error so the import could not be done if an error happened.

Fix:

Take the case where both records have NULL company_id into account.

Also ignore error and log a warning when a legitimate error happens because of duplicate ir.property in source records.

Note:

This issue should only happen when:

- modifying ir.property directly
- after a migration with a res.partner field becoming company_dependent field, the partners without company would get an ir.property without company_id

Without the fix, the added test would fail because of an error at each _merge call.

opw-4300572
opw-4030442

Forward-Port-Of: odoo/odoo#188673

If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994

If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid.

That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'.

opw-4460696

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

Forward-Port-Of: odoo/odoo#193994

This PR addresses an issue where selecting a video and pressing Ctrl+K would introduce a link(anchor tag) on top of the video. The fix ensures that pressing Ctrl+K while a video is focused will no longer insert a link, resolving the issue of an empty link being added. task-2819776 Forward-Port-Of: odoo/odoo#193447 Forward-Port-Of: odoo/odoo#162615

This PR addresses an issue where selecting a video and pressing Ctrl+K would introduce a link(anchor tag) on top of the video. The fix ensures that pressing Ctrl+K while a video is focused will no longer insert a link,  resolving the issue of an empty link being added.

task-2819776

Forward-Port-Of: odoo/odoo#193447
Forward-Port-Of: odoo/odoo#162615

Before this commit, loadViews didn't benefit from the "async" protection of services. Indeed, when used in a component (via useService), the promise returned by loadViews could be resolved (when the rpc returned), even if the component had been destroyed meanwhile. This could lead to code in a destroyed component being executed, and eventually doing an rpc, which would lead to the crash `Error: Component is destroyed`. This could be reproduced in a form view with an x2many field, whose form v

Before this commit, loadViews didn't benefit from the "async" protection of services. Indeed, when used in a component (via useService), the promise returned by loadViews could be resolved (when the rpc returned), even if the component had been destroyed meanwhile. This could lead to code in a destroyed component being executed, and eventually doing an rpc, which would lead to the crash `Error: Component is destroyed`.

This could be reproduced in a form view with an x2many field, whose form view isn't inline (i.e. needs to be fetched when a record is clicked). In such a form view, click on a record in the x2many, then, during the call to get_views, toggle the home menu (for instance).

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

steps: - create an attendance for one day with less worked hours than the daily hours - create another attendance for the next day with hours to compensate the previous day's missing time - got to the attendance report : you have worked overtime although that overtime was only compensating for the previous day This worked in 16.0, but got broken by the attendance refactor and the introduction of the overtime_hours field in hr.attendance. This commit fixes the computation of the field to in

steps:
- create an attendance for one day with less worked hours than the daily hours
- create another attendance for the next day with hours to compensate the previous day's missing time
- got to the attendance report : you have worked overtime although that overtime was only compensating for the previous day

This worked in 16.0, but got broken by the attendance refactor and the introduction of the overtime_hours field in hr.attendance. This commit fixes the computation of the field to include negative overtimes.

opw-4337755

Forward-Port-Of: odoo/odoo#192699

### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is m

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

- The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records

### Current behavior before PR:
- The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred

### Desired behavior after PR is merged:
- The problem has been fixed.



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

Forward-Port-Of: odoo/odoo#194338

There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825

There is already a placeholder image displayed when an image fails to load.

opw-4419565

Forward-Port-Of: odoo/odoo#194011
Forward-Port-Of: odoo/odoo#193825

Issue: If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records. This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset. Fix: We fix this by forcing active_test=False before calling search a

Issue:
If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records.

This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset.

Fix:
We fix this by forcing active_test=False before calling search and reapplying the previous context immediately after.

Closes #194311

Forward-Port-Of: odoo/odoo#194379

**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, c

**Problem:**
When editing the "Sign & Pay" modal in customer preview for a sale
order, changes are not saved due to multiple issues:
1. Saving the signature component directly results in only the
   signature UI being saved, missing the logic and props of the
   original component.
2. If the signature component is saved with other fields, it gets
   duplicated upon saving due to `<owl-component />` behavior. This
   re-renders every saved component and mounts those passed as props,
   causing duplication and breaking functionality.
   - Reference: public_component_service.js

**Solution:**
1. Hide the signature component during editing to prevent saving its
   UI-only state, preserving its logic and props.

**Steps to Reproduce:**
1. Create a sale order.
2. Click on "Customer Preview."
3. Enable edit mode.
4. Open the "Sign & Pay" modal, modify the content, and save.
   - The signature UI duplicates

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

Forward-Port-Of: odoo/odoo#187707