Google maps used to be free, but became a paid API.
Technically, the usage could be part of the free offer,
but to benefit from it the account needs to have billing enabled.
Since it's a paid feature security had to be ramped up,
so now APIs have to be explicitly enabled (here geolocating/geocoding).
All this makes it so that the Google account has to be properly configured
before the calls to the Maps API can work.
As a result we add an explicit UserError if the request fails,
to help the user configure the Google account
(before the error was entirely hidden as to give the user no chance at all).

Also exports transaltions, including for commit e6ca846c
which raised a similar error message if no API key was found.

opw 1946485
opw 1947292
opw 1947337

closes odoo/odoo#32162

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

Oversight of #32079

Some cashdrawers will not open when the command is send. This can be
solved by sending a longer opening pulse.

Used fix of newer library:
https://github.com/python-escpos/python-escpos/blob/0a89ee2b8610452f18b521af71b1ab1af7932894/escpos/constants.py#L40
Explanation for command:
http://www.beaglehardware.com/howtoprogramcashdrawer.html



closes odoo/odoo#32079

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

If the database name contains one of the tested strings, it can render
the assertion of the test invalid or inconclusive. Ensure we strip it
away during the tests.

opw: 1957055

closes odoo/odoo#31987

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

Before this patch, the ir.logging's write_uid field was a many2one which
could cause a module install/update to hang when the module is changing
the res.users model schema and when this module causes to orm to warn
through the logger. (eg: declaring two res.users fields with the same
string attribute)

In such situation the transaction cursor that is processing the
res_users table alteration will be granted an exclusive postgresql lock
hence causing the ir_logging insertion to block because of the write_uid
foreign key to res_users.

This issue has never been raised by runbot as it is using a remote
database with --log-db

Note: the write_uid conversion from m2o to int was left over in commit e6a5d820

closes odoo/odoo#32015

Signed-off-by: Christophe Simonis <chs@odoo.com>

Avoid potential tracebacks from the FSWatcher's thread being killed.

Drawback: Server shut down can have an extra small delay

(only applies when the --dev=reload option is given)

closes odoo/odoo#31855

Signed-off-by: Christophe Simonis <chs@odoo.com>

Add the alternative of inotify instead of watchdog to watch the addons
paths the server was started with.

Reason: watchdog spawns 2 threads per path to watch. When there are a
lot of addons paths, this can become too costly. With inotify we watch
all the repositories in a single thread.

https://github.com/dsoprea/PyInotify

installation:

    pip install inotify

Before this commit every worker would start his own FSWatcher.

Python2 uses IOError instead.

/!\ DO NOT FORWARD PORT AFTER 11.* /!\

We set the default rate to be 1.0 instead of 0.0, since a rate of 0.0
doesn't make sense.

Partial backport of 29849159

opw-1949866

closes odoo/odoo#31866

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit iteration in a t-foreach containing null or
undefined values crashed because they have no attributes.

closes odoo/odoo#31828

Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.com>

Intrastat was modified on january 2019 to backport some features for new
regulation of belgian intrastat in c5a8e397.

There was a coding typo so EXTRF was <Report/> code attribute instead.

sources:
 https://www.nbb.be/doc/dq/e_pdf_ex/docxml-en.pdf
 https://www.nbb.be/doc/dq/f_pdf_ex/docxml-fr2019.pdf



opw-1948336
closes #31875

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

The customer display used only a small part of the available width.

closes odoo/odoo#31865

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

- When creating a user from the "Grant Portal Access" wizard, the code
  checks for duplicate users.
  It does so by checking if there is a user with the same login as the
  one we want to create.

  The check is case sensitive which could lead to issues.
  For example a mistyped email (with a uppercase somewhere) could fail
  the duplicate user check.
  Since emails are not case sensitive, we want the check to be case
  insensitive too.

  OPW-1932918

closes odoo/odoo#31818

Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>

This is related to issue #31549, fixing it in 10 since it's already a
minor issue here (importing 500 partners which all have the same parent,
on my system the import time goes from 2:30 to 2:00).

This is mostly a problem for such fields as `property_product_pricelist`
(added do the commercial fields list by `product`): since we're first
getting it then writing a field it depends on (updating the address,
which contains the country), the field gets invalidated for all records
on each record being imported, so if we're importing a bunch of partners
which all have the same parent (e.g. company employees)
`property_product_pricelist` is going to be re-computed for every
partner imported so far as well as the one parent we're interested in,
for every new partner we're creating.

The problem is much more prevalent with 12.0's batched creates as we're
first creating all the new partners then doing the updates, and thus for
each new partner we're computing `property_product_pricelist` for all
new partners and the one parent we're interested in, roughly doubling
the import time of a series of partners which all have the same parent.

closes odoo/odoo#31804

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

Sequel of cc54194e.
The mentioned fix only worked when the user was public.

The problem arises when calling the function `_get_fpos_by_region()`
in `sudo` without specifying the company and this happens, for instance,
in every `onchange_partner_*` function of a sale order.

