Before this commit:
If you changed the URL of a menu linked (m2o) to a website page and the new URL
was already taken by another page, it would edit the menu.url and the
menu.page.url resulting in the menu's page having the same URL than the already
existing one.
Now, if you edit the URL of a menu linked to a page and the URL is already
taken by another page, we will simply change the menu/page m2o relationship
without writing on the menu's initial page's URL.
Before this commit, the domain use to retrieve pages in enumerate_pages was
wrong (mainly used for sitemap.xml). It would only show website.page that:
1. are published
2. are indexed
3. have a publishing date (whatever date, future or past).
Last point was incorrect
Now, we correctly retrieve pages that:
1. are published
2. are indexed
3. have no publishing date or a publishing date in the past
Before this commit:
1. If the website's homepage is unpublished and a public user naviguate on it,
it will log an access read error in the server. The user won't see the error
though.
2. If the user can't access '/', we serve the first menu's page instead.
This first menu's page can be an unpublished page, resulting in a 403, which is
not convenient.
3. Menus are sorted by sequence, then the ORM sort them by write_date.
Menu with same sequence will be sorted differently every time you edit one of
them. (This issue get hidden/solved if user edit and save the menus with
"Edit Menu" since it will recompute every sequence.)
- Create 3 pages 'A', 'B', 'C', with 'Add page in menu' enabled
- Menu is now 'A B C'
- Edit website.page B (in property dialog), it will write on the page's menu
aswell
- Menu is now 'A C B'
Now:
1. We prevent this error by ensuring the page is published and so can be read
by anyone before accessing its properties.
2. We serve the first menu's page that is published
3. We sort menu by id after sequence to keep original order
This closes#21259
Before this commit, if there was a menu entry linked to an unpublished
website.page, the menu would be shown. For restricted users, they would land on
a 403 forbidden.
Now, we dont show website.page's menu if user can't access it.
This closes#21328
Before this commit, if a website.menu had a URL set to null, it would throw an
error when displaying that menu.
It is normally not possible to do so in v11 but after a migration, menus can be
empty. (eg: Using an empty menu to display a divider in a dropdown menu)
Now we return an empty url instead of an error
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 commit, editing a website.menu (linked to a website.page (m2o))
would not save the URL on the website.page record but only on the
website.menu.
But since the URL retrieved to display the website navbar is:
1. The website.page url if the menu has a page_id
2. The website.menu url otherwise
It would never get the edited URL stored on website.menu
The idea is to warn user if he created a special file (website.page with
supported extension) and he wants to change the file's name, which will at the
end also change the key).
If this special file has been t-called elsewhere, they t-call wont work anymore
This is why warning user is needed.
Note that this is different than the already existing page_search_dependencies
that is just checking if the URL is present in menus, templates, blog or pages.
This is about checking if the key is present somewhere. (we assume that if the
key is present, it is surely about a t-call.
Technically, the flow is:
1. Get supported extension
2. Get key dependencies
3. Check if user modify name
4. If name changed and it is/was a supported extension (special file) and it
has dependencies (surely t-call) then warn user these call wont work anymore
--
search_page_dependencies is also improved by returning links to be clickable
(on delete dialog eg) and splitting template/page results.
it also refactor dependencies warning that was creating HTML in javascript into
using XML template
Before this commit, if you created a page with the same name as another one
(which is allowed) it would set the same key for that second page.
Indeed, the code was setting correctly the path uniqueness but it was then
setting the key based on the name and not on the unique url we found free.
Now, the key is correctly uniquely set and even better, it is now completely
independant from the url and has its own 'find unique' method to be sure it is
correctly working.
It was not clever to have key & url being linked.
To be more clear:
1. Create page 'aboutus'
key is 'website.aboutus'
name is 'aboutus'
url is '/aboutus'
2. Create page 'aboutus' ->
key is 'website.aboutus'
name is 'aboutus'
url is '/aboutus-1'
Problem: key should be unique (for t-call for specific files & website_version)
Cause: key is set based on name which is not checking for uniqueness like url.
Two possible solutions:
1. Set key based on url (which is being checked for uniqueness)
2. Create & Use a specific method to get unique key
Fixed with solution 2 which is more clean.
--
It also fix an invisible 'bug':
Saving a page being in menu would cause the menu's URL to get it's trailing '/'
to be removed. It was only a problem when you were getting the warning about
dependencies (the menu wouldn't be recognized as dependencies because of the
removed '/')
Before this commit, if you created 2 pages with the same name/url it could
create both the pages with the same url.
Now, like before, it is correctly adding a suffix (eg '-1') when you create a
page with an URL already taken
Before this commit, we were using data[] array from json call to write on
website model accordingly of is_homepage value.
Now, we use the newly created inverse function of the computed field to handle
that to make it more clear
Before this commit:
1. You could create a page with supported extension in the path (eg: myfile.js)
You would then be redirected to the webeditor (myfile.js?enable_editor..)
But in this case, it would just redirect you to a plain text page without odoo
layout because supported extension are rendered with a specific mimetype.
(is it is a .js page, it will just render the page content as a js file)
2. These kind of page would still call t-layout that you should be removed in
backend in order to make it work
Now:
1. You will be automatically redirected to the back end to edit your file
instead of landing on a text-only page.
2. Supported extension now have their own template (eg: .js file now have
<script text=..> tag added automatically in their content)
Before this commit:
1. you could not edit a menu URL because the input was hidden.
This was due to radio options being switched (new page is now selected choice)
when you create a menu.
But when you edit, there is no choice and the input should be shown.
2. if you set a menu url to an email address, the display link would be prefixed
by a / and so it would open mysite.com/mailto:XXX instead of just the mailto
Now:
1. Input is now hidden only when you add a new menu, not when editing a menu.
2. mailto link now works as expected: it will open your desktop mail software
Use rec_name in domain because some model like survey.survey don't have name field.
Check that query_string is setted to avoid traceback 'lower of None'
Before this commit:
website.page won't be rendered as translated items since it is not going though
a controller (route) enabling multilang. Website.page were not considered as
multilang items and no lang prefix were applied on link.
Now:
website.page will correcly handling translation.
In case of one route doesn't match a controller, it is now by default a route of
type multilang.
Add a new field auto_redirect_lang on website model to allow to deactive the
autoredirect of the lang optionnaly. The code will arrive after more tests.
Before this commit, an unpublished page present in menu would throw an error for
public user (group_portal & group_public) because of the security record rule
set on website.page model not allowing read access to unpublished pages:
<field name="domain_force">[('website_published', '=', True)]</field>
In this particular case, we try to retrieve the menu URL, but since the URL is
retrieved through its (m2o) website.page, it would cause an error.
Now, it the menu has a website.page unpublished, we will correctly retrieve its
URL (sudo) and it won't crash.
Don't add useless routes or route that will return 404.
Improve generate function from ModelConverter to have a better management of
query_string.
Now we have an helper sitemap_qs2dom that will analyse the current route and
check if query string is plausible and if yes, generate a domain, when the
query_string don't seems to match the route, we return a Falsy domain.
Before this commit, if qs was /product/ipad, enumerate_page check for each
modelconverter of the route a name ilike '/product/ipad'.
Now we check all routes that contains product and one converter that match ipad
or routes that contains ipad and one converter that match product.
This commit a new way to declare the sitemap for a route.
def sitemap_xx(env, rule, query_string):
yield {'loc': '/my_url'}
@http.route(..., sitemap=sitemap_xx)
In this case, only the loc returned by this function will be in the sitemap
for all rules.
You can pass sitempa=False, if you don't want that route are into the sitemap
Before this commit, website.page had a 'name' field which was useless because
website.page inheritS from ir.ui.view which has its own 'name field.
At the end, we were duplicating/synchronizing 'name' field between
website.page and its ir.ui.view for no reason because we were always using the
one from ir.ui.view.
Now, getting website.page's name will always retrieve the one from its
ir.ui.view and there is no redundant information.
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
Purpose
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
As customer portal will be moved to portal module support of pager
has to be moved previously to the various portal moves. This commit
moves the pager code and template to portal.
Compatibility using website-based pager is provided to avoid having
to update all website addons currently. Future commits will make
addons use the portal pager instead of website pager.
Code managing language in URLs and redirection is moved from website
to http_routing. Override of _dispatch in website now consists in adding
website to the request.
url_for and is_multilang_url tools methods are also moved from website
to http_routing.ir_http as those are required for the moved code.
Some renaming is performed on request attributes previously added in
website. Indeed as website keyword may be misleading now a renaming
has been performed to better understand them :
* request.website_enabled -> request.is_frontend
* request.website_multilang -> request.is_frontend_multilang
* request.httprequest.cookies.get('website_lang') -> ('frontend_lang')
* first_pass variable in _dispatch is replaced by a new attribute of
request, routing_iteration, that is the number of routing iterations
currently done
ir_http override in website manage languages through methods or attributes
directly defined on website model. Those methods are get_languages method
and default_lang_code attribute. In order to be able to have a translation
layer independent of website we have to have access to this data without
depending on website record.
This commit solves this by adding class methods on ir_http override
located in http_routing. Basic implementation comes directly from website
default methods _active_languages and _default_language. Website overrides
those methods in order to be based on website values defined through
language_ids and default_lang_id for available languages and default
language.
Website behavior is therefore untouched whereas http_routing implements
a basic default behavior. This commit updates ir_http code in website
to use those methods and ease next commits which will move parts of that
code.
Slug and unslug API is now available in http_routing. Indeed there is no
link to any website or any reason to not support slufigied URLs when
website is not installed. A new unslug_url method is added as a tool
coming from an embedded method from website. Doing it allows to have all
slug related methods defined at the same point.
Support of slug and unslug in qweb rendering is also moved directly in
http_routing version of ir_ui_view instead of website inheritance. This
is done in order to keep things coherent.
Some code from website about ModelConverter is also moved. Indeed both
versions of ir_http uses some kind of placeholder to store the uid
when converting urls to python. This commit unifies it by using the
website one directly in base to simplify the override.
This commit also updates all module importing slug. Enterprise modules
will have to be updated, see related commit.
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
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
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`.
Ths fix add the `uid` parameter back.
opw-708456
Christophe Simonis