Add the support to be able to specify exlicitely module, class and method name in test_tags
Before this commit, there is no distinction between module tag and test tag. Meaning
that --test-tag module_name will replace the default +standard tag and execute all test
of the module.
This commit tries to keep the initial behaviour, while addind new features, like explicit
modules tag with /module_name, as well as class (:class) and method (.method)
Some usage examples:
--test_tags /module will execute all standard test of module
--test_tags :class will execute all standard test with class name 'class'
--test_tags .method will execute all standard test with method name 'method'
--test_tags external/module will execute all external test of module
--test_tags */module will execute all tests of module,
--test_tags */module,-standard will execute all non standard tests of module,
--test_tags -/website:TestUiTranslate.test_admin_tour_rte_translator will disable only rte translator test
closesodoo/odoo#34756
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
We have multiple ways of simulating a frontend context while running python
tests (mainly during TransactionCase):
- `MockObject` class from 8557bcfa30
- `simulate_frontend_context` method from a5a5a57e48
- `DotDict` from f8efc9a957
This commit moves `MockObject` to misc to be reusable and adapt it to be
accessible by dot notation with `DotDict`.
Part of #34396
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>
This commit goal is to encapsulate every tour-test into a separate assets
bundle that would be called only during tests (command line) or by URL
(debug=tests). That way, a lot of .js files would not be loaded anymore
uselessly outside test mode and will speed up the page loads (especially in the
frontend as the backend do not reload the page anyway).
In order to do that, we needed to propagate the `debug` state from page to
page.
Otherwise, every page change during a test would simply lose the debug mode and
the test would stop as the test assets would not be loaded.
As we could not add the `&debug=tests` on every link (either hardcoded or
preprocess during the rendering), it has been decided to store it in session.
Technical summary:
1. `debug` state (currently only stored in URL) will be stored in session.
Either when adding the `debug` param in URL (handled with _dispatch) or by
starting Odoo with `test-enable` or `test-file` (handled by session init).
2. Once activated (and so set in session), debug mode will remain activated
even if not visible in URL (after a page navigation eg).
To deactivate it, set its value to nothing, `debug=`. That will exit debug mode
(whatever mode it is: debug, assets, tests).
3. As tour-test files are now in a separate bundle, every layout (when needed)
should `t-call="web.conditional_assets_tests"`.
As it would be redundant and verbose, no `t-if` is needed on the t-call to
load it only in test debug mode. That will be handled by
`compiled_assets_tests` that will actually do the conditionnal t-call-assets
to web.assets_tests, if tests debug mode is activated.
4. In addition to separating the tour-tests files in a separate bundle, we also
moved those files to a specific folder under /static/tests/tours next to
QUnit tests.
5. Also, tour files will be moved in a specific folder /static/src/js/tours for
cleanness purpose (those files will still be kept in their 'normal' assets
as needed outside test mode since it is tours).
This will be done in the next commit.
6. It is possible to enable multiple debug mode, such as 'tests' and 'assets'
together. Simply separate debug modes with a comma, eg '?debug=assets,tests'
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
Before this commit, when we want to make an external url, we need to know
if the record is related to a specific website or not, and choose base_url
or website domain.
Now each model have a fonction get_base_url (public to be callable from email
template, ...) and website override this function to add the website domain if
the record is website specific.
closesodoo/odoo#34089
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since b5a12b4aac the website_id was not set anymore.
Indeed, before this commit website_id was the field from the inherits, thus
when writing on website_id from res.user, we would write on the partner field.
But with b5a12b4aac the website_id was explicitely overrided on res.users as a
related to res.partner (its inherits) with readonly=True.
Thus, writting website_id on res.users was not working anymore.
closesodoo/odoo#33521
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously the image that we uploaded as a favicon of the website was not
resized, so it could be extremely excessive in size and resolution, and it also
was not guaranteed to be a square.
Now we always resize it appropriately and save it as an ICO file.
The default favicon is now applied to all websites instead of only the first.
task-1958000
PR: #31811
Reintroduces 5324284f5 that was reverted because in the case of an URL
like /payment_stripe/static/src/js/stripe.js directly inside a QWeb
template, we would possibly get:
/fr_FR/payment_stripe/static/src/js/stripe.js
Which is not accepted by werkzeug SharedDataMiddleware we use to serve
static data in /{module_name}/static/ directories.
Added test without changeset failed with:
- test_process_att_no_request_lang: <AssertionError>
line: self._test_att('/en_US/', {'href': '/'})
wrong result: {'href': '/en_US/'}
- test_process_att_with_request_lang: <AssertionError>
line: self._test_att('/', {'href': '/fr_FR/'})
wrong result: {'href': '/'}
- test_process_att_matching_cdn_and_lang: <AssertionError>
line: self._test_att('/en_US/a', {'href': 'http://test.cdn/a'})
wrong result: {'href': 'http://test.cdn/en_US/a'}
- test_process_att_no_route: <AssertionError>
line: self._test_att('/my-page', {'href': '/fr_FR/my-page'})
wrong result: {'href': '/my-page'}
- test_process_att_url_crap: <IndexError: list index out of range>
line: request.httprequest.app._log_call[-1],
opw-1922051
closes#32095
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.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>
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>
It's better to always have a relevant name in the image URL for SEO.
Also make sure there is always an alt on the image.
closesodoo/odoo#31705
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
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
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 commit, the website selection was not working when a scheme or port
was encoded in the domain field. This was not obvious or natural for the user,
because the easiest way to fill it was to copy/paste the URL from the browser.
Now it works when scheme or port are encoded, it is even strongly recommended to
actually encode them if they don't take a default value because they will be
used when creating full URL to the website (typically when sending emails to
clients where a link back is necessary).
PR: #30000
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
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
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.
Martin Trigaux