Move it in an external view to be able to place it at a different
location depending on the header template.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: b4866d192e6f4fdfba15b65fa2c209b35b7eb8c0
When a view is:
- a specific view (duplicated for a specific website)
- inherited by a new view that is translated
the inheriting view will also be duplicated, but the translation will
only be created for the generic version and not the specific ones.
With this changeset, we duplicate translation of arch_db terms of the
generic view onto matching specific views.
Without the change, added test fails with:
AssertionError: '<div>hello</div>' != '<div>hi</div>'
loading module translation copy translation from base to specific view
fixes#51579
opw-2261278
closes#52451closesodoo/odoo#53012
X-original-commit: 989d58d26f8803b40c1411cb97b0171b05d274d7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Since dd139948f0 when saving oe_structure for the first time, for eg.
a `<div class="oe_structure" id="oe_structure_part_1"/>` structure, when
edited we will create an inheriting view that fills it.
But this inheriting view would contain branding data and "data-note-id"
which would make this use case erroneous:
- edit page and fill oe_structure => data-note-id="1" saved on view
- edit page and add link in other oe_structure => error
This happen because the data-note-id refers to the editor of the
element currently being edited, since we saved it previously we get two
elements with `data-note-id="1"` and the code will just get the first
one which in reality could have not been in editing.
With this change, we strip the branding data on the parent element.
Without the change, added test failed with:
AssertionError: '<div class="oe_structure" data-test="1"
id="oe_structure_test" test="2">hello</div>' not found in
'<t t-name="dummy"><div class="oe_structure" data-test="1"
id="oe_structure_test" data-oe-id="55" test="2">hello</div>
</t>' :
saved element attributes are saved excluding branding ones
opw-2268836
closes#53321closesodoo/odoo#53346
X-original-commit: 855438be92ee71d8f8d5afedd52459e149ec49f7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Things to know about specific views:
Since the introduction of website specific views, we can have multiple
views that are related to a website (specific views). These views have
no xml_id as it is only set on the original view (generic view).
We rely on the view's key to identify related views as it is the same
for all specific views of a generic view. Also the key is equals to the
xml_id.
When a generic view is updated, we will check if the specific views have
the same values as the generic view. If it is the case, the value that
are the same are considered updatable and are updated on both the
generic and specific view. Else these are considered as noupdate.
When a generic view is created we will check if the potential parent
generic view has specific views. If it is the case we will create a copy
of the created view for each specific view.
The issue:
The method that checks if a created/updated view has specific views is
located in website. When we update a module, each modules are
initialized and updated in a specific order. If a generic view that has
specific views located in a module loaded before website this view's
specific views will not be updated/created as the method does not exist.
This issue is mainly affecting portal views at the moment.
The solution:
For write:
We now COW(copy on write) the views in base module, meaning this will
apply to all qweb views that are duplicated and not only the website
specific ones.
For create:
We will create the generic view as before but wait until we have
updated all the modules to gather all generic views that are supposed
to have a specific view but don't and create the specific views.
This will result in a change of behavior being that if a specific view
that have a parent is deleted it will be recreated on update
(same behavior as a generic view).
closesodoo/odoo#52629
X-original-commit: b1a90ee2bb441aa52e3cf4607c43fb464b55b1d7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: fja-odoo <fja-odoo@users.noreply.github.com>
When a theme module is updated the changes made on a view are considered
as user changes, prenventing the view from being updated in the future.
Fixed by comparing the arch being written with the arch of the original
view. If it is the same the record should not be noupdate.
Plus added a test to make sure the theme views receive theme updates
after being updated once.
Introduced by: https://github.com/odoo/odoo/commit/4acf177b4c55f3a16362cbeafea3d332ef4fe819closesodoo/odoo#51557
X-original-commit: 221470ab9c9eda3f3a4e2da0fa1a7bb23d6288cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
During theme install, theme.ir.ui.view are copied as ir.ui.view for the
requested website.
During theme update, those already created ir.ui.view will receive the
theme.ir.ui.view modifications, including the `arch`, even if it was changed by
the user, meaning the user changes would be lost.
Here are some examples which will be wiped away when the theme
is updated (only if the view is loaded from the theme module):
- Changes made from website HTML/CSS/JS editor.
- Changes made from website builder e.g. Theme modify footer with XPath
and user make changes in footer then user changes will be gone on theme update
- Changes made directly in the arch of ir.ui.view in the backend.
This commit fixes that behavior by not updating views which were modified by
the user.
closesodoo/odoo#49224
X-original-commit: 9906e1d403c4e9137a0313c342a455f425e95b8e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Kishan Gajjar <kishanegajjar@gmail.com>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The function get_inheriting_views_arch, retrieves the architecture of
views that inherit from the given view. In the case of the module init
is currently in process only views from modules whose code is already
loaded are taken into account.
Before this commit, the function didn't process views that has been
copied (copy on write, web editor, customize show, manual copy, ...),
this raise an error when trying to install a module. For example,
install module website_sale, copy on write the view 'Main layout',
install module website_sale_wishlist.
Now, views that has been copied are also processed.
opw-2181968
closesodoo/odoo#47590
X-original-commit: d5a2890b30f869c9b4cf7aafed0e05aff9440360
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Due to the infamous web_editor revert, summernote assets filesa are once
again created and stored in DB, but because they do not contain
'assets_' in their name, they would show up in the media dialog. This
commit fixes that by prefixing the created summernote assets file with
'assets_'
closesodoo/odoo#45298
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This reverts commit 404fa816403b60c0d6e36bef6f2c73f020ea5ff3.
The commit acts on some special case. But it seem to break some case
when there is a t-ignore or other directive at that same element.
Reverting because a good solution would need to take
into account t-attr-class and this might not be possible easily.
opw-2122947
closesodoo/odoo#42599
X-original-commit: da62f7e65bd1df67138fe9a82000f800dc0ff84c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In most use case, when we edit the website we have a situation such as:
```
<div id="wrap" branding-attributes="...">
<section class="mycontent">hi!</section>
</div>
```
When we modify a part, we replace all child nodes of the branded
element.
But if we had more complex content such as:
```
<div id="wrap">
<section class="mycontent" branding-attributes="...">ho!</section>
<t t-call-assets="web.assets_common" t-js="false" t-css="false"/>
</div>
```
we have a t-call inside the div#wrap, so branding is distributed to
child that could have attribute modified (eg. changing background).
Then if `<section/>` node is saved, the possibly modified attributes
are lost.
Without the change, the added test fails with:
'<div class="nice">hoi</div>' not found in '...<div>hoi</div>...' :
saved element attributes are saved excluding branding ones
opw-2122947
closes#40345closesodoo/odoo#40830
X-original-commit: 71b20a24c40ae9daa10076ab0fd656b043819cff
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Before this commit, it was not possible to install website_forum if the 'Main
Frontent Layout' had been COW'd.
When loading Forum Layout view which is a primary child view, it would crash
during view validation, not finding the element to xpath.
Triggering COW instead of copying fix the issue.
opw-2036119
closesodoo/odoo#35138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, for the following view tree:
P (active)
|
I (inactive)
|
II (active)
When calling `get_related_views()` on 'P', it would wrongly return 'II'.
It shouldn't, since its parent 'I' is inactive.
Step to reproduce:
- Go to /shop
- Enable ecommerce categories
- Enable Collapsible Cateogories
- Disable ecommerce categories
- Collapsible categories is still shown even if its parent got archived
closesodoo/odoo#35154
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
On a eCommerce page were there was no SEO optimization change:
- Customize > Activate "eCommerce categories"
- Customize > Activate "Colapsible category list"
- Promote > Optimize SEO > Change description > Save
Nothing happens.
Actually, an SQL error is raised because of the `ondelete='restrict'`
set at:
https://github.com/odoo/odoo/blob/897feb553e6ef75af9434cb77436b26abde3a761/odoo/addons/base/models/ir_ui_view.py#L212
In this case, we have the following structure:
```
View 1
|
---> View 2 (Website-specific)
|
---> View 3 (Website-specific)
```
For example:
```
Products
|
---> eCommerce Categories (Website-specific)
|
---> Collapsible Category List (Website-specific)
```
Since the inherited view (View 2) is website-specific, we duplicate it
and try to unlink it. However, this view has children, which raises the
error.
To solve the issue, we re-attach the children of the inherited view to
its copy. In a realistic situation, the children of a website-specific
view should also be website-specific, so there is no need to apply the
'copy or re-attach' logic recursively.
We end up with:
```
View 1 (Website-specific, duplicated)
|
---> View 2 (Website-specific, duplicated)
|
---> View 3 (Website-specific)
```
opw-1997946
closesodoo/odoo#33787
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when a view was removed during a module update (eg: the
record was deleted from the file), its COW views would not be deleted.
This could lead to unwanted behaviors including tracebacks(1).
This commit is somehow related/an extension of b5fe23055d that handle COW view
write during module update and 2e32cc5aa3 that remove COW views during module
uninstall.
task-1931683
Note: Some existing tests had to be run post install
(1) A view doing a t-call is COW'd, then that view and its t-called view are
removed. If the cow view is not removed, the t-call will crash (see tests
in this commit for detailed case).
closesodoo/odoo#31295
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit:
If a view A was doing a t-call on a view B and view B had view C as child.
And view A had view D as child.
And view D also t-call view B (that as mentionned above has view C as child).
And view D was inactive.
Then COWing C to set it as inactive would make `get_related_views()` on A to
return both generic active C and COW inactive C.
This rare case appeared for customize option that were enabled by default, like
wishlist, compare..
Disabling this customize option would show both the generic customize view and
the COW customize view.
Resulting in the customize toggle being shown twice, one enabled and one
disabled.
Detailed explanation:
1. `website_sale.products` would call `_views_get()` with `options=True` for its
t-call node `website_sale.products_item`, returning the full view tree,
including COW wishlist.
2. `website_sale.products` would then call `_views_get()` on its child views
with `options=extension.active`.
It is the case for `website_sale.products_list_view`, which also has a
t-call node `website_sale.products_item`.
It would then perform the same `views_get()` as in step 1. but with
`options` set to the view active state, in this case False.
At that point, the `_view_get_inherited_children` method would filter by
active before filter_duplicate, leaving the generic view over the specific
one as it should.
closesodoo/odoo#31286
Once `website` module is installed, the `save` method will always write on the
specific view or create it if it does not exist yet.
This means that actually, the generic view will never have his `arch` modified
through the `save` method.
Thus, there is no need to flag it as noupdate as we want to receive update for
that view (that might be used by other website without a specific view).
Since multi-website, we COW (copy on write) views when editing a view on a
website.
This is causing 2 issues related to module install/update:
1. During a module install, when creating an inherited view, it will create
that view as expected on the generic tree.
But that generic tree may not be used on website(s). Indeed, if the view
was edited, we are now using a copy of the view instead of the original
XML view (with an xml_id).
That copied view won't get the new inherited view in its view tree.
Now, we correctly copy the new view under every specific view tree (if
exists).
2. During a module update, when updating a view, it will only update the view
having the xml_id, so the generic one.
But most of the time, the generic view is not used as it was usually COW'd
and the specific view now replace the generic one.
Now, we also apply the update on the COW'd view. Note that only unmodified
field will be updated, this behavior basically mimic the noupdate behavior
on view's ir.model.data.
Step to reproduce for bug 1:
- Install website_sale module
- Go to a product page and then enter edit mode
- Make a modification to trigger COW, eg edit the information area under the
price "30-day money-back guarantee".
- Now install website_sale_comparison module
- The product page won't have the comparison button as the comparison view
inheriting the product view was created on the generic tree and not copied
on the specific tree (COW'd before the comparison module install).
Step to reproduce for bug 2:
- Repeat first 3 steps of bug 1
- Now make a modification in a view from the XML file in
website_sale_comparison module and update the module
- Only the view with the xml_id is updated, not it's COW'd views. This mean
that only the generic view is updated and not the specific one(s) really
used on the website.
task-1920487
closesodoo/odoo#29956
Before this commit, a generic view tree could be valid but impossible to copy
on a COW specific tree.
This was because when looping through inherit_children_ids to copy them, they
would be sorted by the ir.ui.view sort order (name, priority, id).
Indeed, when applying view inheritance and reading a view arch, children are
sorted by (priority, id).
Thus, if sorting the children by (name, priority, id) was different than
sorting by (priority, id) and the children view would conflict in that new
order, the COW would raise an error "can't find DOM element"
Step to reproduce:
- Create a parent view with just a DIV in arch
- Add a child view that add something inside that DIV
- Add another child view with a name alphabetically lower than the other
child and that replace the DIV by something else, like a SECTION
- Everything works as expected, when reading the parent view arch, the first
child is inserting something into the DIV and then the second is replacing
the DIV
- Now try to trigger the COW on the parent view by writing something on it in
a website context
- It will crash as the child views will be copied in another order, sorted
firstly by name.
- Indeed, when reading parent view, the second child will be copied first as
it's name is lower than the first, it will then replace the DIV by a SPAN.
When trying to copy the other child view that is supposed to insert
something into the DIV, the DIV will not be found and it will crash.
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
Before this comit:
The `_views_get()` method would be called recursively for every
`inherit_children_ids`.
At the end of the method, we would get the complete view hierarchy, including
duplicate hierarchies for website specific copies (COW).
Then, the `get_related_views` that is calling `_views_get()` would be overriden
in website module to keep only most specific views.
But this would not be enough as it would leave orphans from other trees:
- Have a base view 'B'
- That has an inherited view 'I'
- That has itself an inherited view 'II'
- Now make the hierarchy specific on a website from 'I'
- And add another inherited view to 'I' on the generic tree
This become:
B
/ \
/ \
I I'
/ \ |
II II2 II'
As explained, filtering duplicates would not be enough as it would correctly
remove 'I' and 'II' from the generic tree but would not remove 'II2'.
At the end, it would return "B", "II2", "I'" and "II'".
Now, we correctly return only "B", "I'" and "II'" by ignoring generic trees
when there is a specific one.
Closes#29347
In a particular case, `_views_get` was mixing apples and oranges, ir.ui.view
and theme.ir.ui.view.
This was the case if a theme has a theme.ir.ui.view t-calling another
theme.ir.ui.view.
(Only theme's sale bridge cause this issue, eg theme_kea_sale.products)
Then, having that theme installed on a website would make all other website
without that theme to crash when opening the /shop customize menu.
Indeed, the theme.ir.ui.view would have the xml_id theme_kea_sale.search.
The generic view `website_sale.products` would have `theme_kea_sale.products`
as inherit child which is website specific and t-call `theme_kea_sale.search`.
Then, on a website witout theme_kea installed, opening the customize menu would
call `get_related_views` that would call `_views_get` that would loop through
inherit children calling `_view_obj` that would not find a view with that key
and would fallback on self.env.ref, finding the theme.ir.ui.view.
Note: `_views_get` might return specific view for another website but that will
be filtered on `get_related_views` override in website.
Step to reproduce:
- Have at least 2 websites and website_sale installed
- Install theme_kea on a website, it will also install theme_kea_sale
- Go on the website that has not theme_kea installed
- Go to /shop
- Open Customize menu, it won't load because of python crash
opw-1914576
Closes#29347
Before this commit, when enabling a generic view from a specific website
context and that view already had a specific view for this website, the
view was duplicated again instead of writing on the already existing
specific one.
This is because we did not consider inactive views when checking if a
view that is being written already has a website-specific view.
closesodoo/odoo#28743
Before this commit:
1. If a view A is being inherited by a view B and C and the view C is doing an
xpath on B (but inherit A), then copying the tree to make it specific would
crash.
Indeed, when copying C, the view inheritance check (while doing the xml
check) would break since C would be tested against the generic tree and not
the new specific tree.
2. If a generic view being written with a website_id in the context had already
a specific child, we would copy both its specific child and generic child
for the same key instead of simply copying the specific one.
This happens if we triggered previously a COW on a child view, then only
that view had been made specific (and is still in the generic tree).
Then, when cloning the parent, we need to copy and make specific all the
hierarchy but ignore the generic elements if they already have a specific
one.
Now:
1. Fixed with adding the inherit_id on the copy vals
2. Fixed with filtering children_ids with filter_duplicate() before cloning the
children tree
opw-1908308
Closes#27914closesodoo/odoo#28405
Before this commit, when using the website editor, modifications were
saved in place in the original view. The view was also marked as non
updatable so that when an user migrates its database, he does not lose
its modifications.
The problem with this system is that users were able to keep their
modifications at the cost of having views which are not up-to-date with
the latest odoo updates.
Now, the views' content which is inside an oe_structure element is saved
in an inheriting view instead of the original view. The original
view is not marked as non updatable anymore.
Note 1: we only consider elements with the 'oe_structure' class which
also have an id containing the 'oe_structure' string.
Note 2: if a non oe_structure but editable content is edited, the
original view is still marked as non updatable (however, with the new
multi-website feature, this may not be necessary as the edited view will
be duplicated to be website-specific... we may want to disable the
behavior in a future update).
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
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.
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.
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
QWeb's get_template:
* remove the fallback that returned the entire result of IRQweb's
`load` if no match was made between the t-name of the first children
of this result and the template to render
* When get_template receives an etree, directly return it and don't
try to find a matching t-name in it. The loader was not called but
a matching was trying to be made, now that we removed the fallback
a lot of tests that were relying on passing etree didn't work
anymore.
IRQweb's load now return consistently the full result of IrUiView's
`read_templace` when asked to load an id or an xmlid. We make a special
case to patch the result if asked with an id or with a child view so
that the "t-name" of one of the first children of what we return is
always what QWeb is looking for.
This fixes the problem of recomputing that field in a much better way. The
field was stored for the sake of searching; instead we implemented a search
method for it.
The field was a stored computed field without dependencies, and therefore it
was never (re)computed. Add a simple dependency on the model `ir.model.data`
to make the recomputation everytime a view is modified. Moreover, when views
are created from modules, delay the recomputation of view fields until their
`ir.model.data` record is created.
Since saas-3, website controllers use `request.website.render`
to render the template of a web page. This was kept for retro
compatibility. It's time to stop using deprecated stuff.
Same for `_render` method on website.
'json' route don't use `request.render` since
`JsonRequest` has no `render` method.
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.
The `unittest2` package is simply a backport of `unittest` from the
Standard Library of Python 2.7 to previous versions.
There is no reason to use it any longer.
Closes#6941
Escape text nodes changed via the web editor before sending the content
it to the server controller.
It is done since the content is unescaped one time when being displayed,
and it is not done for inline style and script tags (which may be
injected by dropping a snippet) since that would break them.
replacing the solution in cdb900044.
When saving a template in version 8.0, html would be saved as it should
be displayed once on the site. In particular, if some text should be
escaped once send to the browser, it will be saved as such.
But when rendering, a text node content is unescaped two times:
* for translation which seems wrong since we already use .text of a node
which already escaped it, doing it one more time is bad,
* when rendering the template, since the html template is stored in xml,
This commit remove superfluous unescaping for translation, and add an
escaping when saving the changed template content.
closes#7967
opw-646889
Didn't manage to find RTE settings to avoid losing leading whitespace of
lines, so reindeint arch after doing all integration, right before saving back
to view's field.
* html.fromstring(parser=HTMLParser(remove_blank_text=True) does not seem to
work, so serialize to XML, and parse back with
remove_blank_text. remove_blank_text necessary for lxml's pretty_print to
work correctly.
* pretty_print only & always uses 2 spaces/indent level. Our files (and the
HTML editor's Format button) uses 4 spaces -> need a second pass to double
indents.
bzr revid: xmo@openerp.com-20140227125934-q8j3z440px2ic6kx
Before, would save view section itself (including root element). But
branding distribution (and thus editability) are set on the last
programmatic root, thus the root element may well be generated
e.g. <span t-att-foo> will define the span itself as editable.
Saving this would remove the programmatic content on the node, and
thus break the view section altogether.
Fix the issue by only saving the root's content in the previous root.
bzr revid: xmo@openerp.com-20131217112034-nbxbg919cffv4w51
Cocographique