This commit adapts the business code in which
class/module/function/method redefinition took place so that it no
longer happens and the pylint test passes.
Odoo provides basic handling of CORS preflight requests: if an
endpoint is marked as `cors=<truthy value>` then it'll automatically
reply allowing the request.
*However* this is performed in `HttpRequest.dispatch` (likely in order
to correctly handle the nodb case), which means it's executed after
the auth handler has run... which means custom auth handlers will be
called on preflight requests.
This is a problem because they are missing relevant
information (e.g. which endpoint they're invoked for), plus having to
deal with preflight requests in every custom auth handler is annoying,
and simply allowing preflights could cause issues if the decision
diverges between the auth handler and the automatic
handling.
To fix this issue, extract the preflight *decision* into a separate
method so we get the same decision-making process everywhere, and in
case of CORS preflight set the auth to none to limit the eventual
capacity for nuisance in the span between the bypassed auth and the
automated preflight handling.
Also change the signature of IrHttp._authenticate so it's clearer if a
callsite was forgotten somehow (and this makes for less changes and
duplication at the callsites).
closesodoo/odoo#56029
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit each url was processed each time, now with have a cache
with the path (withtout query string) as key on each worker.
It reduces drastically the time of the rewrite check on hot. (~10x)
closesodoo/odoo#54690
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Now, slug uses seo_name if field exists before to fallback on display_name.
It allow to have a custom url without change the product name already used in
backend e.g. or just because you want add some keywords for seo.
task-2291676
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.
Method _get_exception_code_values can return None value for code. We should avoid
getting a KeyError in HTTP_STATUS_CODES in this case.
closesodoo/odoo#50160
X-original-commit: ea138667d55b535d8ec51f86fd649e28d704ac76
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
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>
In case of short controller that don't use qweb template, we don't need
anyhting else that this url code that don't change frequently.
It make only sense for model like lang, website, ... that will not change
frequently. And are called on each call by the dispatcher.
In case of a website page, we will btw browse lang later, but in case of
small controller like /favicon.ico, or page without qweb, ... we can just
use the same from last query.
Before this commit, url_lang (= url_for) will make query to find the lang_code
but we alrady have this info in ormcache with get_available method.
So instead to rebrowse (search query) the lang, we use a new method that will
try to find it in cache if possible before to make the query.
The gain on each page is n-1 (where n is # lang installed)
Because the switcher of languages do an url_for for each lang available.
Related to #47257
task-2211013
X-original-commit: 2cecbe356ce283e15fb0bbd0a6e9aa4735af520e
Before this commit, each module override _get_translation_frontend_modules_domain
from ir.http to add its own translation in website if needed and that module
is not starting by website_. Updating the domain from the super() call.
Since we know in most of the case the name, it is useless to do a:
select name from module where name = 'name1' or name = 'name2'...
Now we support a new override of _get_translation_frontend_modules_name that will
allow to add the known module name directly in the list instead to make a search.
In case nobody override _get_translation_frontend_modules_domain, we don't need to
make an extra rpc to find the module.
Related to #47257
task-2211013
X-original-commit: 0dc54814161ab55c34dd2242f65dea23d19fdfca
Before this commit, we compute the hash on each request, to know if we need to
download the file from the frontend or if we can use cache.
Now we store the hash computed in cache. The cache will be invalidated when we
touch one of these translations (openerp-web in the comments) or when you
install a new lang (already the case).
+ avoid to use read on a record, since it will not use the cache from record.
Related to #47257
task-2211013
X-original-commit: d5aaecbc51de19ef1d8d9988b691177fc73a4b86
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.
- When rendering a website page, exceptions might happens.
If so, an error page is displayed, to do so we create
a new psyscopg cursor to read the view in database and render it.
But if the current (failed) transaction was holding a lock, the new
cursor might have to wait for this lock to be released further
down the line. However, this will only happen after the
request is done (and in fact it won't happen). As a result, the
current thread/worker is frozen until its timeout is reached.
So rolling back the transaction will release any potential lock
and, since we are in a case where an exception was raised, the
transaction shouldn't be committed in the first place.
closesodoo/odoo#44085
X-original-commit: 7a61c89da5ccaed983275eb5f4986475ebf8b48d
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit fixes 2 issues, both coming from a misbehavior in
`get_nearest_lang()`:
1. Anyone could reach the website in a lang available in backend but not in
frontend. Eg, french is activated but not a website lang, going to `/fr`
would show the page in french.
2. As a logged in user coming from backend in a lang not available in frontend
(has request.lang set to that lang), the website would show a 500 error page
since it would not filter out the current request lang.
Both these issues are fixed here by ensuring langs are filtered out if they do
not belong to the frontend (website langs).
Step to reproduce (bug 1):
- Install french in backend lang (not on website)
- Visit `127.0.0.X/fr_FR`, the frontend will be displayed in french even if
it not a lang available in frontend.
Step to reproduce (bug 2):
- Install french on frontend and remove english from frontend
- Navigate to the backend /web
- Navigate to frontend, it will crash
Fixes#40572 and fixes#40078closesodoo/odoo#41146
X-original-commit: 4bfba037fbbf34c178abd532f7bf52b94ae40b27
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Old heuristic is not more True:
Force to check method to POST. Odoo uses methods : ['POST'] and ['GET', 'POST']
We have some controller that only allow 'GET' method, so we need to check GET
also when we try to know if an url is multilang or not.
This commit fix case where a controller '/test' only allow GET and you were in
another language that the default, in this case, the rendered url in qweb was
/get instead of /<lang>/get.
Closes#37223closesodoo/odoo#40519
X-original-commit: c7650106f8588083be12812600a6c94ba703fd6f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Reproduce the issue
- Install eCommerce & Sales
- Create a quotation
- Preview
- Switch to french on the website page
- Click on "Signer & Payer"
There is a lot of things not translated.
Cause
On the website, the route `/website/translations` is called.
The route calls a method `_get_translation_frontend_modules_domain`
which teturn a domain to list the domain adding web-translations and
dynamic resources that may be used frontend views.
The missing translations are in the web module and the module is not
loaded by the method.
This commit adds the `web` module to the domain and a missing
translation for the portal module
OPW-2120397
closesodoo/odoo#41072
X-original-commit: 50c2ecbc9ef0e446af0a1d4010ec1d923aa41bec
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
A customer reported a problem when he deleted a language on the
website app.
In some cases, if you go on the odoo's generated website as a public
user let's imagine the following url: website.com/en_GB
The lang is saved in a cookie and sent to the context.
If you delete the language from the website languages (without
deactivating it) and you go on website.com as a public user,
the method will try to use the context or the cookie value which is
'en_GB' and it crashes.
This commit makes sure that the language is available
OPW-2129580
closesodoo/odoo#41007
X-original-commit: f3e9ca13f60ced0ec61cea0d13da45b2569da14e
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
A nicer 404 layout was introduced with e9106f8f98 but the specs got changed
just after it was merged.
It has been decided to make the 404 fully editable (before, everything was
fully editable except the popular page div).
In order to do this, the 404 template can't have inherited views, which brings
the following changes:
1. Remove every main website module xpath view adding their most popular page
2. Remove the xpath view in portal to add popular page part (was not needed
in http_routing/web). It has been decided that having `Home` ('/' url) even
without portal and/or website is not a big deal.
Those changes allow the 404 template to be written in a single view without any
inherited views.
The 404 will be the same for backend only databases, portal and website.
task-1966460
closesodoo/odoo#40637
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit introduces a nicer 404 page, which is basically the same layout as
the one used on Odoo.com.
Also, the 404 is now fully customizable, blocks can be drag'd & drop'd.
task-1966460
closesodoo/odoo#38901
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Initial b6ed34e1 idea was to ensure that we always have
_rewrite_len and _routing_map defined. Unfortunately, this
is not correct since class attribute defined dynamically
are actually added in registry, and recomputed on each install.
More than that, the call si shared between multiple database
meaning that routing_map cache may be shared between multiple
database whcich is not correct.
After b6ed34e1, when installing discuss on a fresh database without
demo, all discuss routes will be unknown since None is already in
_routing_map and thus routing_map is not recomputed.
When routing_map is on the model class, in registry,
a new install will reset the class, remove the _routing_map attribute,
which will fix the problem.
Task #2117275closesodoo/odoo#39640
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Now, you can define a Visibility mode between:
Public (All poeple)
Connected (Portal or Employee)
Restricted Group (Has this group or is Employee)
With Password (Know password or is Employee)
Internal Users (Is Employee)
It is a 'fair' feature, but without really warranty that the content is
really unreadable via others methods, ...
It is more for frontend display, that real secret. Dont use this like
a keychain ;)
We only catch the visibility on the main view and not the t-call inside.
Even if it should work on controller too, it is only display now on the
page property menu. (Or on the view directly in backend)
task-2091365
A 404 will take 3 to 5 seconds to be resolved and execute +- 1900 query, to return
a rendered page which is quite expensive, especially when multiple missing images
are rendered in a view.
Catching static route and marking them as not frontend will help to avoid to handle miss
on static resources. In this case server returns a standard 404.
This commit also fix a iframe src in order to avoid a 404 on
/web/(test )/report/html/some_report (thx to aab-odoo)
X-original-commit: 818d0cb59fbae78d0edf06318082981f318e4db7
This reverts commit 08108486d5.
+ Fix the url that add a useless ending / and so a useless redirection.
There are no problem of mixed content or anything else, if you configure nginx
and launch your server in proxy-mode as specified into the documentation.
closesodoo/odoo#38196
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In case you have a controller website=True without website installed, the
request.redirect() use url_for which one uses request.website_routing on the
request, without that it has been set by the website dispatcher.
closesodoo/odoo#38191
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = portal, website, test_website, account, sms
Portal an Survey error pages were ugly default pages.
Now the error pages will be the same as the website ones.
Also fixing single module builds tests
task-2059969
closesodoo/odoo#35535
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
After this commit, you will be able (in technical mode) to update the url for
the python controllers.
Eg.
You can now rename /shop in /garden and /shop/product/ in /garden/vegetable/
Most of urls will be replaced at fly in the renderd qweb, with the function
url_for but all old urls will keep available. So if you access url /shop you
will be automatically redirected to /garden (308 Permanent Redirect).
As for cdn and other post-process of att, the automatically replacement in the
rendered qweb is only done when you will be not website editor. But the new
dispatch of URL will be applied in all cases.
For developper, since it is Permanent Redirect, don't forget to clear cache or
open chrome debug tool (with option 'Disable cache while DevTools is Open) to
see your lasts changes.
closesodoo/odoo#36555
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When accessing an URL, there is some computation to check if you try to access
a lang. Part of this job is to get the closest language available.
For instance, you could try to get `/fr_BE/..` and it would redirect to
`/fr_FR/..` if french is installed but not belgian french.
There is a known issue when loading files/assets from a module starting by the
same letter than a lang, in debug assets.
Only reported case was `hr_XXX` modules which would be redirected to `hr_HR`
lang (croatian).
So, the issue would only occur when:
1. Debug assets is enabled
2. hr_HR lang is activated
3. only hr_XX modules would be impacted
But since 269aa59411, the issue would appear even if `hr_HR` was not activated.
This commit restore the issue to its minimal case, when `hr_HR` lang is
activated.
closesodoo/odoo#37494
Signed-off-by: Olivier Dony (odo) <odo@openerp.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/
The canonical tag is important for SEO, indeed it prevents search engines from
indexing duplicate content.
Reasoning
=========
The choice has been made to create the canonical tag automatically depending on
the request path, ignoring the query string, and manually prefixing the
appropriate domain and language code.
Indeed creating it manually for each resource would create a lot of code and
potential mistakes.
It is more dangerous to do it the generic way, but after investigation it
appears that it is an acceptable trade-off since the vast majority of our routes
are well built and already ready for this:
- using query string only for minor features that do not change the main content
- having the models, the ids, the pager and other important features in the path
Override
========
It is still possible to override the default behavior by passing
`canonical_params` manually to the view or to the different methods.
This is done for `/event` because the only way to display Past Events is to add
`date=old`.
Languages
=========
Fix an issue where it was possible for a bot to be on the URL without language
code but to use a language that is not the default language.
Adapt hreflang, because it:
- must only be present on canonical pages
- must always lead to canonical pages
- should not be set if there is no alternate language
Misc
====
task-1958075
closes#12532
Inspired by OCA module `website_canonical_url` courtesy of Jairo Llopis.
closesodoo/odoo#35852
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Jairo Llopis <jairo.llopis@tecnativa.com>
Co-authored-by: Sébastien Theys <seb@odoo.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>
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closesodoo/odoo#35504
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
cache_hashes was introduced at 8a28cc22fd to reduce the number of reload
The cache is correctly reseted when the translations content changed but did
not contain all the translation-related parameters that are, however, stored
in the session_info
This commit fixes two bugs:
Language parameters invalidation:
1. Access the webclient in a specific language
2. Modify the language parameters (e.g. thousands separator)
3. Refresh the page
--> webclient is still using old language parameters (from cache)
No translation flag after installing a language:
1. Load a database in English in mono-language
2. Load a second language
3. Access a record with a translated field
--> translation button not present on translated field (multi_lang is still
false in cache value)
To fix it, this commit adds all the information that are returns by the
/web/webclient/translations call to make sure the hash represent the reality
closesodoo/odoo#34266
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Adrian Torres