This commit applies the following ACLs rules:
C : nobody can create visitor (except system)
R : everyone that should access to this model
U : website_designer can update (even if only few fields are editable),
mainly useful for language (+ system obviously)
+ livechat users as they are the guys who directly speaks with the visitors
D : system + website_designer can delete, mainly useful to clean if necessary
Remove the no_create from all visitor views as handled by ACLs.
This fixes the 'can create' that should not be done by any users
except system + admin
Task ID: 2092502
PR #40439closesodoo/odoo#40865
X-original-commit: 23f3324830adf31edb0a12c7009fcb65b0f54614
Signed-off-by: Thibault Delavallee (tde) <tde@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>
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
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/...)
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
David Beguin