When the QWeb `<template>` loading test was introduced at [1], the
`test_website` module did not exist yet, see [2].
This commit moves that test and its related data file to `test_website`
to remove the `fake data` noise from the `website` module.
That's one of the two purpose of this `test_website` module:
- Avoid noising the website module with test only data & code
- Encapsulate in a lighter module the module operations tests, but it's
not really the case anymore as those tests are now standalone tests.
See manifest for more details.
[1]: https://github.com/odoo/odoo/commit/9cd982bcc811cacb42f5c08db139043d2734b891
[2]: https://github.com/odoo/odoo/commit/ef03db9edd9472201cb2c08a32d20ff0f33a5fdfclosesodoo/odoo#109349
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the file size is displayed only for images that support
processing (filter effect, crop, resize...) but when switching to an
image that does not support it, the old size remains displayed.
After this commit when an image for which the file size is not computed
is selected, the previous file size is hidden.
Steps to reproduce:
- drop a Text-Image snippet
- select the image => the size is displayed in the options block title
- replace the image with an animated gif
=> previous size did remain displayed (now size is not shown anymore)
[1]: https://github.com/odoo/odoo/commit/089ae3d28b5d2d7bdbaad133174ae54240113181
task-2729177
X-original-commit: 378f67749a51d8c0b9fb65767faceaa0844916e5
Part-of: odoo/odoo#95963
Progress bar on image upload was introduced with #65828 in saas-14.3.
Since, it has been broken in saas-14.3 with 3765ac1 which broke the flow for
image unrecognized by PIL, see the other commit of this PR.
It was also completely broken in master (saas-14.5) with the wowl refactoring,
where no progress bar were shown at all. It would show empty toastr.
This was fixed with #74027
This commit introduces a complete testing suite for that progress bar:
- Single image upload
- Multi image upload
- Success upload
- Unsupported error
- Unrecognized error
task-2607393
Closes#74122closesodoo/odoo#74454
X-original-commit: 381d432faf8d19e71ff1d63c29a14064a6d7f57f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
2021-08-02 13:57:41 +00:00
Jeremy Kersten"Romain Derie <rde@odoo.com>""Jeremy Kersten <jke@odoo.com>"
Basic tests & tests of the 3 fixes of #64328
Be sure that we have a beautiful error page and not a black/white error
Be sure that slug_matching with 308 redirect works as expected and don't
raise a RequestUID exception.
closesodoo/odoo#64889
X-original-commit: 3af11f0b6db0efb6c912b25bcd04d2cbe9a07d57
Co-authored-by: "Romain Derie <rde@odoo.com>"
Co-authored-by: "Jeremy Kersten <jke@odoo.com>"
This commit is a manual forward port of #62555. The tour test needed to
be adapted because the navigation flow is slightly different: upon
custom snippet creation, the editor page used to be saved and reloaded
in 14.0 but this is not the case anymore.
Before this commit the deletion of custom snippets failed because the
button click event got intercepted by the drag'n'drop mechanism.
The currentTarget of the event was used in an asynchronous call where it
had already been replaced by the jQuery's event bubbling mechanism when
invoking the other handler.
After this commit the deletion of custom snippets works again and a test
tour is introduced to make sure it does not get broken again
task-2405854
closesodoo/odoo#63108
X-original-commit: 4de0519d5b54634604e22b32d91a099695378088
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- 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
Old heuristic is not more True:
Force to check method to POST. Odoo uses methods : ['POST'] and ['GET', 'POST']
We have some controller that only allow 'GET' method, so we need to check GET
also when we try to know if an url is multilang or not.
This commit fix case where a controller '/test' only allow GET and you were in
another language that the default, in this case, the rendered url in qweb was
/get instead of /<lang>/get.
Closes#37223closesodoo/odoo#40519
X-original-commit: c7650106f8588083be12812600a6c94ba703fd6f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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>
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
Purpose
=======
This commit tests some behaviors with multi company
mode after changes brought by f847a46.
Specification
=============
The website company should be automatically set in the
context as 'allowed_company_ids'.
That way, we can remove the switch company menu on the
website, which doesn't make a lot of sense.
This test enforce this behavior.
Before this commit, call a controller defined as:
```
@http.route('/route', type='http', auth='public')
def controller_func(self, foo):
do_it()
```
and called with url like /route?foo=1&bar=2
will crash with an exception:
`TypeError: controller_func() got an unexpected keyword argument 'bar'`
Now, we remove the extra parameters if the controller doesn't support it.
This case is not uncommon, you can easily arrive in this case with utm or
debug as extra parameter.
closesodoo/odoo#33962
Signed-off-by: Christophe Simonis <chs@odoo.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>
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
Benoit Socias