Sometimes when importing products that share the same internal reference code (default_code) the _import_fattura_pa function will throw an expected singleton error. This is because, in order to find the product for the line of the invoice, it will search for the product reference code (e.g. [CONS_0001]), which is not necessarily unique.

I've set the limit to one on the search to fix the immediate error for
now, but I will add more logic to better search for the relevant product
in a future commit.

closes odoo/odoo#84724

Task-id: 2764978
Signed-off-by: Josse Colpaert <jco@odoo.com>

Set the l10n_it_edi_transaction value on the invoice to false after
receiving notificaScarto from the edi. This is so that the methods
associated with posting the invoice will detect it again and process it
for posting.

Task-id: 2764978
Part-of: odoo/odoo#84724

[FIX] account_edi_proxy_client, l10n_it_edi_sdicoop: adapt config params to make use of the test iap server

This commit adapts the l10n_it_edi_sdicoop and account_edi_proxy_client
modules to make use of the existing config param
'account_edi_proxy_client.demo' in order to target the correct odoo iap
server for italian edi requests.

When the config param is set to:
'prod' or False (when the config param doesn't exist): Target the
production odoo iap server (by default), which submits and collects edi from the
production channel. Though if the config parameter
'account_edi_proxy_client.edi_server_url' exists, we use the value
provided there instead.

'test': Target the test odoo iap server, which submits and collects edi
from the test channel

'demo' or anything else not above: don't send anything, and simulate the
flow of italian edi submissions in odoo

task-id 2764978

Part-of: odoo/odoo#84724

msgmerge with .pot file

Fixes odoo/odoo#83457

closes odoo/odoo#84764

X-original-commit: afb59998
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Purpose
=======

The parent_path is invalidated from cache when computing it from scratch
(with method `_parent_store_compute`) but not when it is recomputed
(method `_parent_store_update`).

The issue is that a computed field depending on 'parent_path'
won't receive the updated value using the cache, and could lead
to inconsistencies if the developer is not aware of that.

Specification
=============

On `_parent_store_update`, set the new value of 'parent_path' in the
cache before marking the records as modified.

task-2766452

closes odoo/odoo#84738

X-original-commit: b07605bd
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Co-authored-by: Rémy Voet <ryv@odoo.com>

Seems to have not broken anything so probably stable enough.

closes odoo/odoo#84726

X-original-commit: 2e73fef3
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Current behavior:
In any chatter, if you schedule an activity then use the "Done & schedule next" options you had an error if you try to modify some fields of the record linked to the chatter.
For example in CRM you couldn't modify the probability after using "Done & Schedule next"

Steps to reproduce:
-Go in CRM
-Go on a lead page
-In the chatter schedule an activity
-Click on mark done and then on Done & Schedule next
-Try to edit the probabilty field of the lead
-You get an error : Record does not exist or has been deleted. (Record: mail.activity(x,), User: xx)

opw-2648685

closes odoo/odoo#84614

Signed-off-by: Anh Thao PHAM <pta@odoo.com>

When the reservation is manual, the quantities in backorders are still
assigned automatically

To reproduce the issue:
1. In Settings, set "Reservation" to "Manually or based on automatic
scheduler"
2. Create a storable product P with an on-hand quantity equal to 3
3. Create and confirm a SO with 3 x P
4. On the associated delivery order, set the done quantity to 1 and
validate it (with backorder)
    - Note: When opening the delivery order, the reserved quantity is 0,
which is correct
5. Open the backorder

Error: the reserved quantity is 2, it should be 0

By default, when confirming a picking, if a backorder is created, the
latter is assigned by default. In case of a picking associated to a SO,
the default behavior (i.e., without the module `procurement_jit`) should
be the opposite

OPW-2703234

closes odoo/odoo#84673

X-original-commit: c4fb7ddb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

How to reproduce the bug:

- Install POS and data_cleaning
- Create 2 customers and set loyalty points
- Select both customers and merge them
- Once the merge is done, the loyalty points have not been summed

Bug:

When you merge 2 contacts that have both loyalty points, the resulting
contact won't have the sum of the 2 source contacts. Instead of that,
the resulting contact will only have the points of one of of the
contact.

closes odoo/odoo#80904

Opw: 2686208
Related: odoo/enterprise#24059
Signed-off-by: Simon Goffin <sig@odoo.com>

Before, if you would put Peru Street 23, it would put Peru in House number.
This is because the editable field was the street field, so behind the scenes,
Odoo will split it and according to the standard format without country,
this means Peru will go into House.

We tried first with a change inversing it, but as we are doing the change,
the best thing is to remove the split all together.  We added also onchange
logic that if you put a district it would automatically put the right city.

City or city_id should depend on the country and is correctly inherited by a
fields_view_get.

Task 2724531

closes odoo/odoo#84163

Signed-off-by: William André (wan) <wan@odoo.com>

decimal places while we compute stock_quants.

closes odoo/odoo#84689

X-original-commit: 1defcf4d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When performing a picking with a package, the source location of the
package level may become incorrect

To reproduce the issue:
(Use demo data)
1. In Settings, enable:
    - Packages
    - Storage Locations
2. In Operations Types, edit "Internal Transfers":
    - Enable "Move Entire Packages"
3. Create a storable product P
4. Create a receipt R with for P
5. Put 10 P in pack and validate R
    - Let be PK the package generated/used
6. Process an internal transfer with PK
    - The destination location of the package level is WH/Stock/Shelf 1

Error: Once the picking is validated, the source location of the package
level is "WH/Stock/Shelf 1". This is not true, it should still be
"WH/Stock"

The compute method is incorrect. It uses the package location to define
the source location of the package level. However, once the picking is
processed, this package has moved so using its location to define the
source location doesn't make sense anymore.

OPW-2754179

closes odoo/odoo#84637

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

With this commit: we are adding basic search feature for binary fields,
custom filter will have binary fields and selecting binary field will
display 'is set', 'is not set' operators.

with this user can at least filter records based on whether binary field
is set or not set.

task-2512226

closes odoo/odoo#70149

Backport of 28fa5bc8

This feature was working in 13.0 but it has been lost during the control panel
refactoring.

opw:2753199

closes odoo/odoo#84636

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Based on the po/pot files generated from odoo,
reorder the translations + remove the unused one.

closes odoo/odoo#84625

Signed-off-by: William André (wan) <wan@odoo.com>

When printing a delivery slip, if the delivered product is a kit
composed with a subkit, the products of this subkit won't be listed

To reproduced the issue:
1. Create 5 consumable products: 'Compo 01', 'Compo 02', 'Compo 03',
'Sub Kit', 'Super Kit'
2. Create two phantom-type boms:
    - Sub kit:
        - 1 x Compo 02
        - 1 x Compo 03
    - Super Kit:
        - 1 x Compo 01
        - 1 x Sub Kit
3. Process a delivery with 1 x Super Kit (the picking must be done)
4. Print the delivery slip

Error: The report only contains two lines, i.e. the name of the kit
('Super Kit') and the name of the 'direct' component ('Compo 01)

The issue comes from the SML used to define `kit_move_lines` (XML side).
It uses `has_kits` which only contains the top level kits' SML:
https://github.com/odoo/odoo/blob/1b1067b0cf2a3de2773915ff8205084492b1bbe3/addons/mrp/report/report_deliveryslip.xml#L6-L9


This is the reason why the SML for Compo 02 and Compo 03 are not listed

OPW-2740247

closes odoo/odoo#84552

Signed-off-by: Tiffany Chang <tic@odoo.com>

To reproduce the issue:
(Need purchase,sale_management)
1. Create a product category PC:
    - Costing Method: FIFO
2. Create a product P
    - Type: Storable
    - Category: PC
3. Create a PO with 1 x P @ 10 + Receive P
4. Create a PO with 1 x P @ 0 + Receive P
5. Create a SO with 1 x P + Deliver P
6. Create a SO with 1 x P + Deliver P
7. Process a return for sold P at step 6
8. Open the valuation of the return

Error: The value is 10, should be 0

In `_get_price_unit`, `price_unit` is defined with the correct value
(i.e., `0`), but the if-condition of the `return` is not respected, so
another value is used

OPW-2735502

closes odoo/odoo#84590

X-original-commit: c1f7c1dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Currently, `Attachment.copy` has an *explicit* check for write access
on the underlying record.

This doesn't necessarily make sense e.g. a user copying an attachment
from a template to an email may not have write access to the template,
but that should not be an issue. And indeed if the copy is performed
"by hand" (read then create) things work fine[^1].

Since both `read` and `create` are checked, the explicit `copy` check
doesn't seem necessary. Drop it, and try to add some tests around
`copy`. Move `test_06_linked_record_permission` to its own `TestCase`
and split it for readability.

A secondary issue is that the `check` in `create` was performed in the
context of the `self` being copied, leading to the same issue as
`copy` being repeated (that is, `a.copy()` would call `a.create()`
which would call `a.check('write')`, even though we're semantically
creating a record from scratch). The behavior is really intended for
`write` where we want to check if we have `write` access to both the
"source" and the "destination" records.

Explicitly opt-out of having any source data in the `create` before
performing the `check` calls, this way we correctly and only check for
the writability of the destination, and only check for the readability
of the source.

issue 2746483

[^1] well not entirely true, see 4th paragraph

closes odoo/odoo#84580

X-original-commit: bb956d7d
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Steps to reproduce:

- Set a language which use ',' (comma) as
  decimal separator (eg French)
- Make a Vendor Bill for any product at any price.

If the partner's language use '.' (period) as
decimal separator (eg English), the field
amount_by_group is formated whit period, while others
are formated with comma. They should all be formated
with comma.

- Now print the Vendor Bill

The same issue is occuring.

With Customer Invoices, the issue is the same on
the form view, but not on the printing, where all
the fields are formated with period, as set in the
partner's language.

After this commit, we format all the fields
regarding the environment's language on the view form,
either in Vendor Bills and Customer Invoices,
and we formating the printed bill/invoice regarding
the partner's language

opw-2735698

closes odoo/odoo#84561

X-original-commit: 42e20b2d
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>

closes odoo/odoo#84487

X-original-commit: 2df9503f
Signed-off-by: Josse Colpaert <jco@odoo.com>

Before this commit, during edit mode, the user was able to interact with
form elements. In 13.0, it was somehow prevented by some JS code by
losing the focus immediatly but it was not enough: if typing quickly the
user was able to type text. But the real problem was the user seeing the
input focused for half a second then not anymore, making him think a bug
occured. Worse, the datepickers of the form snippet were able to be used
entirely during edit mode, making the user think it is possible to
configure a default value (which is not true in 13.0). In following
versions, the bug is indeed worse as it messes up with the default
values configuration. In 14.0, it is apparently possible to type
normally in all of those inputs... although still ignored on save.

This commit fixes that via CSS, still allowing a click on the elements
to be considered as a click on the parent, but preventing to focus our
snippet inputs (this fix is limited to our own snippets as stable fix).
Note: the 13.0 JS code which prevents the focus right now was not found
(if it even exists...) but it would not be ok to remove it in stable
anyway. More investigation and review will be done once this reaches
master.

task-2523496

closes odoo/odoo#84570

X-original-commit: 6b77e105
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

The aim of this commit is to set partner on anglosaxon
aml in order to help our client in their stock
reconciliation process in case it hasn't been done automatically.

Before this commit:
anglosaxon line were created without partner

After this commit:
A partner is set when anglosaxon line are created

closes odoo/odoo#84520

Ticket: 2692308
Community-pr: https://github.com/odoo/odoo/pull/84468


X-original-commit: abfe37fc
Signed-off-by: William André (wan) <wan@odoo.com>

Documentation structure were modified to point out to a new subtree:
    content/applications/general/email_communication/email_server

Related task:2619564
Documentation PR:1092

closes odoo/odoo#84516

Signed-off-by: Vergote Baptiste (bve) <bve@odoo.com>

Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.

Commit [2] introduce a `website_edit` action but also didn't take into
account that the frontend lang might not be the source's lang.

Steps to reproduce:
- Create an empty database and install website
- Add an extra lang on website (e.g FR) and visit the website in that
lang
- Go in settings an create a new website, select a theme
- Redirect is with enable_editor but nothing happens

The editor isn't started if not in the source's lang.

This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.

[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
[2]: https://github.com/odoo/odoo/commit/e0cc28dcee977c4aa0c6a7e4ff6c463ab12e55a2



task-2687416

closes odoo/odoo#83508

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to repoduce:
- Go to Sales - products
- Create a product
- Add variants (3 attributes and 2 values each) Total is 8 variants.
- onfigure variants: Select 1 attribute and exclude it for 1 variant (for example: exclude for size 12x12)
-> the number of variants remains at 8. The one that is excluded is still visible in the Product variants tab.

Solution:
When an exclusion is created, archive all the not-possible-combination.

OPW-2729329

closes odoo/odoo#84515

X-original-commit: 5ff4eb02
Related: odoo/enterprise#24307
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Steps to reproduce the bug:
- Go to inventory > configuration > Products > Attributes
- Create a new Dynamic Attributes > add two attribute values
- Create a storable Product “Test”:
    - Add the two attributes
    - Save
    - Create a BOM related to this product
- Create a new manufacturing order:
    - Do not choose a product
    - Select the BOM related to the product “test”

Problem:
Traceback is triggered because as the product template only has dynamic variants, there is not a `product.product` record created yet.
but we try to access it in the onchange: https://github.com/odoo/odoo/blob/14.0/addons/mrp/models/mrp_production.py#L598



Solution:
do not set the product when a BOM of a product_tmpl without a variant was chosen
opw-2732254

closes odoo/odoo#84106

Signed-off-by: Arnold Moyaux <arm@odoo.com>

Before this commit the only way to modify the domain is to completely override portal_my_quotes/portal_my_orders.
Since this function is so big this is not clean/easy to do.
By creating a separate function we can simply override it and we can reuse the same domain in two places.

closes odoo/odoo#84240

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Chart.js did badly compute the graph canvas container height (width) by
using clientHeight (resp. clientWidth) that may be rounded up by the
browser. This leads to the appearence of a useless scrollbar in the
graph view and makes it flicker on some update.

closes odoo/odoo#84447

X-original-commit: 6bceae94
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

ae96f0e introduced an issue because the update of the m2m used a `tuple`
instead of a `list`

How to reproduce:

* Apply only the (Python) code changes done in ae96f0e, keeping the same
view (i.e. ignore the changed done to the view in ae96f0e).
* Instead of `n=5000` in the compute set `n=1` (it cannot be reproduced
with 5000 unless we create enough dummy data).
* On a clean v13 db with Landed costs (Accounting + Inventory + Purchase
+ demo data)
* Confirm a Purchase
* Create a Landed cost
* Try to select a transfer

Traceback:
```
...
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 250, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UndefinedFunction: operator does not exist: integer = integer[]
LINE 1: ...FROM "stock_picking" WHERE (("stock_picking"."id" in (ARRAY[...
                                                             ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
```

On the reported issues the traceback occur only for DBs with more than
5000 valid pickings, and for views that use the field
`allowed_pickign_ids`.

opw-2762355

closes odoo/odoo#84479

X-original-commit: ccd37565
Signed-off-by: Christophe Simonis <chs@odoo.com>

closes odoo/odoo#84456

X-original-commit: bdde46da
Signed-off-by: Olivier Dony <odo@odoo.com>

Steps to Reproduce:

  - Install 'account' module
  - Go to Settings and set a token for Google Drive
  - Activate Google Spreadsheet
  - Go to Invoicing -> Invoices
  - Under Search bar, click on Favorites -> Add to Google Spreadsheet

Issue:

  A spreadsheet does open but with no data (no formula or config).

Cause:

  The V3 API we were using was turned down in August 2021 and therefore
  not able to use the api to write on the spreadsheet.
  https://cloud.google.com/blog/products/g-suite/migrate-your-apps-use-latest-sheets-api)

Note: In case that the system parameters `​google_drive_client_id` and
`google_drive_client_secret` has been changed (and therefore also the
default templates), it must be ensured that the `client` has the
Google Sheet API (v4) activated and the scope
`https://www.googleapis.com/auth/spreadsheets` set.

API activation and configuration available here :
https://console.developers.google.com/apis/dashboard?project=[PROJECT]
https://console.developers.google.com/apis/credentials/consent/edit?project=[PROJECT]


**[PROJECT]** : Google project that will be linked to `​google_drive_client_id`.

opw-2633951

closes odoo/odoo#84436

X-original-commit: f6d1a882
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Steps to reproduce the bug:
- Go to any Contact > Sales and Purchase tab
- Edit > Change the barcode, and click Save
- Then click Edit, and try to erase (empty) the barcode > save

Problem:
A validation error is triggered, the constraint will check if other partners do not have the same barcode
but as it is empty there will be several other partners

Solution:
When the barcode is empty, no need to check if other partners have the same

opw-2753291

closes odoo/odoo#84411

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Adds chrome path discovery for windows, and spawns sub-chrome via
subprocess (since fork is not a thing).

closes odoo/odoo#84402

X-original-commit: 0c0ac49e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

(cherry picked from commit 4ed7217a)

Part-of: odoo/odoo#84402

Bug
===
If we
1. Open a lead with an email but without partner
2. Set a partner without email on the lead
3. The warning "The email will be propagated" is visible
4. When saving the form, the email is not propagated even if the
   warning message was visible

Solution
========
The reason is that, as the email was not changed, the inverse method
of this field was not called and so the email was not propagated.

The best solution would be to use "force_save" on those fields. But
this feature only works on readonly fields.

So, we simulate a real "force_save" on the email / phone, directly in
JS. That way the inverse will be called, and if necessary, the email /
phone will be propagated.

Task-2704904

closes odoo/odoo#83934

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: flch-odoo <flch@odoo.com>

The function `arrayToString` did not properly support domains containing
arrays of booleans, for instance `[["val", "in", [true, false]]]`. The
array containing the boolean was directly JSON stringified without being
converted to its python equivalent.

closes odoo/odoo#83817

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>

To reproduce the issue:
    - create a cash basis tax, with different account and tags for invoice and refund
    - make an customer invoice using this tax, post it, and register a full payment for it
    - unreconcile the payment

=> Two cash basis moves have been generated: one for the initial reconciliation, and another one reverting it when the reconciliation got cancelled.

=> Bug: the reverse move uses the refund repartition, while the original one is using the invoice's one, so they don't sum up to zero. It's wrong: since the reconciliation got cancelled, we want the impact of the invoice on our tax report to be 0 again, just as if it was brand new.

closes odoo/odoo#84246

Forward-port-of: https://github.com/odoo/odoo/pull/83837


Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

2f6a35eb introduced the fact that when doing a full refund of an invoice, the same account was used as on the original invoice, instead of the one on the tax refund repartition lines, though the tags were still the refund ones. This is wrong.

Also, it restored an inconsistent data setup in a test, while the current version was actually correct.

Forward-port-of: https://github.com/odoo/odoo/pull/83837
Part-of: odoo/odoo#84246

The function `_compute_amount` on `account.tax` returns None if the value of
`amount_type` is not a standard Odoo value. During normal use, this will never
be the case, and if the value is  modified by a custom module the method is
overriden in its code to account for that case.

During an upgrade, however, custom modules are not available. During the tests,
if a field needs to be computed using that function, it will break with
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'`

Adding a default return to the function in case the `amount_type` is not
recognisef will help prevent this.

closes odoo/odoo#84367

Signed-off-by: Olivier Colson <oco@odoo.com>

Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything

Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers
3. In the search field, begin typing the name of a product for which there is a transfer (e.g. Large Cabinet)
4. Click on the small arrow to the left of `Search Product for:` in the dropdown menu
5. Select the product you were typing
6. There is no result to the search even though there are transfers containing the product

Solution:
Remove `filter_domain`
The filter will be handled in the backend by `_name_search` of `product.product`, which already covers the same criteria (`default_code`, `name` and `barcode`)

Problem:
The display name (e.g. "[E-COM07] Large Cabinet") wasn't matched by the `filter_domain` because the domain sent in the RPC was:
```
"domain": [
	"|",
        "|",
        [
            "product_id.default_code",
            "ilike",
            "[E-COM07] Large Cabinet"
        ],
        [
            "product_id.name",
            "ilike",
            "[E-COM07] Large Cabinet"
        ],
        [
            "product_id.barcode",
            "ilike",
            "[E-COM07] Large Cabinet"
        ]
    ]
```

OPW-2732804

closes odoo/odoo#84363

X-original-commit: abd951b0
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>