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>
*: 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>
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>
When executing test on an existing database with other module installed,
browser_js test tends to crach because not all models are available
in registry. A wip will force all js test to be executed in post_install.
This will also have a side effect that make rte_translator test
fail randomly more often since more module are installed, fix is done
in next commits.
In the call to Chart.js we pass a ctx which should be a DOM element,
however we pass `null` as the ctx.
It seems that what happens is that we look for the DOM element inside
the `document` (via getElementById) but this element is not yet inserted
into the document, hence this returns `null`.
Since we already have a reference to the canvas element which should be
used as ctx, we can probably just reuse this reference
closesodoo/odoo#36072
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, every model having website_id would have the default
`set null` as ondelete value for that field. Exception for `ir.ui.view` and
`website.redirect` which are set to `cascade`.
This meant that deleting a website would basically transform all its specific
records into generic ones.
That would lead to unwanted behavior, such as multiple `ir.attachment` with
same URL, when 2 websites had been theme-customized. Deleting one of the
website would result in later crashes when trying to open theme customization
in the remaining website(s), since those website would find their specific scss
custom attachment as well as the generic one from the deleted website.
Probably more behavior might be problematic when deleting a website before this
commit.
To summarize the choice of this commit implementation, every model not existing
outside website module are set to `cascade` (website.redirect, website.menu,
product.wishlist..).
The rest should be in restrict, as we don't want to delete a whole forum, blog
or job, which should probably be managed case by case to decide what to do.
Thus, restrict is a good choice to notify user of what should be handled.
Some exception remains, ir.ui.view should be delete on cascade while sale.order
should be set to null.
opw-2038414
opw-2035249
closesodoo/odoo#35398
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
It was impossible to open the website's edit mode as a user with
"restricted editor" permissions. The reason was that wysiwyg_multizone
was trying to manipulate data that is not injected into the html node
when `editable` is false (see `website.layout` template).
closesodoo/odoo#31702
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
With the following view hierarchy:
A
|
B' (oe_structure_ID view)
Before this fix, when saving multiple templates at once from the same hierarchy
the COW views (website) would not be saved correctly as the first call to
`write` would COW the parent view, then the second concurent call to `write`
would create the child specific view under the generic parent view.
Instead, the generic parent should have been cloned to a specific parent view
and then the child view should be COW under the specific parent.
A A'
| |
B' B*' (This one is the old B', without B' changes in the html editor)
Instead of
A A'
|
B'
Calling the `write` one after another will do the trick. Indeed, when the
second call is fired, the first call has already triggered the COW behavior.
Thus, the second call correctly retrieves the COW view.
Another issue might still appear, if the parent view write is sent first.
Indeed, the parent view will be COW, thus the specific child view (second write
waiting to be fired) will be deleted to be added on the new specific hierarchy.
Thus, that write will then raise an error since the view does not exist anymore.
task-1934279
Fix#30447
Before this commit, the syntax to start a tour was extremely verbose.
With this new method, it is possible to start a tour by just giving the
essential parameter: the tour name.
The full set of features from browser_js are kept by using **kwargs.
closesodoo/odoo#32316
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
* crm, project, website, website_event, website_blog, website_forum,
website_sale
Eg: the tour 'shop_buy_product' is extended by the website_sale_options
addons to add a step to close a modal.
The current solution was requiring the module that defines the tour
to extend, then add/remove steps in the "step" key of the tour
definition.
Some of the problems with this method were:
* The "register" method calls the "update" method to immediately
search for tip to place once registered (as register may be called
after the DOM is ready). So extensions of tours were happening after
the tours were started (and the tours were not restarted).
* The addition/removal of steps was happening after they were filtered
according to the "edition" key.
To allow extension, the system is changed as follow:
* The "register" method now only saves the steps and options without
modifying them and does not call the "update" method.
* Once the DOM was ready, the tour service started listening to DOM
mutations and called the "update" tour method. Now, this "update" call
is replaced by a "_register_all" call, on DOM ready and at the end of
the current call stack (which makes sure all modules are loaded). This
"_register_all" method marks the registered tours as ready after having
filtered the steps according to the "edition" key and initialized the
current step to trigger.
* Also, tours can now define a "wait_for" option which allow them to
be marked as ready for run and update after the given deferred. Those
tours can now also be extended without having to wait for the deferred.
PhamtomJS must wait for the "ready" key to be true to run the tour.
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.
* / fails to load, it turns out Tour is undefined because unlogged home does
not load bootstrap-tour
* after injecting bootstrap-tour, redirects to /login (to log in), tries to
inject tour again except this time ``openerp.website`` is completely empty
(although it is present on the page), no idea why.
removed test because whatever, if enable-test-fix-tour is ever rewritten and
fixed it may reappear.
bzr revid: xmo@openerp.com-20140219142115-5kpu5uvzpkwnt1ef
Christophe Monniez