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>

With commit [1] (and the parent commit here which reviews it), we
move the scrollbar to the modal instead of the website content if the
modal has scrollable content even in the case there is no backdrop. An
exemple would be the cookie bar, configured in popup mode, with a tall
content inside.

This was however not enough: the computation which determines if the
modal should be scrollable or not was not re-done after an image was
loaded. So if the popup was around the height of the window, it could be
smaller than the window's height before images loading and taller after
which would result in having the scrollbar on the body instead of the
scrollable popup.

[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6



closes odoo/odoo#83921

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

*: web_editor

Commit [1] was not coded defensively enough: after it, dialogs not using
a proper bootstrap structure triggered a traceback once they were opened
(this was discovered on odoo.com where such unconventional dialogs do
exist). Bad luck: there was actually a check to allow unconventional
dialogs but it was not done at the right location.

However, fixing this, it was found that more than this was not ok. There
is actually no need to consider the modal-content element at all. Just
using our `hasScrollableContent` method is enough and requires no extra
search in the DOM. This actually also properly computes if the modal
overflows or not while it was not the case before as it did not consider
the modal-dialog element's paddings.

Finally, the whole customized behavior of the modal scrollbar here was
only designed to affect our Odoo modals with the s_popup_no_backdrop
class (see original commit [2]). Indeed, only in that case we want to be
able to switch between body scrolling and modal scrolling while the
modal is opened. In custom cases and other Odoo cases, we want the
standard Boostrap behavior of only being able to interact with the modal
while opened. This commit cleans the code to restore that spirit
(hopefully this does not cause stability issues as [1] was introduced
only a week ago). Sorry for any inconvenience.

[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6
[2]: https://github.com/odoo/odoo/commit/e5a5f98819b3a70b3e2564fb91722cab415ceea9

Part-of: odoo/odoo#83921

While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line
`credit_expense_account = accounts['expense'] or self.journal_id.default_account_id`
can cause a 'Expected singleton' error. During upgrades from v13 and earlier,
the value used for `accounts['expense']` is always `None`.
If the recordset in `self` contains more than one record, the error will happen.

By replacing `self` with the iteration object `move`, this error is averted.

The error happened during an upgrade from v13. Since the value assigned to
`accounts['expense']` doesn't exist in that version, it goes to
`self.journal_id.default_account_id` to grab it.
If `self` has more than one record, the error happens.

Traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1199, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 475, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
    migrate(self.cr, installed_version)
  File "/tmp/tmpae3wx5o6/migrations/account/saas~13.4.1.1/end-09-payment-refactoring.py", line 618, in migrate
    util.iter_browse(env["account.move"].with_context(**ctx), ids, chunk_size=1024).action_post()
  File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in caller
    return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
  File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in <listcomp>
    return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
  File "/home/odoo/src/odoo/14.0/addons/sale/models/account_move.py", line 14, in action_post
    res = super(AccountMove, self).action_post()
  File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 2715, in action_post
    self._post(soft=False)
  File "/home/odoo/src/enterprise/14.0/l10n_mx_edi_landing/models/account_move.py", line 26, in _post
    return super()._post(soft)
  File "/home/odoo/src/enterprise/14.0/l10n_mx_edi/models/account_move.py", line 456, in _post
    return super()._post(soft=soft)
  File "/home/odoo/src/odoo/14.0/addons/sale/models/account_invoice.py", line 75, in _post
    posted = super()._post(soft)
  File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/account_invoice.py", line 171, in _post
    return super()._post(soft)
  File "/home/odoo/src/enterprise/14.0/account_reports/models/account_activity.py", line 75, in _post
    return super()._post(soft)
  File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 49, in _post
    self.env['account.move.line'].create(self._stock_account_prepare_anglo_saxon_out_lines_vals())
  File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 158, in _stock_account_prepare_anglo_saxon_out_lines_vals
    'account_id': credit_expense_account.id,
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 3821, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.account(1383, 38, 30)
```

closes odoo/odoo#83739

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

The test `test_20_payulatam_form_management` was not passing
since #68593 due to the signature change

closes odoo/odoo#84060

X-original-commit: 5f43d0a1
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

The original task is task-2701097
opw-2627875

X-original-commit: 4ab4f3c4
Part-of: odoo/odoo#84060