Before this commit, Going to Website --> Configurations --> Apps was displaying Modules related to Website only but the default focus on searchpanel was on "All". (https://tinyurl.com/y5tw5uob)
Now, The default focus of searchpanel is on Website Category. (https://tinyurl.com/y6984hl7)
closesodoo/odoo#60485
X-original-commit: 0e2c55eec07600585121acf560ec8ffebde442e3
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
To trigger a run of a server action, one must have a group specified
or a write access on the model.
CRM: only access lead, crm.team is readable by employees
Website: all users can access, action_dashboard_redirect takes care of the group
When you create an ir_ui_view form the backend, the encrypt function
was called with a Falsy value and crash with error:
TypeError: secret must be unicode or bytes, not bool
Now, when you create view from backend, we only set password if it is a qweb
view. In case of update, the field is dirty, so if you don't update it, it
will be not write.
closesodoo/odoo#53348
X-original-commit: 3d9101db0f7cc0adc1f34721c38b4c2f7089566d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, published column was not shown as option and user not able
to multi edit at a time in list
In this commit, we ease the purpose of multi edit at a time and keep a column
in option so user can keep hide it when not needed and can show as well.
task-2153812
Closes#43029
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
visibility_group was used for visibility, we now use the groups_id field.
groups_id is a M2M field while visibility_group was a M2O field resulting
in an issue to display the M2M field in the frontend. We decided to
allow editing the groups as a M2O in the frontend. If there is more
than one group the user will have to go through the backend to edit.
task-2264580
closesodoo/odoo#51846
Related: odoo/upgrade#1260
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, url preview of a theme was theme_xx/static/yyy.png
Now we make this url absolue /theme_xx/static/yyy.png
It was the expected behavior, and since werkeug 15.0 utils.redirect() don't use
'/' anymore as root but the current path.
Without this fix, theme selector uses /web/image/<id>, and the location become
/web/image/theme_xx/static/yyy.png instead of /theme_xx/static/yyy.png
closesodoo/odoo#51018
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
This commit adds the possibility to compare a view arch to another one.
The result will be shown in a diff viewer (github like).
This is following what was done at #32009
task-2190072
closesodoo/odoo#44646
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adds two buttons on the Theme side menu that allow users to
add custom XML to the head and to the footer of the website.
Part of #44633
task-2168391
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Without at least one field, performing a search in these models' search
view is outright impossible.
closesodoo/odoo#45177
X-original-commit: 0aabfbff3ce5d68bf37e1734ba7aa43f62803f3a
Related: odoo/enterprise#8379
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Themes image would not be shown correctly in the theme selection if the
`website` module was installed in CLI.
Indeed, the code supposed to load the theme images was done in the kanban view
during theme selection after installing module through apps screen.
Now, this code is encapsulated and called in post_init hook of website.
This was also needed for an improvement on `test_themes` module, see
https://github.com/odoo/design-themes/pull/195.
closesodoo/odoo#42206
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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
Since commit 07631a5, category has been updated, but not the filter of this action
task-2081177
closesodoo/odoo#38223
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
After this commit, you will be able (in technical mode) to update the url for
the python controllers.
Eg.
You can now rename /shop in /garden and /shop/product/ in /garden/vegetable/
Most of urls will be replaced at fly in the renderd qweb, with the function
url_for but all old urls will keep available. So if you access url /shop you
will be automatically redirected to /garden (308 Permanent Redirect).
As for cdn and other post-process of att, the automatically replacement in the
rendered qweb is only done when you will be not website editor. But the new
dispatch of URL will be applied in all cases.
For developper, since it is Permanent Redirect, don't forget to clear cache or
open chrome debug tool (with option 'Disable cache while DevTools is Open) to
see your lasts changes.
closesodoo/odoo#36555
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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>
This commit adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
- A website_visitor is created once the visitor is requesting
a website.page that is tracked.
- A website_visitor is considered as connected if his last tracked
website_page request is within the last 5 minutes.
- The number of visits for a website_visitor is incremented
if his last tracked website_page request was at least 8 hours ago.
- A website_visitor is only handled by the system. Users cannot
create, edit or delete a website_visitor.
- A unique website_visitor is created per website.
That means that the same real person can triggers multiple visitor
creation if visits multiple websites.
This is because, for livechat purpose on later commit, for example,
the chat request can be created on the correct livecaht channel
(linked to the correct website)
- The visitor is recognized via his cookie (visitor_id). So if the visitor
flush his cookies, a new visitor will be created the next time he will
request a tracked website_page.
- Link user's res.partner to website.visitor.
If a website_visitor log in
(a visitor that has visitor_id in his cookie),
the website_visitor is linked to the res.partner.
The website visitor name is than adapted to match the name of
the first res.partner linked to the visitor.
A visitor can have multiple partners as the same session
can be used by multiple person (one PC for a team for example).
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's usefull to see his last page views.
Task ID : 2028059
PR #34624
The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.
This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
`is_published` which would just go through the related for no reason.
Plus, using `is_published` will make the field tooltip more accurate as we
are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
related field, which is just a readonly when we are not in a frontend
context.
- Some create and write function would have security check on
`website_published` value but that was wrong as the user could bypass that by
simply writting on `is_published`. For the write method, check `is_published`
is more accurate as it will cover both case since `website_published` will
then call the write method on `is_published`
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>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
With multi-website support, the key field is more important than ever as it
kind of replace the xml_id behavior.
Thus, on the ir.ui.view list view it is usefull to see the key.
closesodoo/odoo#29419
In order to implement the next version of the dashboards in enterprise
we need to make some changes in community namely :
* Modify some search views (used in the dashboards)
* Remove the date/datetime filters from the search views as they are
duplicated with the time ranges
* Rename the menu items from Dashboard to Overview
With multi-websites, we expect qweb views to have a key set as it is the key
that is used to find duplicates (two views with same keys are duplicate, the
one with a website_id set is more specific than the one without a website_id)
Thus, 5ff87e8039 sort on key in order to find the most suitable one.
It would crash if a qweb view is created without a key (False) as it can't sort
`bool` and `str`.
This commit:
- Adds a generated key to scss views
- Adds an SQL constraint to avoid QWeb views without a `key`
- Generates a random key when creating a QWeb view without a `key`
- Handle False key in `filter_duplicate()` by extracting views with False key
before sorting, and then adding these views to the recordset
Note: We also want the key to be editable as it is now an important field with
multiwebsite. Thus, we removed the readonly on this field.
+ fix python tests as we now force key on qweb views with sql constraint
+ pep8
Reorder res.config.settings for website
Make website_id in no create in most view
Revamp res.configsetting and view Form simplified
Transform old 'useless' stored field for presentation by computed field.
We can consider that if there are not key, feature is disable.
Co-authored-by: rde-odoo
Co-authored-by: jke-odoo
From now, when you install a theme, it load the data from xml to template
table theme [ir.ui.view|ir.attachment|website.page|website.menu].
Data are only copied from this template table into the real table when you
choose a theme on a website; Making them website_specific and with a link
to the original to allow futur update.
A special case is done to create theme.ir.ui.view when you are installing
a theme, even if you continue to use template tag to create quick view.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Set up env & tools for module website multiwebsite (blog, event, sale..)
website_id in modelConverter and ir_rule
add _compute_domain_keys to have a different cache per website
or rules would not be correctly website_dependant
eg: blog 1 on website 1, blog 2 on website 2
access blog 1 from website 1 => can access -> normal
access blog 1 from website 2 => can access -> should crash because (ir rule)
split mixing website.published.mixin and website.published.multi.mixin to have
website_id only on last one.
multi mixing will:
- override website_published compute to take current_website into account (not in backend)
- force website when clicking on published in backend
- website blog, website_sale, website_event, website_forum, website_slides are now multi website
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Fix bug from the initial poc of JOV
Fix menu creation
- creating a menu would create a 'container' menu in the DB (.create is call without website_id)
then writing on it would copy (if condition to cow) the menu with a website_id leaving the first
one as a menu container unused.
- website_menu should always have a website_id
we dont want to support the multiwebsite system that allow to have generic/specific menu
unlink/write is useless now since we always have a website_id
Make unique_path website dependent, 2 distinct website can have a page with same name
Make Sale report multiwebsite compliant
Make website_id on sale_order / account.invoice as a related stored from partner_id.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Now we can see which specific page override wich page when page are sorted by url.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Swapnesh Shah