*= 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`
* website, mass_mailing, web_editor
This commit adds various improvements in newsletter snippets as follow:
- Improves UI for newsletter popup.
- We only had one popup for all websites. Now, we can have a different
popup for each website.
- The popup was not appearing on mobile/tablet devices. Now, in
mobile/tablet devices, the popup appears automatically after 5secs.
- Added the ability to customize the whole editor popup like any
editable area (background colors, etc).
- User needed to enable popup snippet from the settings. We removed that
setting so now popup snippet will always be available.
- Added new snippet "Newsletter block".
- Display notification after successful subscription the same way for
all newsletter snippets.
Closes https://github.com/odoo/odoo/pull/29353
task-1903256
closesodoo/odoo#29353
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, those pages would be flag as noupdate.
If not modified, those view would not get modification on module update, which
is not logic.
Now, those view will benefit from any update. It makes even more sense since
multi-website as those views will never get modified directly (it will COW).
closesodoo/odoo#33920
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, aboutus contactus and homepage would be flag as noupdate.
If not modified, those view would not get modification on module update, which
is not logic.
Now, those view will benefit from any update. It makes even more sense since
multi-website, as those views will never get modified directly (it will COW).
closesodoo/odoo#33919
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.
Task #1909865closesodoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Previously the image that we uploaded as a favicon of the website was not
resized, so it could be extremely excessive in size and resolution, and it also
was not guaranteed to be a square.
Now we always resize it appropriately and save it as an ICO file.
The default favicon is now applied to all websites instead of only the first.
task-1958000
PR: #31811
* = account, sale_management, website
Settings that are using groups internally should not appear on the user form
without using debug mode.
The admin should not get the idea that he should configure those per user,
because they are going to be reset if/when changing the general setting.
closes#29842
PR: #29860
Previously, for multi-websites it was decided that:
- creating a new website would not get already existing apps menu (shop,
blog, forum..).
- installing a new app would create the app's menu on existing website
This was decided mostly for technical reason but it is a weird behavior.
This commit saves the installed apps menus in order to copy them on new website
If this default menu got deleted, we ensure a minimalist tree menu for new
website
Note: This also fixes the bug where installing a website_module more than once
(with -i website_module in command line) would create the menu (blog, shop,
forum..) on the first website a second time.
This was because the website.menu.create() overrided in website would
return the last created record in the self loop, thus the last one created
would be the one set to the xml_id (ir.model.data).
This commit closes#27253
Somehow, having theses 2 new `website.page` records created separately from
their `ir.ui.view` would throw an error in dev-xml when installing website
module.
A task has been created in website team to track the origin of this bug.
In the meantime, this commit will avoid the traceback by creating the view
inside the page record. As the page's view is not intented to be inherited, it
is the best way to write it anyway.
Step to reproduce:
- Start odoo in dev xml
- Install website app
Related to #27199closesodoo/odoo#27210
Somehow, having theses 2 new `website.page` records created separately from
their `ir.ui.view` would throw an error in dev-xml when installing website
module.
A task has been created in website team to track the origin of this bug.
In the meantime, this commit will avoid the traceback by creating the view
inside the page record. As the page's view is not intented to be inherited, it
is the best way to write it anyway.
Reaching the URL /demo/snippets-debug will now showcase all snippets
*automatically* (if a theme uses different snippets or if the snippets
change in the future, this page will not have to be adapted).
Remove demo data for domain to make it usable on runbot.
Before this commit, when you switch on runbot to website 2, you was redirected
to 0.0.0.0.
+ add tooltip (fgi request)
* social_media
- Remove action server demo (out-dated and buggy)
- Remove website app / themes app actions (useless)
- Move demo social media to the social_media addons
- Use same contact us page for demo website 2
- Improve edition of contact us and about us pages by using snippets
as default contents
- ...
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>
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
* web, web_editor, website_hr_recruitment, website_mail_channel,
website_mass_mailing
- Review all snippets and add new ones
- Add lots of new options
- Use odoo colors as default theme colors
task-38878
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.
The 'control-label' class was renamed to 'col-form-label'.
The 'help-block' class was renamed to 'form-text'.
The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
The system completely changed. I also had to adapt classes to new
screen breakpoints.
hidden/hide -> d-none
show -> d-block
hidden-xs -> d-none d-md-(block/inline/...)
hidden-sm -> d-md-none d-lg-(block/inline/...)
hidden-md -> d-lg-none d-xl-(block/inline/...)
hidden-lg -> d-xl-none
visible-xs-* -> d-* d-md-none
visible-sm-* -> d-none d-md-* d-lg-none
visible-md-* -> d-none d-lg-* d-xl-none
visible-lg-* -> d-none d-xl-*
hidden-print -> d-print-none
visible-print-* -> d-none d-print-*
...
and all possible combination of those had to be handled too.
Description of the issue/feature this PR addresses:
Accessibility improvements forbids the use of the syntax
`<i class="fa fa-check"/> Some text`
to create a labelled icon. But, by this, some fonts are changed.
Desired behavior after PR is merged:
The old syntax can be used.
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
- Remove useless snippet background suggestions (only one button to
open the media dialog directly)
- Show meaningful-only tabs in the media dialog (no document as
background, ...)
- When editing a background shows the background suggestions first and
show the background suggestions last for standard images. Technically,
this is done by filtering on the name/fname of the attachments and
adding magic name parts to the fname on image upload (e.g. when
uploading an image from the media dialog when customizing a bg, the
uploaded image will automatically be marked as a background). Note:
there were discussions to implement this feature with a tag system for
ir.attachment/s but the implementation's cost was too great in regards
to the feature.
- When editing an existing link or creating one from selected text, do
not show the "Link Label" field in the dialog; it was confusing. Only
show that field when adding a link at the cursor location with no
selected text.
Some website default images were declared with the wrong filename
extension, inducing the wrong mimetype. As a result, some browsers
(IE...) were unable to render these images.
Purpose
=======
User tests have been made by the Product Owners team. It showed that the planners are not used by new users on Odoo due to several reasons (They are too static, too heavy to use,...)
Specification
=============
Remove the module and its different applications. The onboarding on the business flow will be improvement in the weeks to come.
Before this commit, website.page xml record were created in 2 steps:
1. Create an ir.ui.view record with <template> tag
2. Create a website.page record with <record model="website.page">
But this is useless since website.page inheritS ir.ui.view, you can create both
records just in one <record> tag.
Note: This is NOT TRUE in every case:
Odoo's ORM will suffix external_id of inherited records (in this case the
ir.ui.view created through the website.page record) with its model's name.
This can be a problem in some case (this is an example):
website_crm_template.xml create an ir.ui.view inheriting the
ir.ui.view 'website.contactus'.
But if we didn't keep website.page & ir.ui.view records split for that
specific case, the ir.ui.view would inherit a website.page record
causing an error. (website.contactus would be the id of the page record
while the ir.ui.view's id would be website.contactus_ir_ui_view)
In short: when migrating an ir.ui.view (<record> xml) to a website.page:
* If there is record inheriting the ir.ui.view ID, then split
website.page & ir.ui.view
* if not, you can create the website.page and its ir.ui.view both in one
record (<record model="website.page").
This commit also removed remaining page="True" from xml template since we
removed the 'page' attribute from ir.ui.view model overrided in website module.
Before this commit, website.page had a 'name' field which was useless because
website.page inheritS from ir.ui.view which has its own 'name field.
At the end, we were duplicating/synchronizing 'name' field between
website.page and its ir.ui.view for no reason because we were always using the
one from ir.ui.view.
Now, getting website.page's name will always retrieve the one from its
ir.ui.view and there is no redundant information.
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/...)
Purpose
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
fja-odoo