| Age | Commit message (Collapse) | Author |
|---|
|
closes odoo/odoo#31520
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
Next commit will change that file to make it extend a web_editor model
instead of a web_editor controller. This commit only moves the file.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
|
|
|
|
|
|
This reverts commit 99f497b390e680629dce3a7e2e282ada74ee9884.
|
|
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>
|
|
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.
|
|
Each qweb widget should now explicitily define a method
`get_available_options` which specifies all options used in the widget
rendering.
The options are a dictionary with the option as key and the option type as
value (e.g. string, integer, array, model, etc.).
This is used by the Studio report editor (to customize widget options) and parsed
in JS.
|
|
Replace hacks introduced in V11 by the proper solution.
|
|
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
|
|
|
|
In the module website, the relational field website_id is defined twice,
once for ir_ui_view and a second time for res_config_settings, for the
former we perform an ondelete='cascade', which means that when the
website model is unlinked, the field is unlinked as well.
This is not done for the website_id field in res_config_settings, which
instead defaults to setting the field to NULL, which violates a not-null
constraint and therefore causes issues when trying to modify/save
settings.
To solve this, a hard delete of the ir_model_field website_id is
performed during the uninstall process of the website module.
Fixes #21905
OPW 803018
|
|
|
|
The ORM does not currently, an probably won't support two fields with
the same name in different modules that do not depend on each other.
This is obviously a nasty hack, but it's the best one can do for a
stable branch.
THIS IS WHY WE HAVE DEPENDENCY MODULES, PEOPLE.
|
|
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.
|
|
Now that we only have one model (res.config.settings). Uniformize everything according to the guidelines.
|
|
This module adds required base code for a fully integrated customer
portal. It contains the base controller class and base templates.
Business addons will add their specific templates and controllers
to extend the customer portal.
This module contains most code coming from odoo v10 website_portal.
Purpose of this module is to allow the display of a customer portal
without having a dependency towards website edition and customization
capabilities.
Some CSS files used in frontend assets are already moved to have a
working portal skeleton. A is_public method on users is also added
as it will be used in various portal code soon.
|
|
|
|
* LDAP import: python-ldap is not python3-compatible, pyldap is
Warning: only supported from debian Stretch (current testing)?
https://packages.debian.org/search?searchon=names&keywords=pyldap
* implicitly relative imports
* imports of moved or removed stdlib modules
issue #8530
|
|
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.
|
|
|
|
for html field) and website
|
|
to mail. The only use was to update a method of publisher_warranty.contract
model that is defined in mail.
This code has been moved to the bridge module between website and mail
aka website_mail.
Dependency to share has also been removed.
|
|
This commit impact crm, website, website_sale and web_planner modules because it
- add planner for website and website_sale
- improve planner notebook by setting texterea and input size to 100% and using col-md-* class
- split js code into common part (used in backend and frontend) and backend part (only for backend)
- adapt some tour, since every page will have the planner modal in its DOM, the tour selectors msut be more accurate
- introduce some style fixes and adaptations
- ...
|
|
|
|
website: added website/action/<id_or_xml_id> route, that runs the server action designed
by its id or xml_id. Only code server action returning a template give a result. The
template is displayed. Other or not existing server actions redirect to the homepage.
website: added an override of ir_actions_server: evaluation context gets request for
evaluation, to enable request.render(template_name); also returns template the same
way action is returned for code server action;
bzr revid: tde@openerp.com-20140205090447-2hppg7818nx1wfzh
|
|
bzr revid: chm@openerp.com-20140127173816-uldoee71h7ntpyhl
|
|
read pricelist to evrybody and use superuser for saleorder in website_sale
bzr revid: chm@openerp.com-20140107085728-77mxlims6fa0li76
|
|
bzr revid: xmo@openerp.com-20131115132626-60p0yk3jv1pk6mhb
|
|
bzr revid: xmo@openerp.com-20131014121319-ry0s5tnpz5f21aw0
|
|
bzr revid: xmo@openerp.com-20131014085459-dhbypq0hg3lzzf3j
|
|
bzr revid: al@openerp.com-20131013030806-2236jpszm1morlg6
|
|
access rules evaluation.
bzr revid: chm@openerp.com-20131010090229-8cz9ophrqlayw00x
|
|
bzr revid: xmo@openerp.com-20131009133112-05dglhptiw019838
|
|
bzr revid: xmo@openerp.com-20131008092233-9su66923zthl9jyg
|
|
bzr revid: chm@openerp.com-20131003150048-elm5kiwabrh1j6gt
|
|
Also, html.fromstring does weird stuff when encoding is not specified,
force to utf-8 just in case.
bzr revid: xmo@openerp.com-20130930145358-qh7xdicgg21prsk4
|