We propose to add the `force_company` key in the context of the sale
order to ensure the right company when selecting the fiscal position.

closes odoo/odoo#31751

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

- Fixes incorrect user type assignments on some accounts
- Fixes incorrect account assignments on taxes
- Adds a few accounts that Japanese companies would typically need
- Changes some account codes to make the structure more consistent
- Updates descriptions of some taxes to make them appear more natural
  on PDF reports

closes odoo/odoo#30780

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Authorize.Net is phasing out the MD5 based hash use for transaction response
verification in favor of the SHA-512 based hash utilizing a Signature Key.

Instead of hashing with md5 the transaction key, it is now required to hash
the signature key (binary format) with SHA-512.

Support for MD5 will be dropped the 7th March 2019 for sandbox environment and
the 28th March 2019 for production environment, initially planned for the 14th.

Note that as of February 11, 2019 authorize removed the ability to configure or
update MD5 Hash setting in the Merchant Interface.
Merchants who had this setting configured have been emailed/contacted.

opw-1943030

Usefull links:
https://developer.authorize.net/support/hash_upgrade/
https://support.authorize.net/s/article/What-is-a-Signature-Key
https://support.authorize.net/s/article/MD5-Hash-End-of-Life-Signature-Key-Replacement
https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD5-to-HMAC-SHA512-and-how



closes odoo/odoo#31642

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

The text was in a value tag, making it untranslatable

Closes odoo/odoo#30774

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

Include cristinamartinrod in CLA of Tecnativa

Needed for odoo/odoo#30774

When creating a cart on the website, the website company was not
considered which could end up with the selection of a fiscal position
linked to a wrong company since the method is called in sudo.

closes odoo/odoo#31673

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

To avoid exception:
  TypeError: Mixing apples and oranges: gamification.badge() - gamification.badge.user(1,)

when rule_auth of a badge is set to `having`.

opw-1945440
closes #31436
closes #31595

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

closes odoo/odoo#26220

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

Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).

However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).

Fix by using proper version parsing and comparing the result of that.

See also: odoo/odoo#28116

closes odoo/odoo#31553

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

The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).

But the feature was broken at a point, and has been solved in 11.0 with
7c7b0992.

This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.

This changeset is only for 10.0 up to saas-15 to implement the fix
differently.

opw-1945417
closes #31475

Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.

closes odoo/odoo#30545

On some devices and chromium with printing option "Background graphics",
a printed receipt on the point of sale could have a black bottom below
the receipt content.

This is caused by the point of sale black background and happen rarely
because most frequently browser printing remove backgrounds.

opw-1940434
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
closes #31472

As signed at opw-1944366

closes odoo/odoo#31413

Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.

The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().

See tests for a clearer view of the use cases.

Fixes #30113, #26540

closes odoo/odoo#31202

The admin can decide to publish/unpublish messages in the comments
of a product from the website. The button is also shown for notes
even if they are never published.

opw-1935337

closes odoo/odoo#31420

When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.

At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.

We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)

opw-1925547

closes odoo/odoo#30154

closes odoo/odoo#31373

- Switch to French language
- Go to Inventory > Inventory Adjustment
- Launch an adjustment

The field 'Real Quantity' doesn't follow the float formatting.

This is because the widget is set as `field_float_scannable`, which is
not recognized by the formatting function.

Since the widget descriptor has priority over the type descriptor, we
must explicitly take this widget into account, on top of adding the
`format_value` method.

opw-1940884

closes odoo/odoo#31366

Apply e1767490 to SO count in order to
take into account all children, and not only direct children.

opw-1941335

closes odoo/odoo#31329

- When changing the user of a `hr.employee` record, access rights errors
  could be triggered.

  Those errors are triggered when a record (for example a leave) is
  linked to this employee and the current user has limited write
  accesses by record rules on this record.

closes odoo/odoo#31032

- Go to Inventory > Reports > Inventory Valuation
- Select the pivot view

The top row (containing the Total) has an empty 'Inventory Value'.

This is because there is no domain on the line, so it is skipped.

We fall back on the global domain instead.

opw-1933191

closes odoo/odoo#31280

On IE11, in 10.0 up to master in some instance when creating a record
under some conditions the dropdown may be automatically opened and need
to be closed.

This has been pinpointed to 90c1af11 so it seem that a combination of
fields/code/autocomplete and changing the placeholder at one time causes
the issue.

Since IE11 lie and say it is mozilla 11.0 we just apply the 90c1af11
when the browser is chrome (we did no did this at first to have the same
behavior accross browsers).

note: there is an opened bug in chromium https://crbug.com/928305 if
solved the hack could be removed completely.

opw-1940592
closes #31271

Before this patch, any exception raised by a constraint method that
were not of type `ValidationError` were hard to debug, because the
origin line was never logged.

Explicitly logging the error (with traceback) when we catch it
ensures proper contextual info, even in the absence of exception
chaining.

closes odoo/odoo#28612

There is no `company_id` field on `stock.picking.type`.

Partially revert f221936f (#30952)

closes odoo/odoo#31121