Commit https://github.com/odoo/odoo/commit/88e910e187346c095a6f0eeb8be647da1e391035
merged the inheritance of a view into the base view while the inherit
was in fact a primary mode inherit. The modal buttons of website
creation modal thus appeared in all website forms by mistake.

This commit also takes advantage of the fix to fix the design of that
creation modal (wrong classes on buttons).

Also fixes https://github.com/odoo/odoo/commit/986415cf050efbd38a5834f9bbd3a37db1fd7933


which added a data file & folder in demo data by mistake.

closes odoo/odoo#40175

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

task-2086939

closes odoo/odoo#40059

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

* theme_bootswatch, theme_default, website_theme_install

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 07631a51, category has been updated, but not the filter of this action

task-2081177

closes odoo/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.

closes odoo/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

closes odoo/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

closes odoo/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

Improve searchviews UX in all the modules

TaskID: 2029731

closes odoo/odoo#35700

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

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`

task-1968099

closes odoo/odoo#32716

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

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 62d73253.

task-1920052

closes odoo/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

closes odoo/odoo#31243

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Courtesy of @Yenthe666

This commit closes odoo#32580

closes odoo/odoo#34039

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

closes odoo/odoo#31854

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Commit 68e9d550 makes the redirection type mandatory, which is
logical. Since we can't add such a constraint in stable, we make the
field required in the view and assign a default value (in case the
module is not upgraded, which is very likely to be the case).

opw-1924983

closes odoo/odoo#30252

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.

closes odoo/odoo#29419

Part of odoo/odoo#27599 to rename fields named 'type' which may conflict

closes odoo/odoo#28112

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

Before this commit, you had 'choose a theme' into the form view.
It should be only visible in modal

task-1878245

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, 5ff87e80 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

Since we use it in website_form which one is included before res_config_setting,
we need to declare it before.

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>

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.

Purpose
=======

Clean menus structure in website frontend and backend, for an easier navigation.

Specification
=============

Website
-------

- Restructure menu
- Enterprise: Keep google analytics view in a dedicated menu item when ecommerce is
  installed:
    - Sales Dashboard(ecommerce dashboard)
    - Analytics (google analytics)
- Community: Keep both sales orders and google analytic dashboard on the same
  dashboard view
- Restore google analytics api option in website settings when ecommerce
  is installed

E-Commerce
----------

- Website > orders > orders: add default filter "from website" and remove it in
  the action. That way if you create an order manually there is still a way
  to find it from the menu (the salesteam is different)
- Default filter for abandoned cart menu
- Improve setting text and tooltip. It's not obvious that recovery emails must
  be sent manually. Replace with:
    - Title: Abandoned Carts
    - Subtitle: Send a recovery email when a cart is abandoned
    - Tooltip: Abandoned carts are all carts for which no transaction has
               been confirmed while the customer has filled in their address.
               You can find them in *Website > Orders > Abandoned Carts*.
               From there you can send a recovery email to stimulate the
               customers to resume their order.
    - Tooltip email template: This email template is suggested by default
                              when you send a recovery email.
    - Tooltip hours: Carts are flagged as abandoned after this delay.
    - Hour label: Cart is abandoned after .... hour(s).

Task ID: 1859170

We need to be able to filter and group by campaign_id, source_id and
medium_id in the sale_report those fields are defined in utm mixin which
is installed with website_sale_link_tracker.

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

Before this commit, it was possible to create redirect with empty values.
Now, for new db, that will be required.

Fix usability according to first feedback
   - Redirect / menu should be visible without debug mode
     because user need it when they start their website and
     dont know at the beginning how to enable it (fgi)
   - fa icon in page manager was for blind people
   - missing widget on sequence field

Before this commit, an user could not create or remove a website.menu since
there was no list/form view for it. Changing sequence also impossible.
Therefore, it was impossible to create or delete a menu from an event. (you
could just edit the existing one)

Now, user can access in debug mode to the list and form view of website.menu to
manage the menus.

This commit also add a link on the ir.ui.view form view to access it's related
website.page

This closes #21302

Some actions were using `list` as value for the attribute `view_mode`.
This value is not valid, the list view is named `tree` server-side.

This was causing issues when setting `view_ids` (`ir.actions.act_window.view`)
on the action because `tree` and `list` were not matching correctly.

Closes #21056

Purpose
=======

The attribute name isn't required on the <filter> tag. If not set, it can't be selected with a xpath and it can't be overwritten.

A lot of PR are coming from the community just to add a name on a filter because:
- It can't be selected with a xpath.
- It can't be used with `default_search_foo` on an action context.

Specification
=============

Make the atttribute name required

Before this commit:
When you were on the page manager and you were editing a website.page's
content, it would redirect you to the website.page's ir.ui.view's form view in
the backend.
From there, you would'nt have an easy way to get back to the page manager:
your only option was to go to the website module and click on 'go to website'
and then click on menu/manage pages.
It was not convenient when you were editing multiple page quickly or just
taking a look into some pages.

Now, you have a button on the ir.ui.view's form view to get directly on the page
manager.

Note: this back button is obviously invisible for ir.ui.view not related to a
website.page