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

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Issue:

  When trying to print a Suisse QR bill, if multiple images are presents
  in document and they have a url as src, some pictures will not be
  displayed.
  (Same issue may occur with simple QR code)

Cause:

  It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b


  Also, adding css class to body by js break wkhtmltopdf.

Solution:

  Replace link by base64 image value (use a function to retrieve base64
  image instead of image_url).
  Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
  to this report).

  extra: Alter some css for better rendering.

opw-2620082

closes odoo/odoo#75408

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.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#76063

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

Steps to reproduce the bug:

- Install website_sale
- Go to the shop and select a product P
- Enable ratings on P and add 3 ratings (4/5, 5/5, 5/5)

Bug:

The ratings displayed were 33.3333333... and 66.6666666... instead of 33 and 67

opw:2634167

closes odoo/odoo#75985

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

Remove duplicated entry

closes odoo/odoo#76058

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

When changing the pricelist on the shop, if the new one has a different
currency and if the cart already contains some products, the purchase
price of each product should be updated

To reproduce the error:
1. Select Public Pricelist
2. Add the Customizable Desk (Steel, White)
3. Back to shop, select EUR pricelist

Error: Consulting the SO on back-end, the purchase price is not
converted (and therefore the margin is incorrect)

Changing the pricelist on a SO that already contains some lines is not a
valid flow. Therefore, the fix must only concern the web-shop.

When setting a new pricelist, the request gets the current carte and
forces the new pricelist. Therefore, the cart is updated and several
values are computed again:
https://github.com/odoo/odoo/blob/379f1490c93dc599a74add2d678c18fbba1efa62/addons/website_sale/models/sale_order.py#L142-L149
In the above dictionary, the price unit is based on the new pricelist
(new discount, new currency...). When the module `sale_margin` is
installed, this dictionary should include the new value of
`purchase_price`. By doing this, the `margin` will also have a correct
value:
https://github.com/odoo/odoo/blob/194ce17436929b74fc3d4c2744853d32bd9d2567/addons/sale_margin/models/sale_order.py#L64-L67



OPW-2585376

closes odoo/odoo#75885

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

When changing the company of a partner, if the latter still has some
unreconciled AML, it will lead to a display error on follow-up report

To reproduce the error:
(Need account_accountant. Let C01 be the current company, its currency
is USD)
1. In Settings, enable:
    - Multi-currencies
    - Multi-companies
2. Create a second company C02
    - Currency: EUR
