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>

closes odoo/odoo#84346

X-original-commit: 5c295fd1
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Before this commit, on Chrome browser, the page url input and the
visiblity password input were autocompleted with the user's login and
password in the page properties options.

After this commit, they are no longer.

Regarding the url input page, it seems to be because Chrome considers
that the first text input located before a password input in the DOM is
a login input.

task-2502747

closes odoo/odoo#84372

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

[FIX] survey: Avoid forbidding access to survey when the answer cookie corresponds to no actual answer

To reproduce:

1) Create a survey and open it with a portal user with its /survey/start/*** link

2) In a private window, connect as the admin and remove the answer in 'Not started yet' state that step 1 created.

3) Go back to your portal user window and re-enter the same /survey/start/*** URL.
==> The portal user is brought back to the home page. He has no way to access the survey anymore, the link will always redirect him there.

This is because of cookies. The first time the user opens the survey, it creates a cookie in his browser allowing him to reload the answer he was working on. In our example, this answer has been deleted for some reason (maybe some cleaning of too old 'not started' or 'in progress' stuff); so the token stored in the cookie does not correspond to anything anymore. Instead of crashing and redirecting to home page, this commit makes it so that we now ignore the cookie in that case, so that the user directly has access to the survey to build a new answer.

Task-2729738

closes odoo/odoo#82041

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

To reproduce the issue:

1) Create a survey requiring user login, with multiple pages

2) Create portal user A and B

3) With user A, go to URL /survey/start/****, where **** is the access token of your test survey. Fill in the first pages of the survey, but don't finish your submission (so: the answer has to stay 'in progress').

4) Logout from user A.

5) From the same browser window (or without cleaning cookies, at least), directly login with user B, and go to the same /survey/start/**** link

====> The 'in progress' answer from A is loaded, even though we are connected with B and should hence not have access to it. Instead, we should have created a new blank answer for B.

This is due to our cookie management. When a cookie is kept in the browser with the token of a previously entered answer, we reload it without checking its owner.

Task-2729738

Part-of: odoo/odoo#82041

closes odoo/odoo#84304

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

Useful resource to understand the different taxes:
- IVA dedutível
- IVA suportado
- IVA liquidado
https://www.e-konomista.pt/iva-dedutivel/



closes odoo/odoo#84267

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

In order to respect the good practices of HTML, it is preferable that
the IDs of HTML elements do not start with a number. This makes it
easier to handle CSS selectors etc.

task-2760205

closes odoo/odoo#84236

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Step to reproduce:
1) create a product with, the "Product Type" as
"Storable Product" + A "Product Category" with a "Costing Method"
set in "FIFO" mode and the Inventory Valuation in "Automated".

2) create a Purchase Order for 1 unit of that product and set the unit
price to 10.00. Confirm Order -> Receive Products -> Validate
(the delivery) -> Apply

3) create a second Purchase Order for 1 unit of the same product but
set the unit price to a different price, like 20.00. Confirm Order ->
Receive Products -> Validate (the delivery) -> Apply

4) create a Sales Orders for 1 unit -> Confirm -> Smart button
Delivery -> Validate -> Apply

5) check the cost on the product form of that product.

On the V13 it will be $10, so its the last unit that left the stock
On V14 and upper, it will be $20, so the next product that will leave
the stock.

The help popup for the field "standard_price" doesn't reflect the
correct behavior. It's the standard price for the next unit instead
of the last one.

closes odoo/odoo#82678

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

Step to reproduce:
- Create a event in outlook with a long description
- Load the event in Odoo

Current Behaviour:
- Odoo use the body preview to get the event description
If the body is longer then, the description in Odoo is incomplete.

Behaviour after PR:
- Change fetch option to get description as text
- Use body['content']  as description which is the full body.

opw-2746358

closes odoo/odoo#84054

Signed-off-by: Arnaud Joset <arj@odoo.com>

When the snailmail API-call timed out, the SnailmailLetter.state and SnailmailLetter.error_code were not changed, which resulted in an infinite loop of retries  via the "Snailmail: process letters queue" cron job.
This commit changes this behavior: On a timeout the SnailmailLetter.error_code is changed such that no retry happens. Following stable policy, no timeout error is added, but 'unknown error' will be used. Preventing retries on timeout is mandatory as timed-out request are indeed processed by IAP and customer credited.

closes odoo/odoo#84202

X-original-commit: 1d842443
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

I want to customize the value when creating the stock move but with the
old code I can't do it. So, I add you a hook method. Look it will be
more professional and good for developer

closes odoo/odoo#83490

X-original-commit: 8e185dfe
Signed-off-by: Arnold Moyaux <arm@odoo.com>