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
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
The revision
8f48baeda6
broke the ability to search pages in the dialog
allowing to add a menu to the website from the website
(From the website, Content > Edit menu)
as `request.website` was not defined in this case
opw-702020
The website `default_lang_id` was not required,
while the algorithm choosing the website language
expects it to be required.
This solves the below issue, when your browser language is en_US:
- add a second language to the website (e.g. fr_BE or es_VE),
- in the website settings, remove English from the languages
- in the website settings, unset the default language
- try to go on the website
You will have a crash:
```
File "/home/odoo/src/odoo/saas-11/addons/website/models/ir_http.py", line 193, in _dispatch
resp.set_cookie('website_lang', request.lang)
File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 992, in set_cookie
self.charset))
File "/usr/lib/python2.7/dist-packages/werkzeug/http.py", line 905, in dump_cookie
value = to_bytes(value, charset)
File "/usr/lib/python2.7/dist-packages/werkzeug/_compat.py", line 106, in to_bytes
raise TypeError('Expected bytes')
TypeError: Expected bytes
```
This is because the `request.lang` is set to `False`
because of the below algorithm in `ir_http.py`:
```
nearest_lang = not func and self.get_nearest_lang(path[1])
url_lang = nearest_lang and path[1]
preferred_lang = ((cook_lang if cook_lang in langs else False)
or self.get_nearest_lang(request.lang)
or request.website.default_lang_code)
is_a_bot = self.is_a_bot()
request.lang = request.context['lang'] = nearest_lang or preferred_lang
```
`nearest_lang` is `False`, because there is no nearest language
available for the browser lang (`en_US`)
`cook_lang` is `False` for users who never went on the website
`request.website.default_lang_code`, which is the last feedback,
is also `False` because you removed the default language
in the website settings.
opw-695621
Previous implementation did not allow the user to search for pages 'name'
but only on the slugified name.
Now we slugify the needles before to find a match.
1. Create a new page: 'The new'
2. add a link on your website and try to find this page...
- Before this commit, the only ways was to type 'the-new'
- After this commit 'the new', 'The new', 'The-new', ... will match
This commit closes#10771
Currently when using a language on the website, the following is done in
this order to choose which one will be used:
1) use a language code if present in the url (eg. /fr_BE/),
2) use a language similar to the one in the url,
3) use a previously choosed language (saved in cookie),
4) use the browser language if available on website,
5) use a language similar to the browser language,
6) use the default website language
When a bot is requesting a page, he could either not specify a browser
language (en_US is set as default) or sometimes specify english
erroneously.
In these instance, we will then never use the default website language
if an english language is installed.
This fix changes this behaviour so if a bot is visiting a page, the 4th
and 5th steps are skipped and the default website language is used
instead of using the browser language.
closes#14033
opw-690910
Commit e11f23b701 split the website
customize_template_get into web_editor and website ones. This split
was not perfect and commit 20861b482a
tried to make it work... but did not made it totally and added an
indirect dependency to website module in web_editor...
As the final result is wrong and inconsistent and that the previous
9.0 implementation was already ugly, this was not possible to make
a consistent full-stable fix.
This commit tries to make a fix as stable as possible (the main method
name did not change, the arguments did not change, their purpose is
the same, ...) which makes the code work and be less ugly. However,
the function returns are now slightly different (and JS depends on it).
It returns only valid view information (not header stuff which is not
related to anything and the inherit_id value is now a combination of
the inherit view id and name). Also, a new private method has been
created.
Also, the method contained code which was deprecated since saas-6 but
was never removed (and never broke anything "by chance").
In master these methods will be refactored to make more sense.
Simon Lejeune