3. Create a partner P linked to company C01
4. Invoice P with X EUR (!)
5. Open the tree view of the follow-up report:
    - P is present in the list with amount Y USD (X has been converted
to C01's company)
6. Edit P
    - Company: C02
7. Open the tree view of the follow-up report

Error: The amount is Y EUR which is incorrect (it should be either Y USD
or X EUR)

The currency used to display the amount is the partner's currency
https://github.com/odoo/odoo/blob/bc53c49c08d48179a7e2d927f3e2b7ba92e77d6c/addons/account/models/partner.py#L391-L391
https://github.com/odoo/odoo/blob/bc53c49c08d48179a7e2d927f3e2b7ba92e77d6c/addons/account/models/partner.py#L377-L382


This is the reason why the display becomes incorrect

Changing a partner's company does not make sense and should not be
allowed

OPW-2525793

closes odoo/odoo#72977

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

This should avoid disrupting layouts.

closes odoo/odoo#75955

Signed-off-by: Olivier Dony (odo) <odo@openerp.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#75829

Signed-off-by: pimodoo <pimodoo@users.noreply.github.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#75621

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

The `update_db_index` method is called even if the field has no index
(the check on `index` field attribute is here on purpose).

Before 13f02a60 was applied, the call of `sql.drop_index` was taking
care of the index existence if a `IF EXISTS` SQL statement, so even if
the field had no index it wasn't causing any issue.

With 13f02a60 applied, the log 'Keep unexpected index' is spam even if
the field has actually no index at all in the database.

This commit ensures to check the existence of the index before logging.

closes odoo/odoo#75387

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

After 0411dda6
the associated test fail in certain time frame due to the datetime check

closes odoo/odoo#75624

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

This commit fixes a behavior when we send a batch of mailings
with no recipients.
When there is no recipients passed down, each mailing should
use it's own recipients and not the recipients of the first mailing.

closes odoo/odoo#75389

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

closes odoo/odoo#75390

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

A stock move with 0 qty in initial demand is considered as 'ready'. But
those stock moves should be excluded of the picking state computation to
not false the readiness of the picking, especially if the delivery
policy is set to 'direct'.

opw-2611018

closes odoo/odoo#75194

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

This commit backports the mobile OS detection support, and specifically
Android & iOS one to allow more specific targeting of edge cases (i.e.
disabling native date picker in the mobile iOS app only).

opw-2613810

closes odoo/odoo#75455

Related: odoo/enterprise#20402
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

New optional 'ttl' parameter for the authorize function. It will allow to specify how much time the credits will be reserved.

closes odoo/odoo#69113

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

- Create a sale order that generates picking and confirm it.
- Validate the picking  when the local DATE and the GMT DATE
are different (i.e. GMT-4, between local 20:00:00 and 23:59:59)

Effective Date will be different in the SO and the picking

opw-2559308

closes odoo/odoo#75170

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

When an index has name 'tablename_fieldname_index', this index is
dropped if the field has index=False.  This lead to dropping a
user-created index or dropping/recreating the index when index=True is
set in a dependent module.  Some info is logged instead.

closes odoo/odoo#66700

closes odoo/odoo#71761

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

With this commit, it will check if the tax name is given by external method and take that name if any.

For example,
vals = {'rate': 5.2, 'name': 'Odoo New Tax'}
tax_template = self.env['account.tax'].search(domain, limit=1)
new_tax = tax_template.copy(default=vals)

Current Behavior:
new_tax.name => 'Odoo New Tax (Copy)'

Instead of 'Odoo New tax'

closes odoo/odoo#74722

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

When creating a new task the name field was not automatically focused.

closes odoo/odoo#75024

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

There's two ways Odoo can get job responses from Gengo: the first is
this callback, initiated by Gengo. The second is a cronjob ran by Odoo
which retrieves translated terms. The callback resulted in a traceback
in the logs, because there was a typo in 'base.gengo.translations' (it
was missing an -s at the end). `json.loads` was also being called with
an unexpected extra parameter ('utf-8'), resulting in another traceback.

This PR fixes both of those and I was able to confirm the callback was
able to update translations in Odoo as a result.

closes odoo/odoo#75230

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

task- 2486484

closes odoo/odoo#74484

Related: odoo/enterprise#19975
Signed-off-by: Josse Colpaert <jco@openerp.com>

Steps to reproduce the problem:
- Connect as admin
- Create a new employee, e.g: “Employee1” for company “My Company (San Francisco)”
- Create a new time off request for this employee, and select a time off type linked to the company "San Francisco"
- create a user and do not give him access to the company “San Francisco”, e.g: “user1”
- Log in as “user1”
- Go to time off > Managers > Allocations > remove default filter

Problem:
user1 is able to see the time off allocation of “Employee1”, even though he does not have access to My Company San Francisco.

Solution:
Add multi-company rules  for the “hr.leave_allocation” model to display only the time off allocations to which the current user has access

A rule has already been added for "hr.leave" model:
https://github.com/odoo/odoo/blob/0f3281e3b1dc943b81d79d2a8f82fca7b95b8186/addons/hr_holidays/security/hr_holidays_security.xml#L65-L70



opw-2535709

closes odoo/odoo#74934

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

In 12.0+ when adding an XI (Northern Ireland) VAT number on a vendor and specifying the country as United Kingdom, an error shows the VAT number as not valid. This is because the method to check specifically XI VAT numbers doesn't recognize XI as a country, and thus uses the GB VAT number verification, which doesn't recognize XI VAT numbers as it isn't up to date yet.

A temporary method to check XI VAT number was already added, but is never called because XI is not recognized as a country code.
With this commit, we add a list of known legitimate country codes, that are not considered as such in Odoo.

opw-2534541

closes odoo/odoo#72910

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#74978

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

Steps to reproduce:

- create a sale order with an event registration,
- on the event, the number of attendees is well computed
- cancel the sale order
- on the event, the number of attendees is still the same as before

Cause of the issue

There was no specific action for canceling a sale order linked
to an event registration

Solution

Add a action_cancel method which cancel also the sale order lines when
canceling the sale order

Also add a test to ensure the flow will not break in the future

opw-2576790

closes odoo/odoo#74481

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

Bug
===
1. Login as "Portal"
2. Go to "/my/opportunity"
3. Create an opportunity
4. Edit this opportunity from the frontend and set the probability empty
=> Save, an error is raised

Technical
=========
The probability is set to "None" and not to "False", therefor the
verification "probability >= 100" in the write method of the lead will
raise an error.

By using False instead of None, this verification will work.

Task-2613208

closes odoo/odoo#74790

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

In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:

- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)

This was solved in pdf.js whith this commit:

https://github.com/mozilla/pdf.js/commit/8805614a03



And this PR is backporting that commit in 12.0 version up to master.

opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311

closes #75020

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce:

  - Install Inventory and Studio modules
  - Go to Inventory -> Products -> Products
  - Open Studio
  - Click on Reports tab
  - Select `Product Routes Report`

Issue:

  Traceback is raised.

Cause:

  No 'product_id' provided in data while getting report values.

Solution:

  If no `product_id` key or value in data, set `docids` (or an empty
  list if no docids) as product_id and set 'warehouse_ids'
  to an empty list.

opw-2619142

closes odoo/odoo#74860

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

Before this commit:
No "image" metadata was available for products on the ecommerce main page (/shop). As such search engines SEO will be less effective.
In the case of the client, using "Google Search Console" would give the message: `Missing field 'image'` as a "Top Warning"

Note:
This issue was introduced by:
https://github.com/odoo/odoo/pull/30656
and was partially solved by:
https://github.com/odoo/odoo/pull/37870/commits/c66892e65d2ae0ca31a686f65d4b517a9d7ffd0b



OPW-2509546

closes odoo/odoo#74880

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

No need to keep it, it's useless and can confuse translators

closes odoo/odoo#74779

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

With the commit some time ago #d3822883, I removed to take the first,
but you can have multiple transfer accounts in one company.

The best way is to just do a limit=1

closes odoo/odoo#44592

closes odoo/odoo#74072

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

Properly set the transfer account in the company taking account the accounts defined in th company domain.  We found this error because in l10n_ar module we have 3 chart of accounts based on the company AFIP responsability which actually have same transfer_account_code_prefix. For that reason it was setting a transfer account to the company which is not belongs to the current company.

closes odoo/odoo#44506

Signed-off-by: Josse Colpaert <jco@openerp.com>