Commit Graph
7 Commits
Author SHA1 Message Date
Jeremy KerstenandDerie Romain 8300155cd6 [IMP] website: res_config_setting make most key website specific
google analytics, google map api key, ... can be set by website

Remove useless duplicated label

Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
2018-08-13 20:16:34 +02:00
Jeremy KerstenandDerie Romain 62d73253f3 [ADD] website, base: improve name_get in case of multi_Website mode
In some case like for website_menu or res.partner from the sale_order form view
it is nice to know easily on which website this record is depending.

Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
2018-08-13 20:16:34 +02:00
Joren Van Onder 4f6ec1cd2a [IMP] website,*: support multiple websites
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.
2018-08-13 19:51:10 +02:00
David Vidal 5e038eedeb [FIX] website: gmaps size parameter flipped
- width and height were passed in the wrong order according to
https://developers.google.com/maps/documentation/static-maps/intro?hl=en#location
2017-11-21 10:08:41 +01:00
Nicolas Martinelli c82b65c855 [IMP] website, website_{*}: Google Maps API Key
As of June 22 2016, the use of API key is required to access the
following:
- Google Maps JavaScript API
- Google Static Maps API
- Google Street View Image API

https://developers.google.com/maps/pricing-and-plans/standard-plan-2016-update

For domains accessing the API before June 22, it will still work without
an API key. Since Google advises to use the API key, we hide the Maps if
no API key is defined.
2016-08-25 16:33:23 +02:00
Ravi Gadhia fd09ddb6f3 [MIG] website: migration to new api
Migration of website module to new API.
The tricky phase is ir_http.py : we need to use `request.env`
only when the authenfication phase is done. Normally by
calling `super` of `_dispatch` method, but website module
required it to be done before. This is important since
`env`is a lazy property of `request` object.

Some hack were kept since this commit is a migration ('RequestUID'
in ir.http, ...)

Some docstrings were added.
2016-08-04 12:02:14 +02:00
Jérome Maes 73749499f0 [MOV] website: split files, reoganize file per models 2016-08-04 12:02:13 +02:00