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.
Currently, the menu are only translated for installed language when we
create a new website.
When we create a new menu (eg. by installing a module) or install a new
language we will only translate menu without website_id set, so the menu
are not translated.
With this changeset, we try to match translation of menu without
website_id to menu with website_id when translations are updated:
- when a language is installed/updated
- when a module is installed/updated
Without the changeset, the added test would fail with:
- "Menu in english" != "Menu en français"
Load translation add missing translation from template menu
- "Menu in french" != "Menu en français"
Load translation with overwriting update existing menu from template
fixes#43365
opw-2209864
closes#48031closesodoo/odoo#50498
X-original-commit: 998987f8ee148235f4025eb97a424e838ac6fc9f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Some apps, once installed, automatically create a menuitem in website.
What complexify the UI and create useless menu withtout plusvalue.
It is not because you install livechat to make support online, that you want
a link in your menu to show stats e.g.
Now we remove the default menu created, and help user to find it when he create
a link. The autocomplete suggest most of the main App's controllers
task-2189613
closesodoo/odoo#49081
Related: odoo/enterprise#9733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = mass_mailing, web_editor, website_crm, website_event, website_form,
website_forum, website_hr_recruitment, website_mail_channel,
website_mass_mailing, website_sale, website_slides
When an outdated snippet's option are activated we display a warning
in the left panel that inform the user about the potential
malfunctions.
To do so the snippet's template key is added to the snippet as
data-snippet.
If a snippet is "t-call" inside another snippet, it will need to use
t-snippet-call instead of t-call to have the key on himself.
Those unique keys are used on snippet selection to retrieve the
snippet's version in the left panel and compare it with the currently
selected snippet's version. Versions are describe with data-vcss,
data-vjs and data-vxml. If a snippet's key is not in the left panel we
consider that snippet as outdated.
Added some tests to ensure that t-snippet and t-snippet-call really have
their template key as data-snippet
Adapted the views to the data-snippet changes adding
data-snippet="tmpl_key".
Part of: https://github.com/odoo/odoo/pull/44569
task-2189669
closesodoo/odoo#50254
X-original-commit: 28a6cd49b6e87b75c2e70771e241c41778bf9e87
Related: odoo/enterprise#10236
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The (private) Rule.build method takes a values *dict* parameter. From
the start it was called with an invalid argument, but before 0.15
`append_unknown` would lead to just not using the argument at all
unless the rule is dynamic (aka has converters)[0].
In 0.15 the code was refactored and the `values` mapping is now used
in every case[1], leading to a pretty systematic error when calling
`search_pages`, which occurs any time an auto-completed URL field gets
used on the website e.g. when converting text to a link using the page
editor or when trying to update menu items.
Fixing this in 13.0 because while the current debian stable ("buster")
still bundles 0.14, the soon-to-be-released Ubuntu LTS (20.04) updates
werkzeug to 0.16. Debian Testing (bullseye) also bundles 0.16 but
isn't expected to get released for another year so it's less of a
concern.
Fixes#47356
Relates to odoo/docker#299
[0]
https://github.com/pallets/werkzeug/blob/c769200d1dcf1e21daaa2781f0c5109586daad42/werkzeug/routing.py#L797-L828
[1] https://github.com/pallets/werkzeug/blob/048cdfd9b969c0c3a133d7ff43b8ad1ad6a673ec/src/werkzeug/routing.py#L1020-L1032closesodoo/odoo#50194
X-original-commit: 4f1589075d2aae65c67a01c5c0f75c19c50a61d6
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.
This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.
Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.
Part of https://github.com/odoo/odoo/pull/48981closesodoo/odoo#48981closesodoo/odoo#49398
X-original-commit: e84a0bfdc99c21406861b88c02b11c925d92f927
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
In case a controller with a relative url return an absolute link
the current crawler follow the redirect and all external link of this
external url too.
Now we don't follow redirection if it is on an other netloc that the
current one.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
This commit introduce multiple improvements regarding social image:
- (perf) Don't read ir.attachment through `social_default_image` when it is
not needed. Use a stored boolean to know if the field should be accessed.
This will remove one SQL query in attachment for public user.
- Show website logo, not the company logo since we now have a different logo
for website.
- Don't show images lower than 200 width or 200 height px. Logo will be
shown regardless of his size.
- Don't show website logo if there is a website social_default_image.
Indeed, the spec was to prevent showing logo and social_default_image if
they are the same image. Technically, this is hard to identify as they
could be the same image uploaded with different resolutions (media dialog),
especially if one of those was uploaded through the backend and one from
the frontend.
It is most likely we will never correctly identify duplicate as they won't
be exactly the same.
For this reason, it makes more sense to hide the website logo if the
social_default_image is set. It avoids every issues while it makes sense
since you won't want to use the logo over the social_default_image. If you
really want to, you could reupload it through the SEO media dialog.
closesodoo/odoo#47848
Related: odoo/upgrade#1012
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
During the rte_translator tour, the step that adds and loads the fr_BE
language lasts a very long time. This time depends of the loading of
`.po` files.
For un unknown reason the temporary postgresql table created in
ir_translation.py may takes more times than usual. This, repeated for
each `.po' files, in enterprise, leads to a timeout of this step (more
than 60 sec).
As this seems linked to postgresql (or another external factor) and as
the purpose of this test is not to test the translation loading, the
present fix is to simply activate `fr_BE` translation for the website on
the server side before starting the tour.
The loading of translation is tested in test_translation_import module.
closesodoo/odoo#48621
X-original-commit: a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In case of short controller that don't use qweb template, we don't need
anyhting else that this url code that don't change frequently.
It make only sense for model like lang, website, ... that will not change
frequently. And are called on each call by the dispatcher.
In case of a website page, we will btw browse lang later, but in case of
small controller like /favicon.ico, or page without qweb, ... we can just
use the same from last query.
If model is already an ir.attachment we don't need to do a new search_read.
We can use it record directly.
After this commit, we don't do extra request if we already have the info,
else we don't change the behavior.
task-2211013
The dispatching layer of Odoo (common to any call) can avoid a query on website
if those 3 values are cached.
Note that for complex business flows, there won't be any gain since website
infos will have to be fetched at some point.
About user_id:
In most cases, for a website page you will need to browse the website btw so
we don't remove this request previously. But in case of a simple image, the
controller /web/content need the public user just to set the request.uid in
auth_public but no other info from website.
With this commit, we don't do the 'select * from website where id in()'
request on each controller declared in auth='public' but use the user_id
from the cache. (Invalidated by the write on website_id)
task-2211013
Co-authored-by: Jérémy Kersten <jke@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Most of the time, the record exists, but we still ensure it does, every single
time, making an SQL query.
Doing a try catch will result in the same behavior, but won't make that query
most of the time.
task-2211013
If we are rendering a page, the menus will most likely be rendered as well.
Note that even in a 403 case when the page is found but is not visible, the
menus will also be shown on the 403 page.
Fetching the menus before accessing the requested page will prefetch that page
as well in one go if that page is in the menus, without any costs for the pages
not in the menus.
There is a tradeoff for 'non-layout' pages, which only occurs in advanced
technical cases:
1. Create a page with specific extension as name suffix (page.css) in which
case the page will be bootstraped accordingly, without call to layout.
2. Remove the call to layout in HTML editor or backend
3. Remove the call to submenus template in HTML editor or backend
For those cases, the menus will be prefetched for no reason.
Note that homepage '/' is rendered through a controller, same logic is applied
there.
task-2211013
Render page flow:
- Search website.page in _serve_page for requested URL
- Check if the page is visible with `is_visible`
- `is_visible` will get the `ir.ui.view` of the page
Note that this is not 'cachable' as being visible depends of now() for the
publishing date
- Render layout which is getting the website menus
Note that this can't be cached either as a menu visibility might also
depends of it's website.page visibility which depends of now()
- Checking menus `is_visible` fetch the menus pages and those pages views.
Before this commit, every level of menu hierarchy would add 2 queries.
This can be avoided by prefetching everything in once during the dispatch if we
know we will render the website menu.
In such a case, read `is_visible` on every website menus will fetch every
pages, views and menus in the lowest SQL queries possible, eg one query for
every table.
For a 3 level menus, requests goes from 20 to 12 to load a untracked page.
task-2211013
- Refactor for easier readability
- Add a test to ensure menu hierarchy scale correctly.
- Add tests for image controllers
- Add test for assets controllers
task-2211013
visitor.partner is a many2one to partner. But partner.visitor_ids is a
many2many.
The result is when you set the partner_id on visitor, the (what should be)
inverse field is not set accordingly.
This inverse field should be a one2many fields. This commit fixes the field
definition.
Task ID: 2127691
PR #40577
Related: odoo/upgrade#905
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This will ensure the performances stay correct for a blank page (no layout),
a standard page and a homepage (which has its own controller).
Related to #47257
task-2211013
X-original-commit: 08e01b5fc4a71b8f7639a953137fbb546ddf3b3e
Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:
The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.
This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries
Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.
This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)
A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.
closesodoo/odoo#47283
Signed-off-by: Christophe Monniez (moc) <moc@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>
Previous implementation crashes randomly in chrome headless due to timeout.
Avoid to do web action, while we just want to check reset_password feature.
+ add one test that reset password on partner from website 2 to check that
link match the domauin from website 2.
closesodoo/odoo#47136
X-original-commit: d8019f25a5cd6ed611295e9b93111402f4cad04a
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
5ac269d722f fixed 7e2b0ebe799 that prevented the website menu to actually be
visible, since the JS in charge of displaying the menu was 'crashing'.
A test was missing to avoid that issue to appear ever again, since it is quite
a critical problem.
Note that it might look strange that breaking such a mechanism does not make
the runbot red, but since the menus are actually considered visible, the tests
are able to 'see' it in DOM and click on it.
They are actually hidden through an opacity 0 & height 0 while the JS process
them.
task-2093679
closesodoo/odoo#47138
X-original-commit: 0dc00a252dfe7fee658579a60dc7b1b1ca71a661
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This test goes to the public homepage and directly logs a 'test
succesful'. It's useless as many other tests use the public homepage and
therefore, those tests will crash if the homepage is unavailable.
Moreover, it happens to trigger random failures due to the fact that
some RPC may occur between the cookies cleaning and the termination of
the browser.
Typically a "GET /web/webclient/locale/en_US" can be triggered right
after the clearing of the browser cookies, cache ...
closesodoo/odoo#46004
X-original-commit: 3aded126e78b18f8bb753f1b57b827667ca99d18
Signed-off-by: Christophe Monniez (moc) <moc@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>
in this commit, throw the wizard to enter the new page name, while duplicating
page button and new duplicate page button added in the page properties dialog.
updated the test case related to duplicate page along with duplicate menu
consideration.
task-2088546
closes#40085
Co-authored-by: jpr-odoo <jpr@openerp.com>
*: web
Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.
This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.
Part of https://github.com/odoo/odoo/pull/44596closesodoo/odoo#44596
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
An http-port provided on the command line (may also have been an issue
for config files, didn't check) would not be taken in account anymore,
because `odoo.tests.common` would be imported during the import of
`odoo` itself (when loading odoo.service.server), itself importing
`odoo.tools.config` leading to a default configuration being set up.
* remove `odoo.tests.common.PORT`, `config['http_port']` should be
used always
* defer the import of odoo.tests.common by moving it inside
load_test_file
* stop generating default configs
closesodoo/odoo#43283
X-original-commit: 45871f498ea4cf3ada719692e69cd413883ab442
Signed-off-by: Xavier Morel (xmo) <xmo@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>
If a visitor logs in (and has a visitor_id in his cookie), the partner will be
linked to the visitor. If, after 1 week, the visitor tries to connect again
with a different session (or another visitor_id in cookies), the authenticate
will crash because
* _cron_archive_visitors applies on visitor inactive since at least a week
* there can be only one visitor per partner (sql constraint)
* the visitor linked to the partner is not retrieved (because archived) and
we try to link the partner to a new visitor.
Further than that, if the visitor is archived and the linked partner wants to
login again with a new visitor_id, we should
* reactivate the previous visitor,
* copy history from newest to previous one,
* delete the newest one
Note that last two points were already done before this commit.
Task ID: 2120464
PR #40199Fixes#40077Fixes#40301closesodoo/odoo#41273
Original-signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
X-original-commit: 53a6bed3b5c1ae09be490254ed09f18acbb970c4
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
This commit fixes 2 issues, both coming from a misbehavior in
`get_nearest_lang()`:
1. Anyone could reach the website in a lang available in backend but not in
frontend. Eg, french is activated but not a website lang, going to `/fr`
would show the page in french.
2. As a logged in user coming from backend in a lang not available in frontend
(has request.lang set to that lang), the website would show a 500 error page
since it would not filter out the current request lang.
Both these issues are fixed here by ensuring langs are filtered out if they do
not belong to the frontend (website langs).
Step to reproduce (bug 1):
- Install french in backend lang (not on website)
- Visit `127.0.0.X/fr_FR`, the frontend will be displayed in french even if
it not a lang available in frontend.
Step to reproduce (bug 2):
- Install french on frontend and remove english from frontend
- Navigate to the backend /web
- Navigate to frontend, it will crash
Fixes#40572 and fixes#40078closesodoo/odoo#41146
X-original-commit: 4bfba037fbbf34c178abd532f7bf52b94ae40b27
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Missing / wrong indented code during rewrite of binary controller:
https://github.com/odoo/odoo/commit/7d85ab1#diff-1407a8ce197a04eefaefa26c127a4418L343-L348
In case you have:
<record id="s_cover_default_image" model="theme.ir.attachment">
<field name="key">website.s_cover_default_image</field>
<field name="url">/web/image/theme_treehouse.bg_img_15</field>
</record>
theme_treehouse.bg_img_15 will be not found in /web addons.
So we need a 301 redirect too.
opw-live
How to reproduce:
odoo.com/trial > Website > Install theme Clean
Drop first snippet > background is 404
closesodoo/odoo#40605
X-original-commit: b8ce93e4eb397e1b7a0e1d408d61d2f283223fb9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
load_lang was a kind of hybrid method trying to active or creating a
language if not found. This was error prone.
Instead rely on two methods with clear purpose:
ResLang._create_lang(lang, lang_name=None)
- create a new res.lang entry using the locale of the server
return the res.lang record to match the API of _activate_lang
ResLang._active_lang(code)
- activate the given code lang
Most of the time, _active_lang is what is expected
tools.trans_load_data and IrTranslation._load_module_terms no longer
activate the language if not active.
Loading the translations should be explicit on an activated language,
it is too error prone to silently activate/create a language if not
found.
Remove lang_name from trans_load_data as no longer needed.
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>
Those tests were raising an assert error if the DB has other websites than the
data/demo ones.
As we have a new module in Odoo 13.0 (odoo/design-themes#178)
which is creating 25 websites, and since the design-themes runbot is now
running tests, we were having a red design-themes runbot.
closesodoo/odoo#39145
X-original-commit: 67df6b91ddb6cb83d558137691481f50834f7fca
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This test was raising an assert error if the DB has other websites than the
data/demo ones.
As we have a new module in Odoo 13.0 (https://github.com/odoo/design-themes/pull/178)
which is creating 25 websites, and since the design-themes runbot is now
running tests, we were having a red design-themes runbot.
closesodoo/odoo#39008
X-original-commit: 5c7b446363fbec7b2a76a579794e0fac20d05271
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When you try to create two users with the same login, the shown error message is
the Postgresql integrity error instead of a nice (translated) validation error.
This happens since bf88f3e which changed the way error messages are translated.
The reason is the manually created unique index `res_users_login_key_unique_website_index`.
The error handling and translation mechanisms don't know it exists.
The index was created for performance reasons in commit b5a12b4 where the
original python constraint was replaced with this custom SQL index.
In this commit, the python constraint is re-introduced to remove the index hack,
but the implementation now uses a single SQL query, which should be quite fast.
closesodoo/odoo#38737
X-original-commit: 817a811ec98b0c313b12e6464b5e98ca432cb3fc
Signed-off-by: Christophe Simonis <chs@odoo.com>
Nicolas Lempereur