When a product is configured with 2 different boms kit
using the same sequence,
the bom chosen could change randomly, therefore randomly
changing the available quantity.

This has been detected during an upgrade,
With the unit test checking the quantities
of the products doesn't change before and after the upgrade,
and in this case, the bom chosen before upgrade
was different than the bom chosen after upgrade,
therefore changing the available quantity of this product
before and after upgrade.

```
Traceback (most recent call last):
  File "/tmp/tmp659zn85u/migrations/testing.py", line 208, in test_check
    self.check(value)
  File "/tmp/tmp659zn85u/migrations/stock/tests/test_on_hand_quantity.py", line 20, in check
    self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[262[3108 chars], '-107'], [3879, '-36'], [3983, '-39'], [3984[5666 chars]14']] != [[262[3108 chars], '-150'], [3879, '-36'], [3983, '-39'], [3984[5666 chars]14']]

First differing element 209:
[3878, '-107']
[3878, '-150']

Diff is 10670 characters long. Set self.maxDiff to None to see it. : Invariant check fail
```

upg-27353

closes odoo/odoo#76363

X-original-commit: 9e7d7fe8
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

This module sends the taxes information (mostly VAT) of the
vendor bills and customer invoices to the SII.  It is called
Procedimiento G417 - IVA. Llevanza de libros registro.  It is
required for every company with a turnover of +6M€ and others can
already make use of it.  The invoices are automatically
sent after validation.

How the information is sent to the SII depends on the
configuration that is put in the taxes.  The taxes
that were in the chart template (l10n_es) are automatically
configured to have the right type.  It is possible however
that extra taxes need to be created for certain exempt/no sujeta reasons.

You need to configure your certificate and the tax agency.

closes odoo/odoo#70302

Task: 2492978
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Task: 2492978
Part-of: odoo/odoo#70302

Since commit bbb1a8f1, module's upgrade script can also be added
into special 'upgrades' folder as an alternative to the old 'migrations'
folder.

  As those upgrade scripts are not maintained from version to version, we
should not count them as maintenance.

OPW-2536046

closes odoo/odoo#76315

X-original-commit: 28a303a6
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>

+ Added the 'Trusted Devices' feature
+ Added 'Remember this Device' checkbox on /web/login/totp
+ Added trusted device's OS / browser on Profile > Account Security

Added '2FA Trusted Devices' feature to allow users to remember their
device to bypass the 2FA for the next connections. The trusted devices
are displayed in a 'Trusted Devices' One2Many under the 'Developer API
Keys'. It is possible to revoke all the trusted devices at once with a
special button. It is also possible to revoke one at a time on the
desired one.

Add tour
Remove the "new Promise()" that makes the logout step fail (and seems
unnecessary).

closes odoo/odoo#69608

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

- Go to any graph view (i.e. in CRM)
- Change "Group By" 2 times very very quickly
(In Chrome, you can set Throttling to "Slow 3G" in Network tab of devtools)
Data from first groupby will be mixed with data from the second one.

A graph reload is performing the following steps:
  * clean previous data
  * fetch data
  * set data
The issue happens when a second reload is performed while the previous one
has not set its data yet and the cleaning step of the second one is performed
before the setting step of the first one.

The solution will be to ignore the setting step of all previous reloads if
there is a more recent one.

opw-2460145

closes odoo/odoo#76269

X-original-commit: 1cda59cf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

- Create a product with Category configured with:
  * Costing Method: First In First Out (FIFO)
  * Inventory Valuation: Automated
- Create a PO to buy 1 unit and receive the product
- Create a SO to sell 1 unit and deliver the product
- Return the product
- Re-deliver the product
- Create invoice for SO but don't post it
- Connect with an user with "Accounting: Accountant" rights only
- Post the invoice
An access error will be triggered when trying to access stock valuation layer.

opw-2623376

closes odoo/odoo#76270

X-original-commit: cc76e76e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

The method '_company_default_get' on res.company is deprecated and
shouldn't be used anymore.

closes odoo/odoo#76284

X-original-commit: 2842a3c3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

- Configure payment stripe to be available on the web shop
- Let's consider a product with P (sales price = 100€) invoice policy based on delivered qty
- Set in the config parameter sale.automatic_invoice to True
- Create a SO with P and generate a payment link PL for 50€
- Go to PL and pay it

Bug:

An error was raised because there was no invoicable line when computing the
invoice of SO

opw:2635175

closes odoo/odoo#75892

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Currently, when there is a YouTube URL configured on the track, we
automatically set the layout of the track page as "widescreen".

This implies that we hide some menus and adapt the layout to display the full
video player.

However, in the XML template of the track view, we only display the video
player if there is a YouTube URL configured AND one or more of those conditions
is respected:
- The track is configured as a "YouTube Replay"
- The track is "coming soon" (< 30 minutes)
- The track is live
- The track is done

This is done to match the two behaviors and get a consistent display.

Task-2643147

closes odoo/odoo#76248

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

opw-2640962

