Fix various tours which either have transient failures due to logging
the entire browser lifecycle or don't deal well with the last step
being suppressed if no explicit `run` is provided.
* test_website: add a warning final step for the page reset as there's
no way to actually run a tour step in the recovery page (because
it's asset-less)
* website: remove final step's action in reset password tour, it's
relatively low-value and adding a proper followup is probably not
worth the effort
* website: add final check step in dashboard tour, as we want to check
that the dashboard gets loaded, but we don't want that to be dangling
Before this commit launch a server with --db-filter that match at least 2 dbs name
Try to authenticate
You will have an error request is unbound when you try to access request.env
Now we retrieve the user from self instead of the request.
New test to ensure rpc authentication is tested.
Related to commit 245ef4b1
closesodoo/odoo#38969
X-original-commit: 4b3400c430bec7539aada0619fd203978daca2d8
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = stock, test_website, web, website_forum, website_slides, base
Replace KarmaError with AccessError and remove the related override made
on crash_manager and ir_http.
task-2069890
closesodoo/odoo#36655
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = gamification, test_website, stock
- KarmaError is now handled as a 400 exception.
- test_website has been updated.
- NO_POSTMORTEM is now clean it was referencing duplicates as most the
exceptions inherit from except_orm.
- serialize_exception from http.py has been moved to ir_http
to take advantage of the odoo inheritance system. We can then
extend ir_http serialize_exception method to add the KarmaError
logic if and only if gamification is installed.
Places where serialize_exception was previously used are updated.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
The purpose of these tests is to verify that errors informations
are displayed correctly on the website.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
Since AST was introduced to compile Qweb templates, the reset templates
functionality is not working anymore.
Actually, it does not even appear anymore as the conditions to trigger and show
the reset view behavior can't be True anymore.
Indeed, the code is still importing the old QWebException from odoo.exceptions
which is now just an empty class.
The QWebException that should now be used is the one from odoo.base.models.qweb
More than just a wrong import, the QWebException properties have completely
changed.
Since its last working version (Odoo 9.0), a lot of changes occured, mostly:
- Odoo 11.0: new model website.page, which completely changed the pages
behavior and changed the models.
- Odoo 12.0: multi-website, which introduced the Copy On Write (COW) that
redefined how we write on view in a website context. We now need to reset
copied/specific views that have no model_data_id.
This fix is for a stable version. There is some flows that can't be fixed
without a refactoring or new fields (mainly because of the arch_fs being
erased when writing on `arch`, plus we can't introduce a module reload in
stable).
The goal of this commit is to fix the basic and standard case of broken views,
which is when non-technical users are breaking the views through HTML editor.
To reset the views, we will read the original arch in the XML file, as the
dev mode is doing.
To be eligible for the reset, the broken view need an `arch_fs` set. If the
view arch has been modified anywhere else than the frontend, the `arch_fs`
will be erased and the view wont be able to be reset.
As the broken views will be specific views, we will simply read the generic
view in the XML file and write it on the specific. We can't simply remove the
specific view as we might be on a specific tree.
Specific case, in case of custom views create dropping a snippet in an oe_struc
we just delete this inehrited view to allow end user to have their page back.
In some case of bad compilation in sub template, we try to guess which inherited
view, t-called view is broken by string matching based on 'last_path_node' xpath.
Add new module test_website to add tests, it will be usefull for futur test of
install/uninstall and ...
Todo in master:
- try to track on QWebException the real template that is broken and not only
the last node from the main template.
Co-authored-by: "Romain Derie <rde@odoo.com>"
Co-authored-by: "Jérémy Kersten <jke@openerp.com>"
closesodoo/odoo#29957
Commit fcb972d skipped a test on saas-12.2 after forward port as it was not
working on that version.
This commit restore the test and fix it.
It was actually a race condition on the save step on edit mode.
Something similar was done already for another test, see 74a98ea.
closesodoo/odoo#31465
Xavier Morel