- Improve _search methods of stock/product by using subqueries - Improve efficiency _search_on_hand of stock.quant (see #77190) Forward-Port-Of: odoo/odoo#78071

- Improve _search methods of stock/product by using subqueries
- Improve efficiency _search_on_hand of stock.quant (see
#77190)

Forward-Port-Of: odoo/odoo#78071

When a components is in a modal (filter dropdown in the Search More modal for example), it will be shifted from the toggler button. This is due to a `-webkit-transform: translate3d (0, 0, 0);` applied on the `modal-body` which influences the `position: fixed` attribute of `.o-popper-position` in the `dropdown-menu` ``` It is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property se

When a components is in a modal (filter dropdown in the Search More modal for example), it will be shifted from the toggler button.
This is due to a `-webkit-transform: translate3d (0, 0, 0);` applied on the `modal-body`
which influences the `position: fixed` attribute of `.o-popper-position` in the `dropdown-menu`

```
It is positioned relative to the initial containing block established by the viewport,
except when one of its ancestors has a transform, perspective,
or filter property set to something other than none (see the CSS Transforms Spec),
in which case that ancestor behaves as the containing block. 
```

See: https://developer.mozilla.org/en-US/docs/Web/CSS/position

the translate3d was applied with https://github.com/odoo/odoo/pull/20314
As the bug is no longer exists, we can remove this style.

opw-2668638

Forward-Port-Of: odoo/odoo#78736

Due to floating point limitation, the quantities displayed in the forecasted report should be formatted to ensure the rounding. Issue example: (Need stock) 1. Create a storable product P 2. Update its quantity to 7.1 3. Consult the Forecasted Report Error: Quantities are "7.1000000000000005 Units". In this case, the floating-point issue comes from the method `float_round()` Another example: (Need purchase_stock) 1. Create a storable product P 2. Update its quantity to 0.1 3.

Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.

Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report

Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`

Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report

Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)

Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.

OPW-2611892

Forward-Port-Of: odoo/odoo#78819
Forward-Port-Of: odoo/odoo#78773

How to reproduce the problem: - Install hr_timesheet and create a project. - Create a task in the project, and assign a Partner as the Customer - In the Timesheet tab of the Task, add a new entry. Save the Task. - Edit the task again and change the Customer. Save again. -> the partner on the Timesheet entry did not change. With sale_timesheet, the Sales Order Item of the timesheet entry can be updated from the Sales Order Item of the Task, but it isn't the case with the partner, which

How to reproduce the problem:
- Install hr_timesheet and create a project.
- Create a task in the project, and assign a Partner as the Customer
- In the Timesheet tab of the Task, add a new entry. Save the Task.
- Edit the task again and change the Customer. Save again.
-> the partner on the Timesheet entry did not change.

With sale_timesheet, the Sales Order Item of the timesheet entry can
be updated from the Sales Order Item of the Task, but it isn't the case
with the partner, which is not logical.

Solution : Now, the partner_id is computed and will automatically be
updated from the Task's Customer/partner_id. If sale_timesheet is
installed, it will first filter out the invoiced timesheet entry:
we don't want to change an already invoiced entry.

opw-2616784

Forward-Port-Of: odoo/odoo#78790
Forward-Port-Of: odoo/odoo#78577

- Update partner document type Task: https://www.odoo.com/web#id=2486484&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 Forward-Port-Of: odoo/odoo#74488

- Update partner document type

Task: https://www.odoo.com/web#id=2486484&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720

Forward-Port-Of: odoo/odoo#74488

Steps to reproduce: 1. Log on odoo with a user A on mobile device 2. Log on odoo with a user B on desktop 3. User B call user A 4. User A answer the call and the keyboard popup on the screen => BUG To avoid this behavior, we disable the input focus on mobile device when the user answer a call. 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 guideli

Steps to reproduce:

1. Log on odoo with a user A on mobile device
2. Log on odoo with a user B on desktop
3. User B call user A
4. User A answer the call and the keyboard popup on the screen => BUG

To avoid this behavior, we disable the input focus on mobile device when
 the user answer a call.

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

and in the notification zone. part of task-2634175 Forward-Port-Of: odoo/odoo#77296

and in the notification zone.

part of task-2634175

Forward-Port-Of: odoo/odoo#77296

### Expected behavior The log note sent when received quantity is updated should take into account the quantity already received. ### Current behavior The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock` ### Steps to reproduce the error - Create a RFQ with few units of a Storable Product (e.g. 5 uni

### Expected behavior 
The log note sent when received quantity is updated should take into account the quantity already received.

### Current behavior 
The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`

### Steps to reproduce the error
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)

| Expected result  | Current result |
| ------------- | ------------- |
| `Received Quantity: 0.0 -> 3.0`<br>`Received Quantity: 3.0 -> 5.0`  | `Received Quantity: 0.0 -> 3.0`<br>`Received Quantity: 0.0 -> 5.0`  |

### Reason
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received

opw-2600221
opw-2613116

Forward-Port-Of: odoo/odoo#78286

Current behavior before PR: it was raising an error while trying to preview the certificate Desired behavior after PR is merged: prevent the preview of the certificate, as it is not possible to set the preview of the certificate Task: https://www.odoo.com/web#id=2623276&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78751 Forward-Port-Of: odoo/odoo#7

Current behavior before PR:
it was raising an error while trying to preview the certificate

Desired behavior after PR is merged:
prevent the preview of the certificate, as it is not possible to
set the preview of the certificate

Task: https://www.odoo.com/web#id=2623276&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720

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

Forward-Port-Of: odoo/odoo#78751
Forward-Port-Of: odoo/odoo#75116

opw-2677100 Forward-Port-Of: odoo/odoo#78908

opw-2677100

Forward-Port-Of: odoo/odoo#78908

The validation error raise "AttributeError: module 'odoo.exceptions' has no attribute 'ValidationEreror'" Instead the the correct message "Member assignment domain for user %(user)s and team %(team)s is incorrectly formatted -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78900

The validation error raise "AttributeError: module 'odoo.exceptions' has no attribute 'ValidationEreror'"
Instead the the correct message 
"Member assignment domain for user %(user)s and team %(team)s is incorrectly formatted





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

Forward-Port-Of: odoo/odoo#78900

Some records have NULL create_date. In that case we get a traceback like below. ``` Traceback (most recent call last): ... File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value getattr(self, field.compute)() File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 259, in _com

Some records have NULL create_date. In that case we get a traceback like
below.
```
 Traceback (most recent call last):
   ...
   File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
    getattr(self, field.compute)()
   File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 259, in _compute_avatar_128
    super()._compute_avatar_128()
   File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 62, in _compute_avatar_128
    self._compute_avatar('avatar_128', 'image_128')
   File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 263, in _compute_avatar
    super(Partner, partners_with_internal_user)._compute_avatar(avatar_field, image_field)
   File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 39, in _compute_avatar
    avatar = record._avatar_generate_svg()
   File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 66, in _avatar_generate_svg
    bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp()))
 AttributeError: 'bool' object has no attribute 'timestamp'
```
Observed during upgrade request 40906

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

Forward-Port-Of: odoo/odoo#78363

Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value. This value is extracted during the pricelist price computation (but not used anyway...). But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value. In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment wit

Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value.
This value is extracted during the pricelist price computation (but not used anyway...).

But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value.  In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment with the same values (user, context, ...) exists.
During this comparison, the new context, with an id (int) as `partner` value, is compared with existing contexts, potentially including some with a recordset on the same key.  Such a comparison fails on the lowest `__eq__` level, raising "Comparing apples with oranges" error.

This commit fixes this case, by making sure the value put in the `partner` context value is always a recordset, and not an id.

Note: In the future, this context key should be dropped because it's still a bad practice to put recordsets in the context.

Forward-Port-Of: odoo/odoo#78950
Forward-Port-Of: odoo/odoo#78276

Before this Commit: =================== The 'Load more... xx Remaining' button is shown on the Customer/Vendor matching tab on the reconciliation page. but not shown on the Miscellaneous matching tab. After this Commit: ================== This button is shown on the Miscellaneous matching tab also with a proper count of remaining Miscellaneous lines. opw-2658672 Forward-Port-Of: odoo/enterprise#21834

Before this Commit:
===================
The 'Load more... xx Remaining' button is shown on the Customer/Vendor matching tab on
the reconciliation page. but not shown on the Miscellaneous matching tab.

After this Commit:
==================
This button is shown on the Miscellaneous matching tab also with a proper count of remaining
Miscellaneous lines.

opw-2658672

Forward-Port-Of: odoo/enterprise#21834

*Before this commit:* - The credit notes that affect boletas were not included in the report, and they should be. - In a multi-company environment the report is being sent even if the companies don't have boletas implemented. *After this commit:* - Prevents sending the report in a multi-company environment where some of the companies use CL localization, and not boletas. (The criteria is to send the report when the company has at least one boletas caf file uploaded). - Includes in the rep

*Before this commit:*
- The credit notes that affect boletas were not included in the report, and they should be.
- In a multi-company environment the report is being sent even if the companies don't have boletas implemented.

*After this commit:*
- Prevents sending the report in a multi-company environment where some of the companies use CL localization, and not boletas. (The criteria is to send the report when the company has at least one boletas caf file uploaded).
- Includes in the report the credit notes that affect boletas.

Forward-Port-Of: odoo/enterprise#21719
Forward-Port-Of: odoo/enterprise#20780

When VOIP module is installed, this commit ensures click event on a PhoneField's value is only prevented when Odoo's VOIP should handle the call. Steps to reproduce: - ensure "voip" and "contacts" apps are installed - ensure voip's settings are set to "prod" without proper credentials - open a partner in Contacts app - click on the phone/mobile number => native call handler (SIP softphone, mobile phone app...) should open but doesn't! opw-2654620 Forward-Port-Of: odoo/enterprise#2

When VOIP module is installed, this commit ensures click event on a
PhoneField's value is only prevented when Odoo's VOIP should handle the
call.

Steps to reproduce:
- ensure "voip" and "contacts" apps are installed
- ensure voip's settings are set to "prod" without proper credentials
- open a partner in Contacts app
- click on the phone/mobile number
=> native call handler (SIP softphone, mobile phone app...) should open
but doesn't!

opw-2654620

Forward-Port-Of: odoo/enterprise#21783

Forward-Port-Of: odoo/enterprise#18032

Forward-Port-Of: odoo/enterprise#18032

- Update Anexo 1.8 Task: https://www.odoo.com/web#id=2486484&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 Forward-Port-Of: odoo/enterprise#19978

- Update Anexo 1.8

Task: https://www.odoo.com/web#id=2486484&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720

Forward-Port-Of: odoo/enterprise#19978

[IMP] mrp_mps: add filter and favorite to mps In the search view of mps, add the filter and favorite options like for other search views. [FIX] mrp_mps: avoid raise constraints in case of bom component. In b07c21c, we introduce bom field to add automatically mps for components. But we cannot use this feature if the mps product/warehouse pair is already exists. Allow to do this by filterout duplicated values from lists. task-2664111 Forward-Port-Of: odoo/enterprise#21528

[IMP] mrp_mps: add filter and favorite to mps

In the search view of mps, add the filter and favorite options like for
other search views.

[FIX] mrp_mps: avoid raise constraints in case of bom component.

In b07c21c, we introduce bom field
to add automatically mps for components. But
we cannot use this feature if the mps product/warehouse pair is already
exists. Allow to do this by filterout duplicated values from lists.

task-2664111

Forward-Port-Of: odoo/enterprise#21528

Before this commit, if the user wants to scan the same lot for multiple lines for the same product (in a batch pickings for example), it's not allowed because the application check the serial number isn't already used (as a SN has to be unique) but it do the same check for lot, which shouldn't happened. Also, it should raise an error but it didn't. How to reproduce: - Create a product tracked by lot; - Create two different receipts for this product and batch them; - Confirm the batch an

Before this commit, if the user wants to scan the same lot for multiple lines for the same product (in a batch pickings for example), it's not allowed because the application check the serial number isn't already used (as a SN has to be unique) but it do the same check for lot, which shouldn't happened. Also, it should raise an error but it didn't.

How to reproduce:
 - Create a product tracked by lot;
 - Create two different receipts for this product and batch them;
 - Confirm the batch and open it in the Barcode App;
 - Scan the product -> A line is selected;
 - Scan the lot -> The lot name should be added to the line and its quantity should be incremented.
   Repeat until the line is fulfilled.
 - Once the first line is fulfilled, scan again the same lot
   -> The second (unfulfilled) line isn't selected or incremented, the first one isn't incremented neither.

The wanted behavior is, when a lot is scanned and the current line has a product tracked by lots:
 - Increment it if the line isn't fulfilled.
 - Try to find an another unfulfilled line for this product if the current line is fulfilled, and increment it.
 - Increment the current line even if it's fulfilled if there is no other unfulfilled line for the same product.

task-2646107

Forward-Port-Of: odoo/enterprise#20841

A default role was added to sign in order to allow adding items while signing documents without sign items. A filter currently exists to prevent the user from choosing the default role when editing a template, however this filter causes some tracebacks when we try to edit a template that contains the default role. For this reason, it was decided that it was simpler to drop the filter and allow users to select the default role, since it wouldn't affect the application. Since the default role is n

A default role was added to sign in order to allow adding items while signing documents without sign items. A filter currently exists to prevent the user from choosing the default role when editing a template, however this filter causes some tracebacks when we try to edit a template that contains the default role. For this reason, it was decided that it was simpler to drop the filter and allow users to select the default role, since it wouldn't affect the application. Since the default role is now visible, it was decided to rename it to 'Standard' not to mislead the users with the default word.

task-2657124

Forward-Port-Of: odoo/enterprise#21313