closes odoo/odoo#76239

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

Following commit 637684fb which improved
the conditions under which the ComponentWrapper compatibility layer
should trigger owl's `__callMounted` on all the owl children of a Legacy Widget.

One case was forgotten though: when the current component (wherever it is in the hierarchy)
is rendered BUT another rendering has been initiated meanwhile.

In that case, we shouldn't mark the component as mounted. The owl's fiber.complete algorithm
will take care of calling __callMounted when it finishes.

closes odoo/odoo#75950

Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>

If for some reason we cannot compute lead probability, we should simply
continue to the next value without causing a division by zero.

For example, this can happen if all stages are team specific, as there is
a current limitation regarding the first stage (used to know how many lost
and won there is) that requires to have no team assigned to it. This is a
side effect of the commit https://github.com/odoo/odoo/commit/cd291b79eb2d2df80899867263ec71438ab8fe87

 introduced in V14, and we should add
a test to ensure we do not crash in that case.

closes odoo/odoo#76110

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

Before this commit, Inventory Admin was not able to create new /edit picking type
as Non-admin users doesn't have rights to create/edit sequence.

With this commit, we are creating/editing `sequence_id` with sudo

closes odoo/odoo#75606

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

no need to make rounding during computing qty_available

STEPS (see the test):

* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units

BEFORE: qty=11
AFTER:  qty=12

---

opw-2632782

closes odoo/odoo#76145

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

`fields.Date.today` doesn't give date based on TZ which might be wrong
in some cases as it doesn't respect TZ.

With this commit, we are using `fields.Date.context_today` as default date.

closes odoo/odoo#75600

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

We fix 2 related UoM issues:

1. Fix quant inconsistency from changing the UoM of Done
   stock.move.lines

Steps to reproduce:
- Enable "Storage Locations" setting
- Create a new "Storable Product" and create a receipt for 1 unit of it
- Validate the 1 unit receieved
- Open "Detailed Operations" of the move and change the stock.move.line
  UoM to dozen.

Expected result: 13 on hand
Actual result: 1 on hand

To fix this:
- prevent users from editing the UoM after the picking is
  done (i.e. unless adding a new stock.move.line and not saving).
- update the write on done logic so stock.move.line UoM changes are
  considering and will update the quant correctly (in case of RPC or
  direct write).

2. Prevent changing UoM of Done stock.move to prevent inconsistent field
values within stock.move and confusion for users

Steps to reproduce:
- Complete a picking (incoming is easiest to see) with a new product
  (i.e. 0 qty) having 1 unit done.
- Unlock picking and add a new stock.move with 1 unit done and save.
- Edit the just added stock.move's UoM from Units to Dozen.
- Check the quantity on hand / Done qty of stock.move after leaving and
  returning to form.

Expected result: 13 On Hand
Actual Result: 2 On Hand and the "Done" qty in the picking is 0.0083
  (i.e. 1/12 of a dozen)

To fix this:
- prevent users from editing the UoM after the picking is done (unless
  adding a new stock.move and not saving)
- if a Done stock.move UoM is uodated, a UserError occurs because there
  is no straightforward way to ensure the quant is updated correctly
  since is handled within the move.line (i.e. has no visibility to its
  move's uom change => changing only UoM and not qty done will result in
  no quant update)

closes odoo/odoo#75891

X-original-commit: 8ca10a8f
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Calling `_get_answer_score_values` on each question creation or update is
not necessary if value is already provided.

Followup of odoo/odoo@0d32ed45aebe2721073580ddae68ec4a8c1499d6

closes odoo/odoo#68500

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

In a POS session, when using the scanner, if the seller changes the
customer, the prices may become incorrect

To reproduce the issue
1. Create a product P:
    - Sales Price: 38
    - Barcode: 2312345000002
    - Available in POS: True
2. Start a POS session (with debug Window)
3. Scan 2312345010001
    - This is product P with price $10
4. Set a Customer

Error: The price is now $38

Because the price has not been set manually, when changing the customer,
the pricelist is updated and so does the price.

When scanning a barcode that includes a price, the latter should be
considered as manually set.

OPW-2618934

closes odoo/odoo#76076

X-original-commit: e6672427
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Steps to reproduce the bug:
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers", “Pre-fill Detailed Operations”, and "Show Detailed Operations"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”

Problem:
In the created “stock_move_line” the expiration date field is not set

Solution:
When we add a new "stock_move_line" and choose a product, an onchange is triggered in order to set
the expiration_date field even if we do not choose a "lot /serial number name".
So we can replace the onchange with a compute function to do the same thing in the creation.

opw-2634583

closes odoo/odoo#75806

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

- create a second warehouse, resupply from the first
- create a product, replenish W2 from W1
- Goto Inventory Forecast

--> Issue value are wrong.

An OUT is when WH source is Set and WH dest is not set.
An IN is when WH dest is Set and WH source is not set.

closes odoo/odoo#67598

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Also, remove the duplicated 'edi_document_ids' field inside the view.
'edi_document_ids' is now in debug mode for payments.

