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.
The commit e59a7fe3ff has moved
the ACE editor from website to web_editor. As some code on ir_ui_view
was used for this widget, the code has also been moved to web_editor.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
- Add optional products and pricelists to ecommerce section
- add mail template sent when confirming a sale order
- rename and clarify using radio widgets
As of June 22 2016, the use of API key is required to access the
following:
- Google Maps JavaScript API
- Google Static Maps API
- Google Street View Image API
https://developers.google.com/maps/pricing-and-plans/standard-plan-2016-update
For domains accessing the API before June 22, it will still work without
an API key. Since Google advises to use the API key, we hide the Maps if
no API key is defined.
better patch for rev e9b649b555
* also fixes website_event which present the same issue (depends
on a function that slugs)
* raise an exception when slug is called with wrong arguments
instead of returning None (which was unclear)
* before calling slug in a function where we got a depends, check
that the record is actually created
When you execute the slug method on a virtual record (not yet
saved, virtualid/newid) the slugs obviously fails as it needs
an id and a display_name.
This issue happens when there's a depends on a function field
using the slug method: just after the create and during the
onchanges, they'll raise.
This patch makes the slug method returns None in these case,
anyway the depends are re-triggered after the write and at
this time they have an id and everything is working fine.
Since saas-3, website controllers use `request.website.render`
to render the template of a web page. This was kept for retro
compatibility. It's time to stop using deprecated stuff.
Same for `_render` method on website.
'json' route don't use `request.render` since
`JsonRequest` has no `render` method.
Migration of website module to new API.
The tricky phase is ir_http.py : we need to use `request.env`
only when the authenfication phase is done. Normally by
calling `super` of `_dispatch` method, but website module
required it to be done before. This is important since
`env`is a lazy property of `request` object.
Some hack were kept since this commit is a migration ('RequestUID'
in ir.http, ...)
Some docstrings were added.
The id of the user to browse has been omitted
during the below forward port revision:
95a2f8b121
We can see in the original revision that it was
correctly there:
cbb51610ee
This had as wrong side-effect to not display
views with a group set in the customize menu,
as it checked the groups of a null user browse
recordset.
opw-684326
Closes#12895
Christophe Simonis