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
* 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
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).
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
Because of 9a98a4d60e
and since the key of an ir.ui.view cannot be unique
(multiwebsite), duplicating views made several parts of Odoo crash
After this commit, we limit to one the views that are searched with their key
Responsibility is given to the user to change the priority and/or the key
in order to predict which view will be taken
OPW 1913335,1913100,1913186,1913112,1913240
closesodoo/odoo#29105
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.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
Since https://github.com/odoo/odoo/commit/5a030db3eb77b6d80187f8ae1a64303b2f50391d
the HTML editor displayed the translated versions of the templates it
allows to customize. So if the user edited and saved such a template,
the non-translated version was saved with translated-version content.
The behavior before the mentioned commit was:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, re-make a RPC to load the view again
The mentioned commit made this simpler by making:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, simply show the previously loaded view
... the problem was that the step (2) of the old behavior was
explicitly saying (client-side) to load the view's untranslated content.
This commit makes step (1) always load the untranslated versions of the
views (server-side).
web_editor dirty elements are saved by calling the ir.ui.view `save()` method.
As this method is called through call_kw _rpc on the ir.ui.view model, self
is binded to the view which has the `id` sent in the request.
In some cases, when editing a field for example, the id sent is the id of the
field's record (eg: product.template for price field).
In that case, the view binded on self will be the view with the id of the
field's record being edited.
If there is no ir.ui.view with the same ID as the field's record, self won't
exists.
This misbehavior resulted in no error luckily since we only use self to call
ir.ui.view methods without ever using self properties.
Since multi-website 47b00c5d53 overrided the `save()` method and used self.key
it was crashing when the self record did not exists.
This commit will fix that by doing the multi-website check only when it is a
view and not a field that is being edited. (We know that if xpath is set)
opw-1904637
Step to reproduce:
- Go to a product on ecommerce, eg product.template 13013
- Edit the product price field, the oe-id attribut is 13013
- Delete the ir.ui.view that has the same ID than the product (13013)
- Save -> It will crash since self is binded to "ir.ui.view(13013,)" but it
does not exists and we try to access key
closesodoo/odoo#28469
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).
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
The ir_translations were pretty slow to load, this was mainly caused by
the condition in variable 'find_expr' and the import of po values in the
temporary table.
To improve the load performance, we made two improvement:
1. Insert the row in the temporary table by batch instead of making an
insertion for each record.
2. Replacing the condition in the variable 'find_expr' by partial unique
index. To perform such a thing, we had to separate the type model in
two types, 'model' and 'model_terms' because it wasn't possible to
create a partial unique index on type 'model' because the type was
used for two different use cases. The type model is now used for
fields that have have a value not callable for the attribute
translate, these field can only have one record for the same field,
model, res_id and language. And the type 'model_terms' is used for
the fields callable, because they can have multiple sources for the
same res_id.
We also removed the deprecated types 'report', 'help', 'view', 'field'.
Thanks to @rco-odoo for the improvement of the first point.
When generating new translations (e.g. 'edit translations' button on a view or
on a translatable field), the new generated translations have the source as
translation value.
Set the state to 'to_translate' as it is the default value
This change requires to add a fallback in web_editor when computing translated
dom
When a translation has no value, there is a fallback done in the different
translation method (e.g. xml_translate) but, as the node was manually created
in edit_translation_mapping, the fallback was missing
closesodoo/odoo#24391
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
In Studio, users can create views, reports, etc. which do not have an
xml_id (no record in 'ir.model.data' from import/install).
After this modification, the template can use the t-call using a readable
key on newly created views.
Before this change, the reports were generated in editable mode for branding
to be applied. The branding is used to cut the report and add on each
selected record for generating the pdf.
Applied branding and editing options takes a useless time and branding
was also applied by widgets even if branding was not requested.
Application of a fix more specific to the problem of the contact widget
which can not serialize the dictionary because it contains the values of
the context of which browse record. (because contact try to
json.dumps options for multi-edition feature in web_editor)
opw-1859848
https://github.com/odoo/odoo/commit/ab85e9594651fd33ffd2747f4d3c5b360e7c7922
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
Currently some base context used for evaluation is computed when rendering
QWeb templates. Evaluation context is build in base and improved notably
in website module.
This commit adds an option to skip this context build and have a minimal
evaluation context based on given values. Purpose is to avoid having to
search and browse unnecessary content when evaluating some custom templates.
When we know precisely what we need when rendering a template there is no
need to add unnecessary items in the evaluation context.
This commit is related to task ID 1817951. Closes#23291 .
Before this commit, when the shop was in multi images, the main image was not refreshed when changed in the back end.
This was because of the ?unique parameter that was computed on the product variant image. Hence, when the product image changed, the variant image did not, the hash neither, and the image wasn't refreshed
This commit fixes this by adding an option to the qweb.field.image
OPW 765287
closes#19133
Currently the image field rendering in QWeb using the /web/image
controller is done in web_editor. However there is no link between
the web editor and the rendering. The rendering can therefore be moved
directly in web.
During the move two options have been added to the rendering of image
field :
* qweb_img_raw_data: fallback on standard base64 behavior that is
otherwise impossible to achieve;
* qweb_img_responsive: True by default, add the img-responsive
class that is not always requested;
Thanks.
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
Romain Derie