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>

Steps to reproduce:
- create 2 stored products: "Test Manufacture" and "Test Component",
- create reordering rule (RR),e.g. min=1, max=5, for "Test Component"
  and set its route = Manufacture
- create 2 BoMs:
  - 1 for "Test Manufacture" that has component = "Test Component"
  - 1 for "Test Component" that has any component (e.g. screw)
- create + confirm a MO for "Test Manufacture" w/ product_qty = 5
- cancel the auto-generated MO (via RR) for "Test Component"
- set qty_producing=1 for "Test Manufacture" + validate + create
  backorder
- 2 new MOs are created: 2 new MOs, the backordered MO + the RR MO

Expected result: backordered MO linked to original MO via
  "procurement_group_id"
Actual result: original MO is linked to RR MO via "procurement_group_id"

Issue is due to "default_mrp_production_ids" in context during backorder
wizard creation which is reused by the RR MO's create, which calls a
procurement_group.create() that also reuses the same context. This
context makes it so the newly created procurement group is linked to
both the RR MO and the original MO. Therefore we remove this default
value from the context.

There is a rare case that a user may remove the procurement group of the
original MO. Therefore to ensure that generated backorders are still
linked to the original MO, we ensure that a MO has a new procurement
group created + assigned that will be used by its backorders. We ignore
the case where a procurement group is removed after backorders have
already been created because there's not much we can do about that.

closes odoo/odoo#84203

Fixes: odoo/odoo#83742
Signed-off-by: Arnold Moyaux <arm@odoo.com>

To reproduce the issue:
1. Produce a SN product P with lot L
2. Unbuild it
3. Produce 1xP with lot L

Error: When setting the lot, an error is displayed. When marking the MO
as done, a second error is displayed

Both domains in `_onchange_lot_producing` and in the beginning of
`_check_sn_uniqueness` are incorrect. We should centralize the
uniqueness checking thanks to all existing computations in
`_check_sn_uniqueness`. This way, unbuilt/scrapped moves will be
considered

OPW-2721205

closes odoo/odoo#83345

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

This commit improves two things:

1) Avoid filtering on the whole sale.order.line recordset every time,
   just to check if the products is in the order.

2) Use += instead of |= to build the result. += is much more efficient
   and we can trust the result is not going to have duplicates anyway,
   since we're looping through the recordset.

closes odoo/odoo#84134

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

- Create a sale.order with a product with an optional product
- Confirm order A
- Copy this order A, a new order B is created
--> Issue: the new line of order B are linked with an line of order A

closes odoo/odoo#83536

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

Preparation for a later PR where we use the country_code field to only show fields in the debit note and reversal wizard based on the country of the company

Backport of https://github.com/odoo/odoo/pull/83986/commits/44226366e3bb657ee5299662a788b8a07b16431f



closes odoo/odoo#84114

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

Also simplify _is_valid_product method to make use of _get_valid_products.
As it uses filtered_domain is more efficient than a search_count.

closes odoo/odoo#84107

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Before this commit: a coupon's start and end dates were compared with
the order date. When a customer adds a product to the cart, it creates
an order on the website. If the customer makes an order, it will remain
active until he completes it, even when the coupon is expired.

To reproduce the problem, add a product to the cart, create a coupon,
and set its end date to present time. Now you can use the coupon after
the end date has passed. So it's better to check the date with the
current time.

opw-2711987

closes odoo/odoo#83882

X-original-commit: 5ce13cc0
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

The shadow option needs to create a div on the fly to be able to
retrieve the default shadow value. This commit makes sure these divs
are also removed when no longer needed.

task-2752326

closes odoo/odoo#82223

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