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.
The field `auth_signup_uninvited` is defined in the 3 aforementioned
modules, yet they are independant modules in respects to one another.
This means that whichever module is installed first will create an XMLID
for the field, if this module is uninstalled before the other two: boom!
crash when changing general settings because the res.config.settings
field set by the other two modules no longer exists.
To solve this, we simply ignore the field during ir_model_field.unlink()
Fixes#23171
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
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
Don't rewrite the wheel with serve_404.
It is the job of HandleException to do it.
In the same time, that will fix the status code that was
previously 200 instead of 404 in serve_404
This commit closes#22438
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
In the module website, the relational field website_id is defined twice,
once for ir_ui_view and a second time for res_config_settings, for the
former we perform an ondelete='cascade', which means that when the
website model is unlinked, the field is unlinked as well.
This is not done for the website_id field in res_config_settings, which
instead defaults to setting the field to NULL, which violates a not-null
constraint and therefore causes issues when trying to modify/save
settings.
To solve this, a hard delete of the ir_model_field website_id is
performed during the uninstall process of the website module.
Fixes#21905
OPW 803018
Before this commit, website had incomplete context.
It was causing website.menu to not be translated correctly because lang was
not set on website.
Now, since the website has the context correctly binded, menus are translated
opw-787012
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
Clean method _add_dispatch_parameters
Remove unused code for caching
Call super before to have the correct lang when we browse website.
Without it, menu was not loaded in correct language.
The ORM does not currently, an probably won't support two fields with
the same name in different modules that do not depend on each other.
This is obviously a nasty hack, but it's the best one can do for a
stable branch.
THIS IS WHY WE HAVE DEPENDENCY MODULES, PEOPLE.
Before this public users could see pages before their
date_publish.
request.website.is_publisher is a function that always exists. So the
if body will never be executed. Additionally, is_visible is a
non-stored computed field that can't be searched. So instead grab all
records that match and filter the ones that are visible.
This commit closes#20296
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:
When you were on the page manager and you were editing a website.page's
content, it would redirect you to the website.page's ir.ui.view's form view in
the backend.
From there, you would'nt have an easy way to get back to the page manager:
your only option was to go to the website module and click on 'go to website'
and then click on menu/manage pages.
It was not convenient when you were editing multiple page quickly or just
taking a look into some pages.
Now, you have a button on the ir.ui.view's form view to get directly on the page
manager.
Note: this back button is obviously invisible for ir.ui.view not related to a
website.page
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
This reverts partially commit ab2283ef83.
This commit clean and clarify some code.
It also secure the call to specific page extension's template to avoid somehow
calling unexisting tempalte
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, the website.redirect records would never been called since
we switched call order from redirect>page to page>redirect.
It would always render a 404 and would never check redirect records.
Now, if there is no page found, it will check for redirects and if no redirect
found it will return 404.
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
Romain Derie