* web_editor
This commit's goal is to optimize the delay to make a scss customization
thanks to the website customize dialog. Before this commit, the JS code
took advantage of existing web_editor routes but this was far from
efficient as this was done:
1) PY: Load all scss files used in the page
2) JS: Find the one we want to customize and adapt the scss content
3) PY: Create the scss customization with the new content
(So two RPC (including one very slow) and content building in
javascript)
After this commit, this is done:
1) PY: Load the scss file being customized, adapt its content according
to the new values and save the customization
(So the whole logic is in python, requiring only one small RPC)
This commit also take the opportunity to review the web_editor ace
editor loading code (the logic is shared with website customizations).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
- Make the controller part more readable and more efficient (O(1) ORM
operations instead of O(n)) and remove deprecated code.
- Add the possibility to have a toggle standalone option. This is
used as soon as an `<opt/>` is alone in its container (note that now,
the container can be any tag and will be ignored during rendering).
- If an option has no specified 'string' to attach to it, the name of
the first view it toggles will be used.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Since AST was introduced to compile Qweb templates, the reset templates
functionality is not working anymore.
Actually, it does not even appear anymore as the conditions to trigger and show
the reset view behavior can't be True anymore.
Indeed, the code is still importing the old QWebException from odoo.exceptions
which is now just an empty class.
The QWebException that should now be used is the one from odoo.base.models.qweb
More than just a wrong import, the QWebException properties have completely
changed.
Since its last working version (Odoo 9.0), a lot of changes occured, mostly:
- Odoo 11.0: new model website.page, which completely changed the pages
behavior and changed the models.
- Odoo 12.0: multi-website, which introduced the Copy On Write (COW) that
redefined how we write on view in a website context. We now need to reset
copied/specific views that have no model_data_id.
This fix is for a stable version. There is some flows that can't be fixed
without a refactoring or new fields (mainly because of the arch_fs being
erased when writing on `arch`, plus we can't introduce a module reload in
stable).
The goal of this commit is to fix the basic and standard case of broken views,
which is when non-technical users are breaking the views through HTML editor.
To reset the views, we will read the original arch in the XML file, as the
dev mode is doing.
To be eligible for the reset, the broken view need an `arch_fs` set. If the
view arch has been modified anywhere else than the frontend, the `arch_fs`
will be erased and the view wont be able to be reset.
As the broken views will be specific views, we will simply read the generic
view in the XML file and write it on the specific. We can't simply remove the
specific view as we might be on a specific tree.
Specific case, in case of custom views create dropping a snippet in an oe_struc
we just delete this inehrited view to allow end user to have their page back.
In some case of bad compilation in sub template, we try to guess which inherited
view, t-called view is broken by string matching based on 'last_path_node' xpath.
Add new module test_website to add tests, it will be usefull for futur test of
install/uninstall and ...
Todo in master:
- try to track on QWebException the real template that is broken and not only
the last node from the main template.
Co-authored-by: "Romain Derie <rde@odoo.com>"
Co-authored-by: "Jérémy Kersten <jke@openerp.com>"
closesodoo/odoo#29957
With multi-website, activating a customize option (customize_show view) will
actually duplicate the customize view to make it specific.
By doing so, the duplicated view will have a higher ID than the original, and
the original's siblings customize options.
Before this fix, two issues could be seen:
1. When toggling a customize option, it would appear last in the dropdown
afterward. This is because of the views being sorted by (priority, id)
(if the views have the same priority).
2. When toggling, sometimes the views header would be duplicated. This comes
from the JS code that loop through the returned views and create the DOM
by adding a header when the view inherit_id is different than the previous.
Obviously, as 2 views with the same inherit_id could not be grouped together
now that the specific one has a bigger ID, it will create twice the DOM.
=> Check tests in this commit, they have schemas that will explain it clearly
Note: We don't take priority into account for customize menu view order as it
would create the same problem as (2.)
We could have sorted by (inherit_id, priority, name) to avoid the issue
and give the user possibility to order options in header but it was
decided we dont.
Closes#29347
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
The code used the xml_id field instead of the key field at some point,
so the modal was not fetching the proper views.
This commit also removes the useless code in there.
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, 5ff87e8039 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
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.
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677
In the portal module,
the `index` method from the `web` module controllers
is overriden to redirect `/`
to the portal `/my` for the portal users,
instead of the regular backend `/web`.
However, when `website` is installed,
this behavior should not happen,
as you would like the signed in portal users to
be able to see the website homepage,
and not to be redirected to `my` when
they try to access `/` root path of the website.
Because the override in the website module was done on the
`index` method coming from the `web` module instead of the `portal`,
according in which way the Python module were loaded,
it sometimes redirected to `/my`, sometimes it correctly
displayed the homepage. This is because the modules are not
loaded in a determinist order.
To summarize, on runbot, if you logged as portal/portal,
one time on two you were redirected to `/my`, and the other
time you saw the homepage correctly.
As `website` depends on `portal`,
we have the possibility to override the `index` method
of `portal` instead of the one of `web`,
to force the determinist order,
and therefore the determinist behavior of the homepage for
portal users.
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
Before this commit:
1. If the website's homepage is unpublished and a public user naviguate on it,
it will log an access read error in the server. The user won't see the error
though.
2. If the user can't access '/', we serve the first menu's page instead.
This first menu's page can be an unpublished page, resulting in a 403, which is
not convenient.
3. Menus are sorted by sequence, then the ORM sort them by write_date.
Menu with same sequence will be sorted differently every time you edit one of
them. (This issue get hidden/solved if user edit and save the menus with
"Edit Menu" since it will recompute every sequence.)
- Create 3 pages 'A', 'B', 'C', with 'Add page in menu' enabled
- Menu is now 'A B C'
- Edit website.page B (in property dialog), it will write on the page's menu
aswell
- Menu is now 'A C B'
Now:
1. We prevent this error by ensuring the page is published and so can be read
by anyone before accessing its properties.
2. We serve the first menu's page that is published
3. We sort menu by id after sequence to keep original order
This closes#21259
This reverts partially commit ab2283ef83.
This commit clean and clarify some code.
It also secure the call to specific page extension's template to avoid somehow
calling unexisting tempalte
Before this commit:
1. You could create a page with supported extension in the path (eg: myfile.js)
You would then be redirected to the webeditor (myfile.js?enable_editor..)
But in this case, it would just redirect you to a plain text page without odoo
layout because supported extension are rendered with a specific mimetype.
(is it is a .js page, it will just render the page content as a js file)
2. These kind of page would still call t-layout that you should be removed in
backend in order to make it work
Now:
1. You will be automatically redirected to the back end to edit your file
instead of landing on a text-only page.
2. Supported extension now have their own template (eg: .js file now have
<script text=..> tag added automatically in their content)
- labelling and screen redesign (update labels, hide labels, hide fields, ...)
- make UI more mobile friendly (icon biggest, color using less variables,...)
- Page & Redirection menu are for visible only in debug mode
- Add meta noindex for website.page not shown in sitemap
- Add mechanism to be able to edit in backend a broken view
(Needed for - Internal Error 500, css, js file, ...)
- website pagemanager dedicated to website_publisher only
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/...)
In a multiwebsite environment, (de)activating some theme views produces
undesired results if the same view exists in different ways for different
websites.
With this patch, we search before for a website-specific view with the provided
key, and fall back to the XMLID-found one if there is no specific view.
This commit closesodoo/odoo#17970
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
Code managing language in URLs and redirection is moved from website
to http_routing. Override of _dispatch in website now consists in adding
website to the request.
url_for and is_multilang_url tools methods are also moved from website
to http_routing.ir_http as those are required for the moved code.
Some renaming is performed on request attributes previously added in
website. Indeed as website keyword may be misleading now a renaming
has been performed to better understand them :
* request.website_enabled -> request.is_frontend
* request.website_multilang -> request.is_frontend_multilang
* request.httprequest.cookies.get('website_lang') -> ('frontend_lang')
* first_pass variable in _dispatch is replaced by a new attribute of
request, routing_iteration, that is the number of routing iterations
currently done
Slug and unslug API is now available in http_routing. Indeed there is no
link to any website or any reason to not support slufigied URLs when
website is not installed. A new unslug_url method is added as a tool
coming from an embedded method from website. Doing it allows to have all
slug related methods defined at the same point.
Support of slug and unslug in qweb rendering is also moved directly in
http_routing version of ir_ui_view instead of website inheritance. This
is done in order to keep things coherent.
Some code from website about ModelConverter is also moved. Indeed both
versions of ir_http uses some kind of placeholder to store the uid
when converting urls to python. This commit unifies it by using the
website one directly in base to simplify the override.
This commit also updates all module importing slug. Enterprise modules
will have to be updated, see related commit.
Before this commit, the session object was responsible for loading the
translations in the backend only. There was then ugly code in web_editor
(which is also loaded in backend...) which was doing "if frontend then
load translations by myself". This code was also translating templates
while this is the qweb object's job. Now session is always responsible
for loading translation.
Note: the session object should be refactored/split.
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
* cross-version metaclass spec
* more formally deprecate browse_record and browse_null since they
were using metaclasses anyway
* update docstrings referencing the latter
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
About a `sudo` on ir.ui.menu, this commit (3649b7f359) removed it,
this commit (3d0cc2d6d2) re-added it.
Since portal user can not go on /web anymore, I think portal does not need to read ir.ui.menu.
Here some news scenario:
- if website is not installed, portal can log in, but will be redirected to login page
with an error message 'only employee can access'. Indeed, there is no page to display for
such user.
- if website is installed, but not website_portal, portal user can log in and will be
redirected to homepage. If he tries to manually access to /web, he will be redirect to
login page with access error (even if he will still be logged).
- if website_portal is installed, the portal user can fully enjoy its features.
Christophe Simonis