Google Important Updated: API keys are now required
We began enforcing the use of API keys, effective June 11th 2018.
Keyless usage will result in a degraded experience, or an error.
https://developers.google.com/maps/billing/important-updates
It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
For an unknown reason, in some case, urllib doesn't work while with urllib2 it works.
Since we don't have the opposite case until now (work in urllib and not urllib2), we
considere that it fixes the issue.
this commit closes#14636
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
[ADD] base_geolocalize, holding partner latitude, longitude and stuff necessary
for geo-localisation. This module will be used for the website, to be able to
use geo localization without having to rely on crm_partner_assign.
crm_partner_assign now contains the logic related to partner assignment and
opportunities geo localization.
bzr revid: tde@openerp.com-20131007144135-mwnpdznojr0ece7u
Christophe Simonis