*: 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>
Romain Derie