closes odoo/odoo#75529

Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>

options="{'no_open': '1'}" is managed for many2one fields.
This commit aims to do the same for x2many fields.

Note: A test will be added later
Part-of: odoo/odoo#75529

closes odoo/odoo#75508

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

closes odoo/odoo#75349

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

Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.

opw-2637321

closes odoo/odoo#76030

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up

Steps to reproduce :
 1) Install Manufacturing
 2) Enable work centers
 3) Create a manufacturing order, in the work order tab, add a new line
 and set a Scheduled Start Date, confirm the date
 -> Traceback

opw-2633940

closes odoo/odoo#75992

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

closes odoo/odoo#75595

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

closes odoo/odoo#75409

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

Reverts 62bf009 as that is causing that no message is posted in the chatter upon creation.
Althought this might have been an issue before, #56631 removed the addition of the "Application created" message in the message body, so now there was nothing adding it, making the message invisible in the chatter.

TT30413

closes odoo/odoo#75978

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

In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.

The new backorder  name will not be guaranteed exact related to the
production sequence but will be unique in any cases.

closes odoo/odoo#76060

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Considering the field declaration:
https://github.com/odoo/odoo/blob/fe5deb4ee4c8e07aed2f2cff6210271bfaa61476/addons/point_of_sale/models/pos_order.py#L1121


`discount` is a rate, not an amount. Therefore, suppose a discount of
10%, when opening a POS-generated SO, the discount shouldn't be "$10".

OPW-2629493

closes odoo/odoo#75991

X-original-commit: 225fb81c
Related: odoo/enterprise#20621
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Bad debt accounts should be of expenses type like the ones in the l10n_de_skr03 addon

opw-2512526

closes odoo/odoo#76019

X-original-commit: 5780e50c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>

Reproduce :
- Create an invoice with a sepa QR-code.

Result :
  When reading the QR-code, German banks assume the fisrt 3 characters are the currency name/code, so the first 3 digits of the amount are cut from this amount.

Solution :
  The amount now starts with the currency name/code (3 letters), as prescribed by EPC norms.

opw-2591454

closes odoo/odoo#75816

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

In case there is a `product_qty` column added by a custom module,
`product_qty`, without specifying from which table to take it from
in the view definition, can lead to an ambiguous definition.

```
2021-08-25 12:25:31,624 1145 ERROR db_23001 odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 424, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 315, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 202, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 370, in init_models
    model.init()
  File "/home/odoo/src/odoo/13.0/addons/stock/report/report_stock_quantity.py", line 126, in init
    self.env.cr.execute(query)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 173, in wrapper
    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.AmbiguousColumn: column reference "product_qty" is ambiguous
LINE 21: ...AND whd.id IS NULL) OR ls.usage = 'transit' THEN -product_qt...
```

upg-23001

closes odoo/odoo#76020

X-original-commit: 07f0ffad
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Steps to reproduce the bug:
- Install sale and inventory
- Create a SO with Qty 10 and confirm it
- Go to the delivery
- Make partial delivery of 5 units and create back-order of remaining 5 units.
- the status of backorder is “waitting”
- Get back to the sale order and cancel it
- the wizard “sale_order_cancel” is displayed, which gives a reminder of some partial deliveries are already done and asks to confirm the cancellation of SO
- Do not confirm the cancellation of SO and click on the cancel button
- Go to the delivery
- The pending deliveries are cancelled

Problem:
The `"action_cancel"` function in the `"sale_order"` model is first called to cancel pending deliveries,
then the `"action_cancel"` function of the `"sale"` model is called, but in that we check if whether one of the deliveries
is already completed in order to display the wizard.

But if the customer clicks the cancel button in the wizard, the SO will not be canceled, but the pending deliveries will already be.

Solution:
Check in the `"action_cancel"` function of the `"sale.order"` model if whether one of the deliveries is already been completed,
if so, do not cancel the pending deliveries and wait for user confirmation in the wizard.

opw-2623404

closes odoo/odoo#75949

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Steps to reproduce the issue:

- Let's log in Odoo with a user U1
- Create a lead with user U2 as salesperson
- Click on New quotation

Bug:

A SO was suggested with U1 as salesperson instead of U2

opw:2520827

closes odoo/odoo#76009

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

Currently, when we try to shorten the links from content with help of
`_shorten_links_text` method, it throws traceback if the body(content)
we pass is `False`(might happen when we directly pass a model field of
textual type but the field doesn't have a value yet). It's because
the `re` expects the content to be string / bytestring.

This commit fixes the issue by adding a check in this method, which
will simply return `False` if there's no body.

Task-2628586

closes odoo/odoo#75987

X-original-commit: 41f59a61
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

When using module `account_invoice_extract`, it would happen that a
bank account of another company was set on the `account.move`.
This happened when the extract update was done in background via the
cron.
A check on the company of the bank account fixes the issue.

opw-2631833

closes odoo/odoo#75989

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>