Steps to reproduce the bug:
- Create a BOM kit for “product K”  with:
    - 2 * “product A”
    - 1 * “product B”
- Create a PO for 1 unit of “product K” > confirm
- A receipt delivery with 2 units of “product A” and 1 unit of B will be created
- Modify the ordered Qty to 2 units of “Product K”

Problem:
The receipt delivery will not be updated correctly (4 units of product A and 3 of product B)
because the `"_prepare_stock_moves"` function computed the previous quantity wrong based on the moves quantities
since the moves are for products A and B, not product F.(do not take into account the products in kit)

Solution:
For kit products, do not calculate from the `"stock.move"`, calculate the difference between the quantity before and after the change

opw-2645719

closes odoo/odoo#76965

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

With the previous fix, tax groups would not work correctly when checking
if a tax affected a subsequent tax.
With this fix, all taxes that are not of amount_type group are aggregated
before following the normal flow.

opw-2497281

closes odoo/odoo#76855

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

Suppose a PO that has been generated thanks to reordering rule. When
changing the product of a line, if the user runs the scheduler, the old
product won't be added to the PO

To reproduce the error
1. Create a product P:
    - Product Type: Storable
    - Purchase: Add a vendor
    - Reordering rule:
        - Min = Max = 1
2. Run the scheduler
3. Update the generated PO:
    - Change the product of the line
4. Run the scheduler again
5. Open the PO

Error: The PO only contains one line (the one with the other product).
The PO should now contains a second line for P

OPW-2538707

closes odoo/odoo#75333

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

The registry attributes 'registry_invalidated' and 'cache_invalidated'
are used to flag that the current request has modified the registry or
invalidated the ormcache, respectively.  This provides a simple yet
efficient way to signal registry changes or cache invalidations to other
workers.

However, those flags were not meant to be used with multi-threaded
workers.  For instance, a thread may signal registry changes that are
actually made by another thread.  It can also happen that a thread
changes the registry, which makes another thread crash (like a thread
modifying a dict while another one iterates over it), and the latter
will reset the registry to its original state because it misinterprets
the registry changes as its own changes.

The situation can even get worse, making threads crash in cascade and
eventually leaving the registry in an inconsistent state.  When this
happens, the worker is broken and has to be manually restarted.

The fix consists in making those flags thread-specific.  This does not
prevent thread crashing because of concurrent changes, but at least it
avoids leaving the worker in a broken state.

closes odoo/odoo#77178

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

Module `account_check_printing` exist on community edition so
It doesn't makes sense to apply `upgrade_boolean` widget on that.

However, It is necessary to have supported modules installed to
use Check Layout.

closes odoo/odoo#76989

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

Magic return image/svg instead of image/svg+xml if file starts with <svg

closes odoo/odoo#68211

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

closes odoo/odoo#76817

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

Suppose the TZ is UTC+12 and a user creates a new rate in the morning:
the date will be the day before

The default date should consider the user's timezone.

OPW-2590972

closes odoo/odoo#76513

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

Update header message to match changes in the following commit:
https://github.com/odoo/odoo/commit/8ba6e3b0c3bf856308b4d58158392d0e99d2b58e



opw-2631125

closes odoo/odoo#76748

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

This reverts the following commits: https://github.com/odoo/odoo/pull/72977/commits/acdc4547fb6f6128debc3ff1f4cbf5b2f772239f



The fix we initially made did not cover every possible scenario.

Steps to reproduce the bug:
- Install accounting
- Connect as admin in a multi-company environment, e.g: “Mitchell Admin”
- Go to the related partner form's view linked to “Mitchell Admin”
- in the “Sales & Purchase” tab > set this partner as a vendor and select the current company in the company field
- create a bill in accounting and choose “Mitchell Admin” as vendor > save
- Try to switch from a company to another
- Validation error is triggered

Problem:
When changing the current company of a user, the company of the partner linked to that user will also be changed.
So the constraint check “_check_company_and_invoices” will be triggered

OPW-2642942
OPW-2641402
OPW-2641399
OPW-2639942
OPW-2643541
OPW-2643399

closes odoo/odoo#76434

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

Facturx expects line price to be subtotal, not unit price. Odoo parser
is also dividing the gross price by quantity. So before this commit,
importing PDF invoice rendered by Odoo, results in: unit price / quantity.

The bug was introduced in odoo/odoo#53894

closes odoo/odoo#70785

Signed-off-by: Laurent Smet <smetl@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#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>