- Before this commit, When user with restricted rights
tries to edit frontend page and without changing anything click
on save button generate traceback due to invalid return type.

- After this commit, On hitting save button on restrict mode resolve
the traceback by changing function return type to promise.

task-2379101

closes odoo/odoo#66357

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

Steps to reproduce the bug:

- Open a customer invoice I for a customer C
- Remove the country from the address of C
- Click on button Print & send on I
- Set the country of C with CTR
- Click on Update and send

Bug:

The country of C was not saved.

opw:2633425

closes odoo/odoo#76023

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

- Activate multicompany
- In the company switcher select all company
- Launch a pos session
--> Issue all rpc request are make in all companies (len(self.env.companies) != 1). It create some error with taxes, fiscale position, ...

closes odoo/odoo#76393

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Merge fixes coming notably from community reporting.

Containing
    [FIX] mail: handle wrong Final-Recipient header in incoming emails
    [FIX] mail: handle parsing of void body in incoming emails
    [FIX] mail: fix ACLs issue with mail composer in new mode
    [FW][IMP] test_mail: test models with type do not mess with attachmen…
    [FIX] mail: prevent useless write when pinning a channel
    [IMP] base: merge activities of merged partners

See sub commits for more details

Task-2641572

closes odoo/odoo#76159

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

When merging partners through the ``base.partner.merge.automatic.wizard``
wizard, messages and followers are merged. However activities are not
probably because its underlying model is "newer" then messages and followers.

This commits fixes that behavior.

Task-2641572
PR odoo#76159
Closes #71654

Part-of: odoo/odoo#76159
Co-authored-by: Thibault Delavallee <tde@odoo.com>

When having an active livechat, we could end up with a lot of query errors
like

```
2021-08-30 [...] "POST /web/dataset/call_kw/mail.channel/channel_get HTTP/1.0" 200 - 104 0.151 0.075
2021-08-30 [...] ERROR production odoo.sql_db: bad query: UPDATE
  "mail_channel_partner" SET "write_uid"=2,"write_date"=(now() at time zone
  'UTC') WHERE id IN (365007)

ERROR: ERROR:  Could not serialize access due to concurrent update
```

Avoiding unnecessary writes helps reducing concurrent updates.

Task-2641572
PR odoo#76159
Closes odoo#75745

Part-of: odoo/odoo#76159

Purpose of this commit is to highlight an issue that may happens easily with
`crm` that is made generic here within `test_mail`.

`crm` alters the context when creating a new record adding in this case
`default_type` to it][1]. The returned record contains that altered context.
his results in other records created from it trying to assign that same default
value for `type`. This is a very common name for fields, and happens to exist
in `ir.attachment` too.

If you create an alias for incoming leads in your DB with default values
`{"type": "lead"}` (something very common) and then an email comes to that
alias that contains an inlined base64 image, the attachment creation process
would simply fail.

Obtained error is ``ValueError: Wrong value for ir.attachment.type: 'lead'`` .

[1]: https://github.com/odoo/odoo/blob/272602193f5647f7f2270ed6ec68777625a139dd/addons/crm/models/crm_lead.py#L310-L311



X-original-commit: 890a91f5
Part-of: odoo/odoo#76159
Co-authored-by: Thibault Delavallee <tde@odoo.com>

As create_uid has no value on mail.compose.message model when being in onchange
or new mode, 'Mail Compose Message Rule' record rule may crash. In this
commit we fix that issue by adding a value for create_uid. An unit test is
added to ensure it effectively fixes the use case.

Steps to reproduce this warning:
 1. Create automated action for the 'mail.compose.message' model
 2. Try to open 'Email compose Wizard'

Warning:

"Due to security restrictions, you are not allowed to modify 'Email composition
wizard' (mail.compose.message) records.

Records: mail.compose.message,NewId_0x7f8e99762310 (id=NewId_0x7f8e99762310)
User: USERNAME (id=2)

This restriction is due to the following rules:

Contact your administrator to request access if necessary."

Task-2641572
opw-2628005
PR odoo#76159
Closes#75369

Part-of: odoo/odoo#76159
Co-authored-by: Thibault Delavallee <tde@odoo.com>

When body does not contain any tag or content parsing currently fails
with an ``lxml.etree.ParserError``. To avoid that we can improve condition
about void body: stripping void characters allows to avoid that traceback.

Task-2641572
PR odoo#76159
Closes odoo#75625

Part-of: odoo/odoo#76159
Co-authored-by: Thibault Delavallee <tde@odoo.com>

Some emails are wrongly formatted mainly due to old servers. If Final-Recipient
header is void or wrongly encoded it currently crashes. This fix ensure there
is no crash, even if bounce detection could be incomplete.

Task-2641572
PR odoo/odoo#76159
Closes odoo/odoo#75618

Co-Authored-By: Thibault Delavallee <tde@odoo.com>

Description of the issue/feature this PR addresses: Fixes #76177

Current behavior before PR:
Before this commit, There will be tracback on adding new
Journal Item if there is not date on Journal Entry.

Desired behavior after PR is merged:
Now we use current date to as fallback to convert currency.

closes odoo/odoo#76178

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Issue: When resequencing an account_move, the chatter showed the
resequencing but also a ghost change of state from draft to posted

Steps to reproduce :
 1) Create an invoice and post it
 2) Look up the journal entry for the invoice and resequence it to some
 arbitrary other name
 3) Check the chatter for that invoice, it shows a change from draft to
 posted

Why is that a bug:
 The state isn't changed so it shouldn't be logged

Side-Note: I don't understand why in the code until this commit we had
to force change the state to draft to change the name of the move, when
I tested, we can change the name of a posted move without any issue

opw-2581248

closes odoo/odoo#75620

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

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>