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#194942
Forward-Port-Of: odoo/odoo#188673

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

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

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

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

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

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#194928 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#194928
Forward-Port-Of: odoo/odoo#194785

Fixes test broken by: be23ed0 https://runbot.odoo.com/odoo/runbot.build.error/109595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193764

Fixes test broken by: be23ed0

https://runbot.odoo.com/odoo/runbot.build.error/109595

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

Forward-Port-Of: odoo/odoo#193764

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

When creating a new mass mailing from an event, the default domain retrieved when switching mailing type is missing the event id filter Steps to reproduce (mass_mailing_sms required): - Open an event with attendees - Click 'Contact Attendees' - Take note of the mailing domain - Switch Mailing Type from Email to SMS Issue: Domain is missing the event_id This does not occur when opening the form view because the default mailing domain is given via context opw-4337256 Forward-Port-

When creating a new mass mailing from an event, the default domain
retrieved when switching mailing type is missing the event id filter

Steps to reproduce (mass_mailing_sms required):
- Open an event with attendees
- Click 'Contact Attendees'
- Take note of the mailing domain
- Switch Mailing Type from Email to SMS

Issue: Domain is missing the event_id
This does not occur when opening the form view because the default
mailing domain is given via context

opw-4337256

Forward-Port-Of: odoo/odoo#194809
Forward-Port-Of: odoo/odoo#189317

Description of the issue/feature this PR addresses: Task ID: 4342267 Current behavior before PR: -Error When printing draft invoice due to unset invoice_date. -Report spacing between header & body in second page overlaps due to paperformat spacing. Due to the long address format of saudi arabia, the default paperformat header spacing and margin top are not enough to show the full address without overlapping the second and onward pages. -English labels on the exchange rate table in l1

Description of the issue/feature this PR addresses:
Task ID: 4342267

Current behavior before PR:
-Error When printing draft invoice due to unset invoice_date.

-Report spacing between header & body in second page overlaps due to paperformat spacing.
Due to the long address format of saudi arabia, the default paperformat header spacing and margin top are not enough to show the full address without overlapping the second and onward pages.

-English labels on the exchange rate table in l10n_sa_edi are translated and not shown together with the arabic labels.

-Remove unnecessary spans in xpaths

Desired behavior after PR is merged:
-Fix printing draft invoice with invoice_date as today's date

-Fix report spacing header by adding a new A4 paperformat for l10n_sa which is set as the saudi arabia companies default paper format.

-Fix exchange rate table to show both arabic and english labels and remove unnecessary translations (no longer used)

-Remove unnecessary spans in xpath.



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

Forward-Port-Of: odoo/odoo#194725
Forward-Port-Of: odoo/odoo#190172

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

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

The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpD

The idea is:

1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable.

2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpDisplay` so it doesn't do a lot of sense to define it in `MrpDisplaySearchModel`. The only exception is in the `_notify` where the cache is invalidated (TODO: to check if it still relevant.) Also, instead of havin an object with one uniq key who refers to an array (`recordCache.ids`), it will now be an array directly.

3. Make `recordCacheIds` part of the `MrpDisplay` `state`. The purpose of this change is to refresh the app everytime the cache is modified.

Also, this commit fix an issue where the record cache wasn't correctly updated when the selected employee requieres a PIN code. The issue was the cache was invalided before the PIN code was validated, a lot of async methods weren't awaited and the dialog itself wasn't bound to a callback in a way to be able to invalidate cache at the right moment.

OPW-4256568

Forward-Port-Of: odoo/enterprise#77210
Forward-Port-Of: odoo/enterprise#74421

Following a discussion with the product owner, it was clarified that in Colombia, customers must provide both an Identification Type and an Identification Number (VAT) for electronic invoicing, as these details are mandatory for all sales. Additionally, for extra billing addresses, the fields should also be visible and required. To address this, all billing addresses in the Colombian localization must include these fields as required. 1. Install the module "l10n_co_edi_website_sale." 2.

Following a discussion with the product owner, it was clarified that in Colombia, customers must provide both an Identification Type and an Identification Number (VAT) for electronic invoicing, as these details are mandatory for all sales.
Additionally, for extra billing addresses, the fields should also be visible and required.

To address this, all billing addresses in the Colombian localization must include these fields as required.

1. Install the module "l10n_co_edi_website_sale."
2. Change the default company of the current user to a Colombian company and switch to it.
3. Go to the partner record for the user and change the address to a Colombian address.
4. Add a contact as an invoice address with a Colombian address.
5. Go to the shop, add a product to the cart, and click "Go to checkout."
6. On the address page, click "Save address." The page redirects to itself repeatedly.

opw-4309448

Forward-Port-Of: odoo/enterprise#76609

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

Steps to reproduce ================== - Install hr_timesheet - Use an android device - Click on a time field => A numeric virtual keyboard appears. This prevents us from entering the `:` character. Cause of the issue ================== The inputmode attribute is set to numeric Solution ======== Set the inputmode to it's default value: text. See also [float_time_field] --- [float_time_field]: https://github.com/odoo/odoo/commit/8b919ae51d7deb34169b7c6970964056ef2e

Steps to reproduce
==================

- Install hr_timesheet
- Use an android device
- Click on a time field

=> A numeric virtual keyboard appears.
This prevents us from entering the `:` character.

Cause of the issue
==================

The inputmode attribute is set to numeric

Solution
========

Set the inputmode to it's default value: text.

See also [float_time_field]

---

[float_time_field]: https://github.com/odoo/odoo/commit/8b919ae51d7deb34169b7c6970964056ef2eb632

opw-4344083

Forward-Port-Of: odoo/enterprise#77339

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

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