Commit [1] made sure that to be considered active, the current page URL
should have the same query strings as the ones defined in the menu URL
(if any).
But it was not fully accurate as extra query strings on the page URL
would make the menu not active even if the menu URL query strings would
be found in the visited page URL.
With this commit, when trying to determine if a website.menu is active,
we only take into account the subset of menu's query arguments.
For ex, a menu with an url of `/my-page?country=BE` should be
considered active if the request url is:
`/my-page?country=BE&utm_source=marketing-campaign&utm_medium=email`
[1]: https://github.com/odoo/odoo/commit/065ca15closesodoo/odoo#120188
X-original-commit: bc1f2c092122e171950348c3e32438e8b862f231
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Before this commit conditions based on `_handle_visibility` and
`_get_cached_visibility` did work only by relying on the cache of the
`menu.page_id` being populated when accessing `is_visible` in sudo.
This does not work if the cache is cleared between the calls.
This commit makes sure all 3 conditions have access the record.
The actual issue has not been reproduced locally yet.
The various workers, crons, websocket work on distinct envs - even
through code they cannot impact the cache of another local env outside
the `check_signaling` system which is only used between requests.
For the problem to occur, some intra-request multithreading is needed
but it could not be located so far.
task-3149270
closesodoo/odoo#111882
X-original-commit: a864192ecd270848fede23d3eb053318d07ae8e8
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- Ignore anchors, those are not sent to the server anyway, no way to
compare even if we wanted to
- Ensure query string (qs) are the same to be considered equals
On top of that, it also fixes the case when the user inserted an
absolute URL instead of a relative one, it will now match.
task-3096367
opw-3091427
closesodoo/odoo#107782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- `clean_url` method was wrongly flag as `api.model`
- the `unslug_url` was not called for the URL comparison in the dropdown
case, meaning that `/shop/prod-1` would not match `/shop/product-1` as
it should (and as it does for regular non dropdown menu)
- the `active` class was actually never working for the dropdown case,
as the class was added on the wrong element (`li` instead of `a`)
The code was hard to read (mainly because huge python conditions in XML)
and kinda redundant, going through an util method should be clearer and
help reading the template XML.
task-3096367
opw-3091427
Part-of: odoo/odoo#107782
Prior to this commit, adding an anchor using auto-complete would not
properly prefix the url with the URL of the current page.
Steps to reproduce:
- Create a page (e.g. /test), add blocks and create an anchor (e.g.
- Save the page
- Click on "Edit Menu" in "Pages"
- Add a new menu entry
- Type '#' in the URL field and select the anchor
- Save
=> The menu entry is wrongly set as it does not contain the original
page's URL inside the `href` attribute. This means that clicking on the
menu from any other place will not properly redirect to the anchor on
the /test page
On top of that, editing a menu entry that was previously linked to a
page would change the URL of the page with an anchor, making it
impossible to access the page anymore until you change the URL back in
the page manager.
Steps to reproduce:
- Create a new page (e.g. test)
- Add a new menu entry that has this page as its URL
- Save the new menu entry (close the dialogs)
- Re-open the Menu dialog and edit the newly created menu entry
- In the URL field, replace it with the page + an anchor
(e.g. /test#anchor)
- Save
=> The page's URL is now /test#anchor and is no longer accessible
The is due to the `save` method of the `website.menu` model not
containing code to properly manage adding an anchor to the menu.
This commit fixes that.
opw-3067750
closesodoo/odoo#108502
X-original-commit: 192bf08da191e6fad27dd2913be0801817256a3a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Just a nice to have. It will prevent those errors to be replicated when
copy pasted and will help reading the files in the IDE.
closesodoo/odoo#97282
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
Before this commit if a menu had been saved without URL, a string +
boolean concatenation error could happen when updating the menu.
After this commit the False boolean is replaced by an empty string to
avoid the problem.
task-2781260
closesodoo/odoo#89147
X-original-commit: 0288e0e91a071c7ec4b8adb0474d82a46dea9c9c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] nested menus were not saved anymore because model ids do not
support `str` anymore.
After this commit the menus update data contain an integer `parent_id`
making them understood again by the model.
The `parent_id`s returned by `nestedSortable()` are the ones obtained
through a regex match, and therefore are strings.
Steps to reproduce:
- go to the 'Home' web page
- click on 'Edit Menu' in the 'Pages' menu
- drag and drop a menu item to nest it (e.g. put 'Contact Us' inside
'Home')
- click on 'Save'
=> nested entry disappeared from the menu instead of being nested under
its parent
[1]: https://github.com/odoo/odoo/commit/534087fa8d3c9947a918aa109f4030b5628a80d1
task-2781260
X-original-commit: d7bfb935580d6cc70dc213657c1a6dbc85dfa756
Part-of: odoo/odoo#89147
When serving a page, fetch the requested page and the menu's pages in
one go.
This will only impact pages that do not have a menu entry, which is the
most common form of pages.
So, instead of:
- read page
- read page's view
and later:
- read menu pages
- read menu pages' views
Fetch everything together:
- read served page + menu pages
- read served page's menu + menu pages' views
task-2774979
closesodoo/odoo#85456
X-original-commit: 16bf7cca8e8d452ce9131d9d86ff5b23789da4e1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit the default template for mega menus was the "Multi
Menus" template.
After this commit the default template for mega menus is the "Odoo Menu"
template.
task-2675252
closesodoo/odoo#80040
X-original-commit: a4d686140133ecf59a3d09c8f930a70b91064599
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Setting a controller URL to a menu which is linked to a page should unset the
m2o relationship to preserve the page URL.
Step to reproduce:
- Create a page (with a menu) and save, eg: "My Page" (url will be /my-page)
- Edit that new menu and change the URL to /shop (or any controller)
Issue:
- The page URL is now /shop, which doesn't have a lot sense if there is a
controller for that URL.
- Unpublishing the website.page will unpublish the menu, as a menu needs its
page to be published in order to be visible.
Note: The flow introduced here is the same as if you choose an URL of an
already existing page, the menu's page will be unlinked from the menu and
left with its original URL.
task-2575974
closesodoo/odoo#74163
X-original-commit: b52a01f76d89ebb7bdd75577e60a09f048c83000
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
*: website_form
This commit introduces a simple & light popover/tooltip (as in Google Doc) when
editing a link.
It will be used:
1. (web_editor) On every page links.
2. (website) In the website navbar, when clicking on a menu, it will replace the
popup shown to ask the user what he wants to do (edit the menu or go to the link
or do nothing). That popup was a bit invasive and old-fashioned.
Part of https://github.com/odoo/odoo/pull/64756
task-2439860
closesodoo/odoo#64756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
As of 02e01dce51 the website menu is prefetched for the user and saved
in cache.
If the sequence of a menu is changed (eg. with the "Edit Menu" modal on
website), the cache was not cleared so it seemed like this did not work.
With this changeset, changing a menu sequence will clear ormcache.
opw-2244908
closes#50683closesodoo/odoo#50703
X-original-commit: 8da3276e8b641e615e4c436b4f0f79139d158220
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit:
- make handle_visibility a private function (even if not
exploitable in rpc easily since it uses request.website)
- encrypt the password in db (even if not critic, since this
password could be shared on twitter, ... it doesn't cost anything
to secure it a bit more)
- remove useless sudo, since handle_visibility does a sudo itself.
In the future, this notion of visibility should be handled on controller layer,
and no more on the View layer (during rendering)
closesodoo/odoo#48145
X-original-commit: 06e0e48217f25f17dff23331111f5dcb98e8cecd
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Otherwise, `_get_menu_ids()` won't be recomputed, meaning removing a group from
a menu won't make it appear for restricted user, and adding a group on a menu
won't hide that menu, until a clear cache occurs.
Introduced with 02e01dce516
closesodoo/odoo#48065
X-original-commit: 0131e6d9103f68950ee23c6b0ef1af972370416e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
To avoid a SQL Query on hot state, the website menus ids are now prefetch.
Related to #47257
task-2211013
X-original-commit: 73421c27f01e7100403eaa72e027c34dbdf9f720
Since this field is not sanitized, it is safe (perf wise) to prefetch it.
It should not be CPU heavy, plus whenever we access a `website.menu`, it is
most likely we will read that field.
with following structure, 5 SQL queries will be avoided:
- Top menu
- Home
- Contact us
- Sub Contact us
- Sub Sub Contact us
Related to #47257
task-2211013
X-original-commit: 20cddcd899e7a119fa9f365e62527499f8e5ff7d
Now, you can define a Visibility mode between:
Public (All poeple)
Connected (Portal or Employee)
Restricted Group (Has this group or is Employee)
With Password (Know password or is Employee)
Internal Users (Is Employee)
It is a 'fair' feature, but without really warranty that the content is
really unreadable via others methods, ...
It is more for frontend display, that real secret. Dont use this like
a keychain ;)
We only catch the visibility on the main view and not the t-call inside.
Even if it should work on controller too, it is only display now on the
page property menu. (Or on the view directly in backend)
task-2091365
Allow users to create complex website menus, also known as "mega menus".
Mega menus are enabled individually via the edit menu dialog, then their
content can be customized by dragging snippets in them like any other
snippets area in edit mode.
task-1925319
closesodoo/odoo#36097
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Andrea Ulliana <aul@odoo.com>
Since saas-12.5, with recent ORM changes, writing on non-existing fields
does not trigger a warning anymore but instead crashes. This revealed
that the 12.0 "Edit Menu" dialog was doing some of that. Indeed,
depending on what was edited, we ended up writing on the 'is_homepage'
field, the 'text' field, the 'isNewWindow' field, ... which do not
exist.
This commit takes advantage of the fix to also lint the dialog code and
convert some of it to ES6.
Discovered while working on task-1925319
closesodoo/odoo#36204
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Before this commit, it was impossible to know which view was the one searched
if there was COW views.
Indeed, since multiwebsite, views might get duplicated from one website to
another. Then, when searching for an ir.ui.view in a form view, every
duplicated view would be listed next to each other with the exact same name
without a way to identify which one comes from which website.
This commit will suffix the view name by its website_id if there is one.
To do so, we use the context key that has been introduced with 62d73253f3.
task-1920052
closesodoo/odoo#33307
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Xavier ALT