For reports fetched through this endpoint, the error would only be
reported to the client, which may well ignore it entirely (e.g. show a
completely generic message which might as well be unhelpful and at
worst aggressively misleading).
Log the error locally before returning it to the client, so the info
is at least in the logs.
closesodoo/odoo#57411
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Doesn't seem used since it's been broken forever on python 3:
base64.b64encode returns binary data, on which json.dumps chokes.
Still, removing the endpoint on old stables seems a bit brutal so just
fix it.
closesodoo/odoo#56650
X-original-commit: 7fc9bc28986d69184df5a4fdeefbe09e4b39b8f0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
/web/action/load is the public controller that Should be used by the
webclient to fetch actions
_for_xml_id is the default access method on actions that implements
fields filtering to avoid leaking server action code or other
information not needed by the webclient
Implementing whitelist of fields that can be access per model
New module for supporting two-factor authentication via time-base
one-time-password (TOTP).
Users (including portal users) can choose to enable two-factor auth in
their user account settings, by scanning a QR code and adding it to an
authenticator app, such as Google Auth, 1Password, etc.
When two-factor is enabled, password-based non-interactive RPC is only
possible by using API keys.
Co-authored-by: Olivier Dony <odo@odoo.com>
Before this, invalidations to the UID cache is not synchronised
between workers because it's an ad-hoc solution (so a user changing
their password or an admin disabling a user would only lock out an
attacker currently using the API of one of possibly several
workers). Shift the entire thing to ormcache which already has proper
support for synchronising cache invalidation between workers.
Also simplify the cache invalidation mess in Users.write because the
caches have been unified into a single registry-level LRU, so the
half-dozen cache clears on specific ormcached methods & models is
pretty much the same as repeatedly calling clear_caches on the current
model.
**However** registry.cache is trivially accessible from server actions
and safe_eval as long as they provide access to a model (through
`model.pool.cache`). Which is common, and an issue given we're very
much putting sensible data in there.
Fix this by renaming `Registry.cache` to `Registry.__cache`, this
requires few editions and mangled names are not accessible from
safe_eval contexts.
The alternative would have been to add more bespoke handling of the
uid cache to hook it into the cache invalidation propagation
machinery.
After discussion with (@)odony, fixing LRU access and using that seems
cleaner and less error-prone.
Note on lazy_property
=====================
Make Registry.cache / Registry.__cache into a regular attribute: the
overhead of the LRU is not that high (compared to that of the registry
itself), it's rare that we *don't* need it, and it's assumed to be a
persisted attribute (it's not just a cache) so making it a normal
attribute seems fine; and lazy_property doesn't work for mangled
names: the name of the property is mangled using the name of the
definition class, but the name of the symbol (fget) is not mangled so
lazy_property would set the __cache attribute but then Python would
lookup _Registry__cache, creating a new cache every access.
And we can't (always) mangle things correctly on `__get__(obj,
owner)`: `owner` is just `type(obj)`, meaning in the case of
inheritance the type we get is the type through which the property is
accessed rather than the one it's defined on. So it would work in the
cases where no inheritance is involved (such as Registry.__cache) but
not in general (lest we want to play around walking the MRO ourselves
to find the definition source, which doesn't seem worth it).
lazy_property *could* be made to work properly on Python 3.6+: the
descriptor protocol gains `__set_name__(name, owner)`, which is called
with the properly mangled name — and with the definition class to boot
(though there might still be issues when overriding lazy properties as
the override will be mangled & named differently... or maybe that's a
feature?). However we're still supporting 3.5 at this point, AFAIK, so
that's not an option. Plus it feels unnecessary / not very useful.
However add an assertion to `lazy_property` so it signals when we try
to use it on a mangled method (as otherwise it kinda sorta work in the
sense that the property / object is accessible but is in effect a
slower way to write a regular property).
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
- Install Sales and Accounting
- Go to Sales > Orders > Quotations
- Create a new quotation
- Add a product and in Order Line form, select a tax
- Save the Order Line
- Save the quotation
- Go back to quotation list
- Select (checkbox) the created quotation
- Select "Export" in Action menu
- In export wizard, choose "Excel" format and add field "Tax amount by group"
- Validate with "EXPORT TO FILE"
An error is triggered.
The issue comes from the fact that the value of "amount_by_group" is an array of tuples
and "xlwt" cannot write that type of value.
opw-2255054
closesodoo/odoo#51480
X-original-commit: dde2ca9943362b20853ab11b15fe1504c0b8d848
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When creating a new database, a random master password for it is
generated and strongly suggested to be used.
The motivation for this change is to have, by default, a secure master
password set for any Odoo deployment.
Often, users do not realise that, when making an Odoo installation
accessible on internet, anyone else can also access it.
Use autocomplete="new-password" for updating the master password and
play nice with password managers
When generating a new password, use autocomplete="new-password" as
well to prevent autofill of password potentially saved in password
manager.
Make the eye click to toogle on click instead of need to maintain.
closesodoo/odoo#45117
Task-id: 2091260
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Steps to reproduce:
- install sales
- go to sales > go to any list view (SO for example) and group by
anything (customer for example)
- click on action > export > add ID to the exported columns
- click export
Previous behavior:
you get a traceback: "Invalid field specification '.id'."
Current behavior:
ids are exported as intended
opw-2194233
closesodoo/odoo#48222
X-original-commit: c8217080d960ec3f8436111ce60a17754fe64f2d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
- Open any product kanban view with missing images
A 404 status code is returned for missing images, while they are
replaced by a placeholder.
This can cause issues when configuring a specific 404 page in a reverse
proxy: the proxy will serve the custom page instead of the placeholder.
opw-2192663
opw-2192340
closesodoo/odoo#45157
X-original-commit: 2719c8a0e40f318787b4d7a46626de46a8fd33f0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
A good practice is to always prefix the name of a template by
the name of the module it is defined in.
So in the case where a template
```xml
<t t-name="module.template" />
```
was inherited by another
Before this commit, one should have written
```xml
<t t-name="other" t-inherit="module.module.template" />
```
After this commit, it becomes more natural, and one should only write
```xml
<t t-name="other" t-inherit="module.template"/>
```
Login in into a database
Access the database manager
Duplicate a database
Internal server error will occur and display user. This should not
happen (even if the database is duplicated just fine), and occur
because after the duplication the connection is dropped but the cursor
will still hold the old reference and then, in the response generation
it will crash.
Invalidating cursor right after the duplication, like what is done after
a 'drop' operation fix the issue
opw-2170974
closesodoo/odoo#44159
X-original-commit: 59553c8595cdaf50a4c6f3ffe4093116d0f48bf1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This controller is no more used, probably used in the past with calendar invitation.
closesodoo/odoo#43657
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
1/ When the new database is created without demo data, the admin has a
'silhouette' as a default picture. When a new user is created without
picture given by the current user, the new user will have a 'silhouette'
as a default profile picture.
2/ web: image for fa-user-slash. This image will be used when a record is
unassigned.
3/ web, *: Change placeholder by default when record is unassigned.
We want to have a fa-user-slash icon when a record is unassigned instead
of 'placeholder.png'. A method is created in the BaseModel to have a
generic method to change easily the placeholder for other models.
4/ Adapt kanban test to keep the same behaviour. Attention the behaviour is
a bit different. Because, now the default image is given by the server to
change easily the default image when a record doesn't have an image.
Thus, we don't say if it's the default placeholder, but we can say it's
not the same image of the record (in this test, the record, it's the
partner).
5/ misc: display 'Unassigned' in the hover on kanban cards if record is unassigned
closesodoo/odoo#41356
Taskid: 2060206
Related: odoo/enterprise#7758
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: jdoutreloux <jud@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
This commit splits the _content_image method to allow to call the
get response part individually.
This is needed because _content_image call binary_content using current user
access. But in some cases, we need to render a binary content even if the user
does not have access to the target model (typically for public users).
The binary_content is gotten in sudo mode where needed and the result can be
given to the _content_image_get_response.
This will avoid code duplication where the sudo use case is met.
Usage :
This commit prepare the redesign of survey. This _content_image_get_response
method will be called to grant access of background image even for public
users. Other modules will use this new method like elearning (website_slides)
to display karma ranking, etc.
Task ID: '2150291'
PR #43237
New component: the custom file input. Its purpose is to define a input of type file
with a custom trigger (button, link, etc.).
Its construction is the following:
- attributes: behaviour of the actual input (route to call, multifile, allowed
extensions etc.)
- inner template: the trigger that will fire the upload prompt when clicked
Once a file has been uploaded, the component will emit a 'uploaded' custom event
containing the files.
closesodoo/odoo#38423
Related: odoo/enterprise#6031
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When expending a many2x record, a field named 'name' was used to
represent the exported record.
If there was no field 'name' on the record, expanding the many2x field
raised a KeyError in the export screen with "import-compatible export"
enabled.
Use the _rec_name instead as fallback
closesodoo/odoo#42004
X-original-commit: 914d4f8ce9dbfd8380caa429a0aeac0513cf5ff9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, when doing a primary inheritance
the root node of the resulting template was the one of the inherited template
after this commit, the root node of the resulting template is the one defined
on the inheriting template
closesodoo/odoo#39452
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a template was inheriting from another
the template mentionned its t-inherit
This has been deemed overkill as the information is irrelevant to the caller
i.e. the caller just wants the template and doesn't care how they've been computed
After this commit, only t-name and attributes not related with inheritance
are disclosed
[FIX]: base: static inheritance propagates other attributes
When doing a inherit in primary mode, the original attributes on the root node of
the inheriting template were not propagated
After this commit they are
At the conception of this feature it has been intentionally thought that
the behavior for static templates should resemble
what is done for ir.ui.view
While keeping the general previous behavior (and this is important)
A little bit of context for ir.ui.view
They are defined as XML's, but end up as python objects
Their meta-data (id, name, inheritance specs...) are thus
present in their XML definition, but end up as part of python objects members
Hence, the final, business, usable arch is free of those meta-data
and is left only with business-relevant dom nodes
The static inheritance feature was backed with those ideas
but inherently encountered the issue that, for them,
the meta-data also end up in the business dom, since
they are at no point considered as plain objects.
Decision has been made, back then, to exclude the root node
that holds the metadata, to be at all targeted by any XPATH
This decision is now challenged as the specs of XPATH should be respected
This commit consequently introduces the root node as any other
It can be replaced, and will be targeted by
`expr="."` or `expr="//NODE_TAG"`
The few attributes that are necessary to define them are kept across
inheritance cycles though.
The attribute `self._fields` is not well named. This is not a list of instances
of the Field class.
It is a list of field names to export.
e.g. 'journal_id', 'account_id/name'
X-original-commit: 6225ce60082d5d2b5fec0e678fe2a1f3f9b93668
When exporting a grouped list view with some nested groups, the aggregate value
of parent groups are not correct. It always sums aggregated values of children
whether the group operator is 'sum' or not (could be 'max', 'avg', ...).
This behavior is wrong and can even lead to a crash if the aggregated field is a
date field (e.g. with group_operator='max'). (Try two sum two dates...)
The quick fix 85cf47f was merged just before OXP to avoid any crash. This fix
limited the support of aggregates to only int and float fields.
This commit remove this limitation.
This commit correclty implements the aggregation for parent group for all
field types and all group_operator.
This commit also improves the export feature tests.
X-original-commit: 5e7e4fa98698967e3c4fd0903f4aa8e91981a6cd
Before this commit, when we export a list with a groupby on
boolean, the groupby title 'False' is replaced by 'Undefined'
in xls document.
After this commit, with an export and groupby on a boolean, we
will have correct title: True and False.
X-original-commit: 7e2c7bc35f2a5b3bc22e0e6c9d3b38279cda9367
This controller never really worked in the last 3 versions.
It was fixed in 11.3 with e9350993ca but broken with refactoring in 12.0 at a
higher level with 19eacf7d23.
It was even worse in 13.0 as it was leading to a traceback: `view_type` field
got removed with 3cd7ed07a2 but this controller was still reading that
field.
closesodoo/odoo#38355
X-original-commit: a5c4e262449fef03d05d5250e4523832db5fbf00
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Fixes#33254:
* was in mail despite using mail.channel (which breaks if mail is not
installed, and web doesn't depend on mail)
* changes to sudo() broke previous behaviour (of having odoobot
message the admin, we ended up with the admin messaging themselves)
so fix that
* also get the channel and message with the user's context, otherwise
since we're during the login procedure the context could be as
little as just the lang from the browser and apparently channel_get
automatically creates a translation which would break if the
browser's lang is not installed in Odoo
closesodoo/odoo#37580
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* base, web
Google now recommends a TTL of one year for static contents. We used to
use 1 week in almost every case. This commit increases that value to one
year for safe resources, like assets bundles which contain a specific
hash in the URL which changes if the bundle is recomputed anyway.
Note: this commit refactors the code so that both the one week and one
year durations are defined in http.py and used by others apps. Loading
the library "locale" file used to be done with 10-hours-cache, this has
been increased to 1-week-cache by using the http.py STATIC_CACHE var.
closesodoo/odoo#37402
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
The commit 2849b5c introduces a new export mechanism of grouped
list views to xls files.
The issue with this development is mainly that the displayed records
are exported, instead of all the records that match the search
parameters.
To export all the records we cannot rely on the data from the web
client. This implies to revert 2849b5c, and implement it in a better
way.
Functional Spec
===============
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
Technical Spec
==============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export
shortcut should be displayed
Task 2072910
closesodoo/odoo#37087
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=======
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
SPECIFICATION
=============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export shortcut should be displayed
Task 2072910
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In case the context was manually passed to report_download, #36839
would pass the context keyword argument twice to report_routes.
That is not allowed in python so we update the current context with the
custom context from the report and pop the custom context from the
arguments
closesodoo/odoo#36989
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
[PEP-594] is deprecating the `imp` module, that module is used in
`module.py` in order to dynamically import addons using any of the
`odoo.addons` or `openerp.addons` import anchor.
We are deprecating `openerp` module/addons imports in v13 in order to
remove the support in v14 and greatly simplify how modules/addons are
loaded. If you are still using the old `import openerp` or `import
openerp.addons`, `import odoo` and `import odoo.addons` are drop-in
replacements.
The `odoo.modules.module.ad_paths` addon paths list has been deprecated
too. The list is now accessible on `odoo.addons.__path__` where they
are now directly loaded [2].
See also:
[PEP-594]: https://python.org/dev/peps/pep-0594/
[2]: https://packaging.python.org/guides/packaging-namespace-packages/closesodoo/odoo#36597
Task: 2003936
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* = stock, test_website, web, website_forum, website_slides, base
Replace KarmaError with AccessError and remove the related override made
on crash_manager and ir_http.
task-2069890
closesodoo/odoo#36655
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit fixes the /report/download route in multicompany
Since the multi company revamp (a5b6f31cf2)
the multi company rules depend on the context.
However the route /report/download was not forwarding any context, this meant
that when trying to read some fields on a record in a company that is different
than the default one, it would crash with the multi company ir.rule
Forwarding the context from the session in the Javascript call is quite simple
however since (521f7d36c1) it also requires to change
the signature of the `report_download` method in order to pass the context to the final
method.
As there was already some code allowing the adding of some context in `report_routes`
this PR reuses this code by simply passing the context as a kwargs.
closesodoo/odoo#36839
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
SHA-1 is a cryptographic hash function that have weaknesses known since
2005, it has been deprecated by the NIST [1] about 10 years ago in 2011
and Google [2] have been able to perform a collision attack in 2017.
We use SHA-1 in order to generate unique URL for resources that can be
cached by the browser: assets bundle, translations, qweb templates and
qweb images.
Although practical attacks still requires quite a lot of computational
resources, it is time to upgrade SHA-1 to SHA-2.
We have selected the SHA-512/256 variant of the SHA-2 algorithm as
replacement for SHA-1 for the following reasons:
* On 64 bits platform, SHA-512 is the fastest SHA-2 variant, it is only
~1.5x slower than SHA-1. [3]
* Keeping only the 256 foremost bits protects against both collision
attacks and length extension attacks.
* The hexadecimal digest is only 24 chars longer than SHA-1 which is
nice to have somewhat short URLs.
We have not used SHA-3 because:
* At the moment of writing, it is too slow (~3x slower than SHA-1) [3]
* It is not guaranteed to be available with the Python 3.5 `hashlib`
module.
* One of the author of SHA-3 is Belgian.
[1] https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions
[2] https://shattered.io/
[3] http://bench.cr.yp.to/results-hash.html
[4] http://www.commitstrip.com/en/2017/02/27/the-sha-1-alternative/
[PEP-594] is deprecating the `imp` module, that module is used in
`module.py` in order to dynamically import addons using any of the
`odoo.addons` or `openerp.addons` import anchor.
We are deprecating `openerp` module/addons imports in v13 in order to
remove the support in v14 and greatly simplify how modules/addons are
loaded. If you are still using the old `import openerp` or `import
openerp.addons`, `import odoo` and `import odoo.addons` are drop-in
replacements.
The `odoo.modules.module.ad_paths` addon paths list has been deprecated
too. The list is now accessible on `odoo.addons.__path__` where they
are now directly loaded [2].
See also:
[PEP-594]: https://python.org/dev/peps/pep-0594/
[2]: https://packaging.python.org/guides/packaging-namespace-packages/closesodoo/odoo#36597
Task: 2003936
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With this commit it is now possible to change the lang displayed in the URL.
Eg, you could use `/fr` instead of `/fr_BE`, or even a fancier `/french`.
Task-32838
Courtesy of pla@odoo.comclosesodoo/odoo#35135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
