This commit:
1. removed the possibility to create page from the menu manager.
The usability of this feature wasn't great since create menu as a new page
would redirect to that newly created page without saving the menu manager
state.
Plus, there is already the 'NEW' button on the navbar to create a new page,
the menu manager should, as its name hint, only manage menus.
2. Handle a new case (officially at least) of menu: menu container.
Those menu are simply menus with '#' as URL. It will be usefull to create a
menu as a dropdown list container.
Note: We should take care of a menu's URL being updated to '#' to avoid the
menu's page URL to be also edited to '#'.
opw-1825883 & opw-1824263
Website Versioning module (website_version) is applied when displaying
views by interfering when doing the "render the view of this `key`" and
showing the view with the same `key` but of the currently displayed
version.
The website.page model when directly rendering a page would directly
specify its `id`, thus website version was bypassed and just the master
page was displayed.
With this commit website.page has a "get_view_identifier" that can be
overrided in website_version and has the same previous behavior
otherwise.
This changeset also solves a conflict (`website().get_current_website`
also modify `request.context`) when modifying the context which also
disabled versions.
opw-1824957
closes#23847
Before this commit:
When editing a page URL through page properties it would redirect to that new
url afterward. If the url was not starting with '/' and had multiple level
before and after edition (eg: page/action to page/realaction) it would then
redirect to a wrong relative URL.
Now, we ensure that we redirect to the correct URL: the one slugified and
cleaned in the backend.
Step to reproduce:
- Create a page '/page/action'
- Go to that page and open Page Properties
- Edit the URL to 'page/someaction'
- You will be redirected to the incorrect relative URL /page/page/someaction
Before this commit, model that create ir_ui_view via _inheritS was ignored in --dev xml
The arch_fs was not set. Because it was not ir.ui.view, and because xml_id was suffixed by _ir_ui_view.
Now we manage the case of inherits. So if model model.name inherits ir_ui_view
class MyClass(models.Model):
_name = 'model.name'
_inherits = {'ir.ui.view': 'view_id'}
view_id = fields.Many2one('ir.ui.view', string='View', required=True, ondelete="cascade")
...
<record name='model.name' xmlid='pok'>
<field name='arch' type='xml'>content</field>
</record>
will be read from xml in dev mode.
parsing the xml file for xml_id pok_ir_ui_view and pok.
The orm by default will add this suffix.
The 'dynamic' view created when we update the groups is a special case, which we don't want the arch_fs
for dev mode because the xml only contains by default and an empty container and btw the imd was wrong
since we had the res.group model a xml_id into the _inverse_arch.
The page create via a template (method new_page) will automatically remove the arch_fs since we don't
want to see the empty container if we are in dev_mode.
Before this commit, it was possible to create redirect with empty values.
Now, for new db, that will be required.
Fix usability according to first feedback
- Redirect / menu should be visible without debug mode
because user need it when they start their website and
dont know at the beginning how to enable it (fgi)
- fa icon in page manager was for blind people
- missing widget on sequence field
This replaces the former modified preorder tree traversal (MPTT) with the
fields `parent_left`/`parent_right`. Each record is associated to a string
`parent_path`, that represents the path from its root node to itself. The path
is made of the node ids suffixed with a slash:
a node | id | parent_path
/ \ a | 42 | 42/
... b b | 63 | 42/63/
/ \ c | 84 | 42/63/84/
c d d | 85 | 42/63/85/
This field provides an efficient implementation for parent_of/child_of queries:
the nodes in the subtree of record are the ones where `parent_path` starts with
the `parent_path` of record. It is also more efficient to maintain than the
MPTT fields, and less sensitive to concurrent updates, because the value of
`parent_path` does not depend on sibling nodes.
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
Romain Derie