commit bc1a6faa51fef60bb64ea09f4e43f1120f9855bd add a rule to fix
tracability report but on a global level. However we won't this behavior
everywhere in odoo or at least if it's the case it shouldn't be specify
there

closes odoo/odoo#76701

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

The Italian VAT report is needed to help Italian customers fill in
their VAT report.

Task id #2079462

closes odoo/odoo#76545

X-original-commit: 33ffea3c
Related: odoo/enterprise#20884
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Monday is commonly accepted as the first day of the week in the UK.

Listed as first option on https://www.unicode.org/cldr/cldr-aux/charts/29/supplemental/territory_information.html#GB

 with Sunday as an alternative.
All mayor OS (Windows, Mac, iOS) use Monday as the first day of the week when the locale en_GB is used.

closes odoo/odoo#76539

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

closes odoo/odoo#76451

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

closes odoo/odoo#76674

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

When registering a payment for an invoice using a payment token,
the payment transaction is not correctly linked to the invoice.

This is because the reconciliation is not yet done when processing
the payment transactions.

closes odoo/odoo#75012

Related: odoo/enterprise#20932
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Issue : When selecting mrp_operation as picking_type, the product
variant is not changed

Steps to reproduce:

Install Quality, MRP
Disable variants
Edit View: Form (debug mode) and remove
groups="product.group_product_variant" to show the variants
(This is done so we can see the issue in the backend)
Set a product
Changing product changes the variant
Set the operation to manufacturing
Set another product
-> The variant is not updated
Why is that a bug:
It can lead to some problems if the variants are disabled and then
enabled at a later time for the company

Side-Note:
The original bug related to the related commit was not present in
v13 as said in the related commit opw discussion

Related commit 2dc2003
opw-2515100 (related to opw-2490412)

closes odoo/odoo#76690

X-original-commit: 441fb1e9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>

When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen
but Odoo stopped polling because a connection failure happened.

With this fix we use the remaining_polls already implemented to get the adyen status with a interval of 3 secondes.
If after 3 tries of 3 seconds each it still fails we can retry manually.
Related to dcb1e2b4 and f83d1b13

opw:2587625

closes odoo/odoo#76481

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Add the natural vat number for partners from Uruguay.

closes odoo/odoo#76644

X-original-commit: 35c8fef4
Signed-off-by: Josse Colpaert <jco@openerp.com>

Bug introduced by this commit: https://github.com/odoo/odoo/commit/f05db8b122140a9d0f124484ab22eb094b4e36e9



Steps to reproduce the bug:
- create a journal entry with 4 ”account.move.line”:
    - two `”account.move.line”` with accounts of type ('receivable' or 'payable') > with the amount of both in debit or both in credit
    - two `”account.move.line”` with accounts other than the type ('receivable' or 'payable')
- save
- duplicate the `“account.move”`
- validation error will be triggered: https:github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L3209-L3211

Problem:
The payment terms must be recomputed only if the `”account.move”` is an invoice

OPW-2642826

closes odoo/odoo#76655

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

Issue: When changing the bill date (invoice_date) of a vendor bill,
the due date (invoice_payment_term_id) is not updated correctly

Steps to reproduce :
1) Install Accounting, Purchase
2) Create a vendor bill
3) (debug) Edit the view, remove the invisible attr for the div with
label invoice_payment_term_id
4) For the vendor bill, in that order, set the Vendor, then the due date
to 30 days, then bill date, then add a product
5) Due date is now set to 30 days after the bill date
6) Change the Bill Date
-> Due Date stays unchanged

opw-2627686

closes odoo/odoo#76068

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

1. Create a bank payment P01
2. Create a second one P02
    - Journal: Bank
    - Amount: 123
3. Edit P02:
    - Journal: Cash
    - Amount: 456

Error: A UserError is raised "Cannot create unbalanced journal
entry[...]" This change should be possible.

