For status images

closes odoo/odoo#78666

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

When importing bank statements, we are filling in automatically the bank account
id if an existing record matching the number is found. However, we should restrict
the search to retrieve only bank accounts belonging to the current company,
otherwise it will create a multi-company inconsistency.

closes odoo/odoo#75769

Signed-off-by: Olivier Colson <oco@odoo.com>

scrap_qty field was missing the digits attribute, and therefore the user
could not create a scrap with a quantity with more than two decimal places.
With this commit, scrap_qty will follow the 'Product Unit of Measure'
precision setting, just like any other quantity fields.

closes odoo/odoo#77652

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

Perform fetching, using `read` or `_read_from_database` on matched debit
and credit takes a huge amount of time, if there are too many acml being
processed. Delay fetching to `mapped` improve the performance greatly.

closes odoo/odoo#75969

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

Purpose of query counter tests is to try to match real life use cases. In
mail those generally involve a correctly configured mail gateway. This is
why we set those parameters in performance tests, leading to a small increase
in some counters.

This is done in stable to better see evolution of those counters in various
stables.

Task-2661036
Prepares Task-36879 (MultiCompany Aliases)

closes odoo/odoo#77734

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

Before this commit:
If the "Base: Auto-vacuum internal data" is archived since a long time, auto-vacuuming models may timeout. As the commit was previously done at the end of the cron, the process wouldn't have been applied. As a consequence the Scheduled action will timeout every time

After this commit:
The commit is done right after each model vacuuming

OPW-2638706

closes odoo/odoo#77730

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

Bug introduced by this commit: https://github.com/odoo/odoo/pull/76965/commits/509db2371f9122a47af867e3b90841e115c712cf



Steps to reproduce the bug:
- Install purchase and mrp
- Add to “Marc Demo”, user access rights only for purchase app
- As demo, Create a PO and add any product
- Confirm the PO

Problem:
An access error is triggered when searching for a BOM linked to the selected product in the POL

closes odoo/odoo#77731

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

51955505 mitigated an issue of being
able to try and download files which don't exist yet, make the fix
more reliable by clearing out the field completely and hiding the
content if the (readonly) field has no value *or the record is not
saved yet*.

Also clean up the code:

* an old-style forward port created a duplicate fixprovement
  (a8d01cbf) which seems less correct
  as it applies conditionally
* and the code is branchier than necessary, we can make it simpler by
  judiciously leveraging jquery's API

closes odoo/odoo#77695

X-original-commit: 0eccd397
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Steps to reproduce the bug:

- Let's consider two companies C1 and C2
- Let's consider two production locations L1 in C1 and L2 in C2
- Let's consider that the company of SUPERUSER is C1
- Add the field Production location in the form view of mrp.production
- Log in C2
- Create a product P with a BOM in C2 with L2 as production location
- Create a MO for P

Bug:

The production location of P was L1 instead L2

PS: related_sudo is set to True by default.

opw:2196707

closes odoo/odoo#45307

closes odoo/odoo#77334

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

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>