An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Before this commit:
When website default lang was not en_US, the translation of fields* in the
web_editor would not be saved correctly.
Let's illustrate with fr_BE set as main lang:
The web_editor's RPC calls does not send language in the context when editing
a page (6ebcc06), but it does in translation mode.
Note that editing is always performed in the website main lang, fr_BE in this
case.
Therefore:
1. When EDITING:
The backend suppose the language is en_US as there is no lang in the
context (hardcoded everywhere).
It then write in the record itself instead of the ir.translation as it
should since fr_BE is a translation. (In Odoo, every lang is a translation,
en_US is always the main lang)
2. When TRANSLATING (in en_US):
It would also write on model as the web_editor send the language to the
backend when in translate mode. But since en_US is recognized as the main
lang (which is correct), it also writes in the model, overriding the
incorrect fr_BE writing which was also wrote on the model.
This has been fixed in 10.0 with these 2 commits:
036ccbe2955bf2
With these fixes, the lang is correctly added (by the backend) if the website
module is installed.
By ensuring the lang is correctly set, the ORM _write() function will process
the edition and translation datas as it should:
- If it receive en_US, it will write on the model
- If it receive another lang, it will write on ir.translation
This closes#10883, closes#22403
*Not the HTML/XML fields which are handled differently by the ORM/translation
Traceback because the `_get_asset` function was called by the
`theme_customize` route without the `values` argument (which is not
necessary for the feature).
Closes https://github.com/odoo/odoo/issues/22516
Issue: when the qWeb compress rendered HTML for a better Google PageSpeed
result, some text fields are missing spacebar between fa icons and text,
and between some fields.
This field should be required.
This commits closes#21997
@kangol: diff in addons/website/models/ir_http.py is for existing db
It can be ignored in master because required will be apply
Before this patch, if some view had both `inherit_id` and `website_id`,
its inheritances were being applied even in different websites.
After this patch, if a view inherits from another, inheritances will only apply
when both views belong to the same (or none) website.
Refactoring based on the pr #17635
This closesodoo/odoo#17635
If the website default language is not en_US, qweb fields are not
translatable in en_US (and thus can't be translated) because:
- the code expected en_US to be the default language.
- there was a error in website _dispatch
opw-746776
closes#17939
Steps to reproduce the bug:
-Change the default lang on the website to be different than en_US
-Edit the name of a product in the website
Bug:
The name of the product is changed in en_US and not in the language
set on the website. The lang is in fact removed from the context in
function saveElement(in addons/web_editor/static/rte.js).
opw:747084
This reverts commit 174d7e8e49.
The default language is the language if no lang corresponding to
the current language is found. Thus the browser language if available in
languages has priority over the default language.
opw-746776
closes#17637
Attempting to read the field `website_price` directly
with the XMLRPC API failed because, in such a case,
the request is unbound, and attempting to read
anything from it (`request.session` whatever)
resulted to the raise of an exception.
e.g.
This prevented to perform a `search_read`
with all fields on the `product.product` model
Closes#14939
opw-745733
- Set a google analytic key with the admin user (in the settings for
module website admin)
- Give the right to demo user for website as 'Editor and designer'
- Give the right to demo user for administration as 'settings'
- Login as demo user
- Modify the google analytic key in the settings.
Security restrictions error on (Document type: ir.values, Operation: unlink)
This is a complement of commit 6c89b2bdd2
opw-727807
When forcing another language that the current one (the cookie one) in an
url, the requested lang wasn't set correctly in redirect url, but the
cookie was, resulting in multiple redirect which ends with initial lang.
A side effect of this error was the inability to edit website page when
default lang is not en_US and user not in default lang.
The request context must be reset before being used by
`request.redirect` (in `url_for` method).
The current user was used to generate the sitemap. So if a user with
more permissions than `public user` goes on the sitemap, he could
generate it (if he is the first to see it or the last generation was
more than 12 hours ago (by default)) and have pages unavailables for
a user with lower permission in the sitemap (until the sitemap is
generated again).
The issue was solved in 8.0 with d08facdcb but was introduced back in
10.0 with fd09ddb6f because the `uid` argument was dropped from
`generate` method on `ModelConverter`.
From 10.0 up to saas-14 the fix introduced is to use a `use_public_user`
key in `request.context` but in master we will keep the fd09ddb6f fix
by adding uid to the `generate` method.
opw-708456
note: to forward-port only up to saas-14
The GeoIP resolver keeps a permanent open file descriptor on the
GeoIP database file, for example /usr/share/GeoIP/GeoIPCity.dat
Because we initialize a resolver for each registry, servers with
many databases may easily blow up the open file descriptor limit
of multi-threaded workers (gevent or no workers multithread mode).
The Maxmind GeoIP API appears to be thread-safe since v1.1.4, so
it is much less wasteful to use a shared resolver for each process.
This patch keeps the _geoip_resolver class attribute on `ir.http`
for compatibility, but it will be removed for the next version.
The forward-port of the above revision missed
the conversion to the new api and that
`context` had to be replaced by `self.env.context`
Fixes#14922Closes#14923
Christophe Simonis