When changing the journal, the account of the associated moves lines are
not updated. Since the amount is also changed, in
`_synchronize_to_moves`, `_seek_for_lines` is called and tries to find
the liquidity lines thanks to their `journal_id` and their `account_id`
(which, as said above, isn't updated). This lead to incorrect results
and thus, incorrect behavior.

OPW-2568002

closes odoo/odoo#75784

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

1. Define a product [TEST] with automated inventory valuation (AVCO)
2. Define a landed cost product in the same way
3. Create a RFQ for [TEST], Confirm and Receive product
4. Create Bill, add the landed cost on the bill
5. Confirm the Bill and create the landed cost (from transfer of point 3)
6. Create a SO for [TEST], confirm, delivery and create the invoice
7. Generate product margin analysis, [TEST] will be present
8. Register a payment for the invoice (it should have the status 'In
Payment')

Generate product margin analysis again, [TEST] entries will be missing
This occur because, when the invoice is in 'in_payment' state the
records are not taken into account

opw-2631974

closes odoo/odoo#76449

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

closes odoo/odoo#76087

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

Currently, if the user configures his survey with questions of type
'simple_choice', 'multiple_choice' and 'matrix', but doesn't configure any
selectable choices, the survey result page can crash.

This is not really a "standard" use case but this commit adds a few checks to
avoid a complete traceback and instead give empty data results.

Task-2622869

closes odoo/odoo#75586

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

Currently, if the survey participant does not answer questions of type:
- simple_choice
- multiple_choice
- matrix

The system does not register any survey.user_input_line with the "skipped"
attribute set to True. Meaning that this question's answer will not appear in
the survey statistics as skipped (in fact it will not appear at all).

This commit makes sure we correctly save a user_input_line set as skipped=True
when not answering to those types of questions.

A unit test has been added to make sure that we consider every non-answered
question type as properly skipped within the survey statistics.

Task-2622869

Part-of: odoo/odoo#75586

Currently we are getting all records of mailing.mailing instead of
getting only records with mailing_type=mail. This bug was produced
by commit[1].

Now we have computed only that records which have mailing_type = mail,
So we can get perfect count in mail stats button in campaign.

commit[1] -> odoo/odoo@3f6625ef134c35ad8fab00ca99b451a7dfabee08

Task-2417993

closes odoo/odoo#74841

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

Currently, the _recompute_tax_lines method is too long and there is no way to customize the taxes_map before move line creation. This commit adds a hook to be able to customize the tax dict values.

closes odoo/odoo#76397

X-original-commit: 748ac076
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

- Up to odoo 10.0, feedparser dependency was optionally used in the cli of vendored html2text.py
  (see https://github.com/odoo/odoo/blob/10.0/addons/mail/models/html2text.py#L437)
- Since 11.0 (67c17cb3), vendored html2text.py has been removed in favor of maintained package
- Turns out the feedparser part in html2text was dead code for a long time anyway
  (see https://github.com/Alir3z4/html2text/issues/220

)
- So we can safely drop this dependency

closes odoo/odoo#76273

X-original-commit: 271b9468
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

It is currently impossible to create a MO from a mobile if there are
some work orders

To reproduce the issue:
1. In Settings, enable "Work Orders"
2. Create two products P_finished, P_compo
3. Create a BoM:
    - Product: P_finished
    - Components:
        - 1 x P_compo
    - Operations:
        - Create a new one
4. Switch to mobile mode
5. Create a MO with P_finished

Error: When saving the MO, a Validation Error is raised "The operation
cannot be completed: - Create/update: a mandatory field is not set.
[...] Model: Work Order (mrp.workorder), Field: Unit of Measure
(product_uom_id)"

For a work order to be created, the request needs to provide two
additional fields: `product_uom_id` and `consumption`. When setting the
product P_finished, an onchange is triggered and does not return
`consumption`. `product_uom_id` is returned but not included in the save
request (because the field is declared as `readonly`)

OPW-2557181

closes odoo/odoo#76228

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

[FIX] account: Don't generate pdf at all when trying to print a misc operation from the 'print invoices' actions

Before, clicking on 'print invoices' or 'print invoices without payment' on a posted misc operation raised an error message saying that only invoices could be printed. However, the pdf file still got generated and could be found as attachement on the move. With this commit, we don't generate the file anymore in this case.

closes odoo/odoo#76509

X-original-commit: 4c06b3c1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

A while back, the behavior of this setting was changed from a
related field to a computed as a fix to various issues with: cb9f48d3
The setting's value synchronization with what is displayed on the
setting's page is broken, since its behavior changed with commit:
2ccc7352 . It resets to its default value for the default website when
editing a secondary one and is not only confusing but breaks the
setting in some scenarios.

When changing the auth_signup_uninvited setting, the changes
are correctly reflected and not reset to default upon changing
the website we are currently editing.

task-2612686

closes odoo/odoo#76262

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

Usecase:
- 2 warehouses 1 and 2
- Create a route with a rule from inter-warehouse to WH2
- Create a picking type for WH1 for stock to inter-warehouse
- Create a planned transfer with 2 stock.move in the wH1 new picking
type
-* Go back to inventory overview
- Click on process on the picking type WH1 -> inter-warehouse
-* Process the picking created before
- Go to WH2 delivery

You see 2 pickings for each stock.move despite they share the same
data (procurement group, source and dest locations)
If you don't do the steps bewteen *, you only have 1 picking.

It's due to the context of the views that is propagate to the
new picking created by push rules.

opw-2533718

closes odoo/odoo#76438

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

Issue: When viewing a pdf in a website_slide, in certain conditions (
odoo detect the slide is externally embedded), a <iframe> code block
is displayed on the pdf rendering it really hard to read. As a work
around, one could click on the "<\> Embed" button to make it disapear

Steps to reproduce :
 1) Run a local odoo server with the website_slides module
 2) Set up a ngrox tunneling service to your localhost and good port
 3) Find or create a **document** slide and get its id (<slide_id>)
 4) Access the slide via the website url on the slide
 5) Go down the page in the Share tab and copy the iframe
  -Replace http by https in the src attribute of the iframe if necessary
 6) go back to the dashboard, open the inspector and add the iframe in
 the body of the webpage
 -> The slide is correctly detected as non embed
 7) Access your Odoo database with the ngrox https forward (example :
 https://0dfc-2a02-a03f-6b9b-b300-bd6c-8048-90f1-3f25.eu.ngrok.io)
 8) Repeat step 3 to 6 included
 -> The slide is detected as embed, so a <iframe> text area appears
 and make the pdf hard to read

Alternative steps to reproduce :
 1) Run a local odoo server with the website_slides module
 2) Go to the usual http://localhost:8069/ to access your database and
 navigate to a PDF slide in eLearning
 3) Change the localhost in the URL to 127.0.0.1 (Example
 http://localhost:8069/slides/slide/gardening-the-know-how-1 becomes
 http://127.0.0.1:8069/slides/slide/gardening-the-know-how-1

) and press
 Enter to go to the new URL
 4) Change back the 127.0.0.1 to localhost and press Enter to go to the
 new URL
 5) You might have to repeat the back and forth between the two domains
 -> The slide is detected as embed, so a <iframe> text area appears
 and make the pdf hard to read

Why is that a bug:
 It makes the PDF unreadable unless we know that we must click on that
 button, it really shouldn't be like that

opw-2499110

closes odoo/odoo#76447

X-original-commit: 0e9975d7
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>

Tests now check for the 'error' field in Pingen repsonse
snailmail_external_layout.js now targets the right div

closes odoo/odoo#76271

Task: 2588145 & 2583718
X-original-commit: ea1869d0
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

- 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>