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

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>